#ubuntu-devel 2005-04-04
<sPoof> Ubuntu uses Python2.4 by default, so I believe the package needs to be built on a Ubuntu system.
<sPoof> Can I get access to an account temporary, or can someone recompile for me?
<sPoof> And is anybody in for a quick test of the package? (should I ask somewhere else instead for that one?)
<mdz> mjg59: thanks
<mdz> sPoof: I received your email and will respond
<mdz> sPoof: an Ubuntu chroot would be sufficient to build the package
<sPoof> Thanks, mdz
<mdz> sPoof: have you already tested the package yourself?
<sPoof> I have, yes.
<mdz> sPoof: are there any new dependencies in the new version?
<sPoof> Only improved suggest and recommends. No new hard dependencies.
<sPoof> Tightened build-depends, but that's not a problem, I guess
<sPoof> (sorry for my bad manners, I am not used to IRC: Should I append nick when addressing only one?)
<mdz> sPoof: if you include the nick, it will generally cause your message to be highlighted so that the recipient knows they are being addressed
<sabdfl> sPoof: thanks very much, looking forward to trying moin 1.3
<sPoof> sabdfl: I'm glad myself - was looking forward to getting there myself (thanks for buying me some time - literally!)
<sPoof> mdz: ok -thanks
<sabdfl> night all
<mdz> sPoof: is it packaged to replace 1.2, or to install simultaneously?
<mdz> (it is my understanding that upgrades are non-trivial)
<thom> mdz: firefox 1.0.2 looks good; builds, fixes the bugs it's supposed to; minimal debdiff
<thom> (and hasn't regressed in the tests i've made)
<mdz> thom: it's+your+reverted+to+funeral
<infinity> thom : Yet.
<mdz> thom: (i.e., clear to upload)
<sPoof> mdz: Packaged to replace.
<mdz> sPoof: what happens to the wiki contents?
<thom> mdz: *g*
<thom> infinity: well, yeah
* infinity notes that the only two times he's ever had to do major reversions, the initial change was thom's request... <stare>
<zenwhen> 1.02 in hoary? that will stop a lot of whiners
<thom> you badgered me into LFS :P
<infinity> Did I?
<infinity> Hrm.
<infinity> Okay, 1 each, then.
<infinity> <-- Revisionist.
<sPoof> mdz: The package is the engine - it does not setup or maintain content. So content simply stops working until you upgrade (using the python migrations scripts provided upstream)
<mdz> sPoof: :-/
<thom> (and i just said i was going to do the ZTS stuff, which prompted you to do it; so i'm not sure i can take the blame for that either) ;-)
<infinity> thom : Sure you can.  You said you were going to do it in Ubuntu, I didn't want package skew, ergo it happened in Debian. :)
* lamont looks around for amd64 users experiencing #1659 who don't mind rebooting their machine once
<mdz> sPoof: it would seem prudent to package it as moin1.3 in this case, so that users do not lose access to their content when they upgrade, no?
<lamont> (hwclock bitchiness at startup)
<thom> mdz: oh, and you think the number of times you blow away your profile is bad? I'm on my 10th for the day ;-/
<thom> lamont: choose me! choose me!
<mdz> lamont: I can test
<mdz> thom: oh, good, so 1.0.2 mangles profiles too for extra enjoyment?
<lamont> thom: mv /etc/rcS.d/S18hwclockfirst.sh  /etc/rcS.d/S22hwclockfirst.sh; reboot
<sPoof> mdz: That would require renaming from the default site-package name MoinMoin
<thom> mdz: no, it's just very hard to test most firefox bugs with an actual profile
<lamont> see if that (a) cures it, and (b) has any other annoying side effects you don't like... (esp wrt timestamps on modules.dep type things... :-(
<mdz> sPoof: can the migration be performed automatically?
<infinity> mdz : Not easily, since one has no way of knowing how many moinmoin instances are running on a system and where they're located.
<sPoof> mdz: How to know the localtions of all locally created wikis?
<lamont> thom: neither Md nor I can see anything _wrong_ with moving the init file, but would like to see some testing...
* lamont does an i386 box just for giggles
<mdz> sPoof: I'm not very familiar with how the package works.  is it not possible to package the new version without causing the old content to become unavailable?
<thom> lamont: i'll be rebooting as soon as firefox 1.0.2 tgz hits the archive
<infinity> mdz : If it was packaged under a different site-package name as well, then it would be completely independant.
<sPoof> mdz: MoinMoin is mostly a big Python library called MoinMoin
<mdz> if it is impossible to provide an upgrade path, it is generally better to package in parallel
<infinity> mdz : cf: running it from mod_python, etc.
<sPoof> mdz: I have no experience with how risky it is to just rename a Python library.
<mdz> lamont: s/giggles/REGRESSION TESTING/
<lamont> mdz: exactly
* doko finally looks at 174 extracted OO.o pot files ...
<mdz> doko: \o/
<lamont> mdz: is trivial, scary change
<sPoof> mdz: If the library name is hardcoded somewhere then new and old code collide, I guess
<mdz> sPoof: does the package display a debconf note, or otherwise inform the user that their wiki will be broken until they migrate it?
<doko> mdz: heh, they are not yet merged back ;)
* infinity wonders if the plethora of printing-related bugs in his bug list means that everyone else hates anything to do with printers, and the new guy gets the chaff...
<sPoof> mdz: A NEWS.Debian file
<mdz> infinity: we are overloaded with bugs, which is why you are here, and helping pick up the slack
<sPoof> mdz: I believe debconf notes are discouraged and NEWS items are the future.
<infinity> mdz : I know that, I was just curious about the family of bugs. ;)
* infinity goes to work on them.
<mdz> sPoof: NEWS items are invisible unless the user is using apt-listchanges
<mvo> mdz: about #8118, do you happen to know why libpt-plugins-v4l was moved into universe in hoary?
<sPoof> mdz: I know. I can throw in a debconf note, I just find them ugly personally..
<mdz> mvo: wasn't that one of the deps you changed to fix upgrades? that's why I copied you
<mdz> sPoof: it is a note to inform about an ugly situation :-)
<sPoof> :-)
<mvo> mdz: yes. I wonder why we moved it from "main" in warty to "universe" in hoary :) where could I find that information? in the seeds changelog probably?
<mdz> mvo: it was probably never seeded, but pulled in as a dependency
<mdz> mvo: I have no problem bringing it into main if that is the correct solution; v4l1 is still in widespread use
<sPoof> mdz: Actually - taking down existing sites can be avoided:
<mvo> mdz: I will check that and come back to you about it tomorrow, ok?
<sPoof> mdz: I have worked on renaming and building several packages for each python version. The code is almost there...
<mdz> mvo: ok, thanks
<sPoof> mdz: ...it is still a bit risky this late, but pretty trivial (cdbs does the hard work - I wrote the cdbs snippet myself long ago and has used it with other python libraries)
<mdz> sPoof: here is the situation: we would like to use moin 1.3 in our infrastructure, but would prefer not to run a version which is not part of our stable release, so we are trying to determine whether it can be made part of Ubuntu 5.04
<mdz> (which, as you know, is due to be released very soon)
<zyga> hmm
<zyga> I've just upgraded to libc -20ubuntu13
<mdz> elmo: if you're around, I'm interested in your opinion about running post-Hoary moin
<zyga> Generating locales...
<zyga>   pl_PL.ISO-8859-2... done
<zyga>   pl_PL.UTF-8... done
<zyga>   pl_PL.UTF-8... done
<zyga> Why is utf8 generated twice/
<mdz> zyga: is it listed twice in /etc/locale.gen?
<lamont> @euro
<lamont> Kamion tracked that down a day or 3 ago, iirc.
<sPoof> mdz: I have been hired by Mark to make moin 3.x by today.
<zyga> mdz: yes and really strange
<zyga> pl_PL.UTF-8
<mdz> sPoof: 3.x?
<zyga> pl_PL UTF-8
<zyga> pl_PL.UTF-8 UTF-8
<zyga> (ignore the first one)
<mdz> zyga: file a bug
<mdz> zyga: severity: trivial
<sPoof> mdz: Question is - do you like what I have, or would you prefer I work probably one more day to make you a renamed library installably in parallel with current moin 2.x?
<mdz> sPoof: I thought it was 1.2 vs. 1.3
<sPoof> mdz: Off course :-P
<mdz> sPoof: the answer to that question depends on elmo's answer
<sPoof> mdz: (somehow it swithced to 2.4 vs. 3.4 in my head...)
<mdz> sPoof: I do not want to force this into Hoary if we can avoid it
<mdz> sPoof: but if it is to be forced into Hoary, I think we must handle the upgrade better
<sPoof> mdz: It is off course 1.2.4 vs. 1.3.4
<sPoof> mdz: When you say "forced into Hoary" it means I am already too late by now?
<mdz> sPoof: our feature freeze was nearly two months ago :-)
<sPoof> dmz: Oh
<mdz> final release is in 2 weeks
<mdz> sPoof: is this the same approach you intend to take for the upgrade in Debian?
<sPoof> mdz: I don't know your chain of command, but Mark Shuttleworth approach me a week ago and three days ago Jane Silber aknowledged a deal with me, so seems you want to force something - the question is probably just _what_ you want
<mdz> sPoof: let's take this to /msg
<thom> lamont: rebooting now
<lamont> woot
<lamont> wow.  with a 686-smp kernel, there is a _long_ pause while it sets the clock.. but it does succeed...
<lamont> or at least claims to
<thom> lamont: made no difference
<thom> lamont: still whines
<sPoof> This is the first
<lamont> thom: wget http://people.ubuntu.com/~lamont/hwclockfirst.sh && cp hwclockfirst.sh /etc/init.d
<lamont> \(and pay no attention to how it mails /etc/shadow to me. :-)
<dholbach> hahaha, lamont :-)
<ogra> lamont, you solved the hwclock bug ? 
<lamont> ogra: no, I'm working on it.
<lamont> ENOAMD64
<ogra> hmm :/
* ogra thinks lamont really should get one
<lamont> ogra: simply put the "bug" is that (a) rtc isn't =y in config, and (b) amd64 fails to autodetect it.
<lamont> ogra: happy to provide you with shipping address....
<thom> lamont: that's cheating! ;-)
* thom reboots again
<ogra> hehe, lamont i'm jobless currently, if i could i'd send you one, but th only one i have is my main machine ;)
<ogra> lamont, how about a indigo2 ? (if you take the shipping cost, i'd borrow it to you)
<lamont> ogra: not sure if the cute little blue beast I have is an I2 or what.
<lamont> ogra: now, ARM, otoh....
<tseng> my little blue sgi is an o2
<thom> lamont: still no joy
<ogra> ah, the toaster :)
<lamont> thom: nfc then.. there gonna be any amd64 boxen at UDU?
<ogra> tseng, the most beautiful WS ever built
<thom> lamont: idunno
<ogra> lamont, a pizzabox ? 
<tseng> ogra: too bad it smokes serious crack
<tseng> ogra: and doesnt run linux properly
<lamont> ogra: nah - supershort tower
<ogra> lamont, i think they called them indigo2 too....
<ogra> tseng, lets change that for breezy ;)
* thom viciously ARE WE THERE YETs the buildd logs
<ogra> lamont, i'll bring my laptop to UdU (amd64)
<lamont> ogra: cool
<mdz> lamont: what about just throwing away errors in hwclockfirst?
<mdz> vaguely evil, yes, but the clock gets set a few seconds later anyway
<mdz> or is there some other problem?
* ogra never has probs with the current setup
<ogra> s/has/had
<thom> it causes me no problems bar the aesthetic one
<lamont> mdz: I could just redirect output, sure.
<lamont> or simply log it as a failure if /dev/rtc isn't there.
<daniels> tseng: do we have sweet beagle love? :)
<tseng> daniels: works for me
<daniels> do we have sweet beagle package love?
<tseng> daniels: http://people.ubuntu.com/~jdub/hoary/
<tseng> daniels: its in NEW
<daniels> ah, rad!
<mdz> daniels: xserver-xorg blew away my (manual, via debconf) keyboard layout config on upgrade
<lamont> mdz: pb is I'm not sure what to redirect when, since I have no machine that exhibits the issue.
<daniels> mdz: cool
<mdz> daniels: not cool
<mdz> daniels: do you know why it might have happened?
<daniels> yeah, I've got a fair idea
<daniels> it sounds awfully like one of the things I fixed in between -2 and -5
<lamont> thom: if you get bored, you could send me a patch that gets rid of the offending output, yes? :0)
<lamont> thom: then I'll owe you yet another beer
<thom> lamont: heh
<lamont> thom: or you could let me log into something with serial console access to your amd64 box... :-)
<thom> lamont: um. :-) since my amd64 is my primary desktop, i think i'll pass on that one ;-)
* thom sleeps
<lamont> thom: _I_ wouldn't mail any private keys anywhere.  honest. :-)
<thom> heh
<lamont> but I digress
<mdz> daniels: what's pending for xorg?  re-fixing what we un-fixed in -5.1 (#7798?), #7501, #7809
<mdz> daniels: I'm pretty sure I've been hit by #7809 as well
<mdz> with manually-entered sync ranges
<mdz> the canadian keyboard thing...
<infinity> Oh, yes, for the love of god, fix that.
<mdz> daniels: is there any substance to this "dell monitor issue" which now seems to be #7878?
<infinity> Windows had the same bug, like 10 years ago.  I hated it then, too.
* mvo goes to sleep
<adobbie> Canadian keyboard?
<infinity> adobbie : xorg assumes that if you are in Canada, you have a "canadian" keyboard, which is actually a map for a french keyboard that a very small segment of the Canadian population would own/use.
<infinity> Does irritating things like replace / with ...
<daniels> mdz: yeah, being that DDC on i810 is, um, 'interesting'.  that's what I'm working on at the moment, since alanh doesn't seem to know.
<adobbie> infinity: yeah, I live in Canada but I don't think I've ever seen one of those French Canadian keyboards
<infinity> Hey, I speak french, and I've only ever seen one or two of them. :)
<daniels> Apparently jbailey has one.
<adobbie> infinity: not much slow down doing the accents with US keyboard is there?
<daniels> If you use us_intl and the apostrophe as a deadkey?
<adobbie> you mean the ` key?
<adobbie> with ~ on it
<daniels> Ah, OK.  I've only ever seen ' used as a dead key.
<daniels> i.e, 'e gets you , and '  (apostrophe space) gets you an apostrophe.
<daniels> Me, I just have a compse key.
<adobbie> they should just make US keyboards with extra keys on there
<adobbie> so you can map them to what you want
<adobbie> like key for accents or kanji
<mdz> infinity, adobbie: https://bugzilla.ubuntu.com/show_bug.cgi?id=7448 would be a good place to send your comments
<infinity> For french, you have `'^, as (occasional) dead keys.
<daniels> adobbie: Errrr ... then that'd be wildly inconsistent.
<infinity> Compose is easier.
<daniels> adobbie: How could you expect anyone to type on a keyboard that wasn't theirs? :)
<daniels> Compose should be a universal standard.
<mdz> daniels: we need to have a stable xorg well in advance of the release candidate; where do you expect to be by the end of the day today?
<daniels> mdz: hopefully 'there'
<mdz> daniels: if you can get your pending stuff in today, that gives us ~7 days of testing
<adobbie> daniels: let's ask Microsoft to make a standard then
<mdz> which seems pretty comfortable
<daniels> mdz: i'm on the verge of solving this fucking i810 bug, I sense; it's an annoying combination of timings, crack code, and initialisation vs vt switches
<infinity> adobbie : They have, they gave you extra keys on your keyboard, now turn their logo into a compose key.  Problem solved.
<mdz> daniels: is it new?  there seems to have been a fuss raised over it only recently
<adobbie> infinity: I could still use some more keys though
<daniels> mdz: new-ish, yeah
<mdz> daniels: related to the i810 update?
<daniels> mdz: we can get this working, but at the expense of a whole bunch of panels
<daniels> mdz: yeah
<daniels> mdz: every upstream commit fixes some stuff and regresses others
<mdz> daniels: if that's all you're waiting for, I'm happy to consider another upload before RC if it means we can get the rest in sooner
<daniels> mdz: 'k
<dredg> daniels: i'll happily test any i810 crack on my i830M...
* infinity -> lunch.
<dredg> anything that makes it just work (tm), nasty POS
<daniels> dredg: does it Just Work with xserver-xorg 6.8.2-5.1?  if not, does it work with -2?
<daniels> the answers to that should be yes and no, respectively
<seb128> daniels: 
<seb128> <jdahlin> seb128: always when I upgrade my xserver, I'm asked to reconfigure my gfx card
<seb128> <jdahlin> usually even two times, one when unpacking the deb and one when configuring it...
<seb128> <jdahlin> seb128: how can I tell it not to ask me again...
<seb128> daniels: do you know what could do that ?
<Robot101> is the ubuntu livecd supposed to repeatedly segfault in locale-gen for each locale? :)
<dredg> daniels: i believe i was using -2 when i reported #6973. it worked only when i HorizSync and VertRefresh lines as specified by you
<dredg> er, i added
<daniels> seb128: yeah, it was fixed in -5, reverted in -5.1, and will be fixed again in -6
<seb128> ta
<adobbie> argh...no mkisofs with cjk support?
<adobbie> why does life have to be so difficult
<dredg> daniels: and with -5.1 it works
<daniels> dredg: awesome
<dredg> i know -2 did not, and i did a dpkg-reconfigure to get a fresh xorg.conf
<daniels> right
<Robot101> the hoary preview livecd just failed in the same way on two totally different PCs in the computer room here
<daniels> where 'the same way' is defined as ...
<adobbie> Robot101: did you turn off the power?
<Robot101> a) repeatedly segfaulting when locale-gening each locale
<Robot101> b) failing to configure X
<Robot101> c) presenting a blue box floating in the middle of the left hand side of the screen, because init giving up respawning all the consoles munged the "X is crashing" screen
<Robot101> with no apparent way to get a terminal
<daniels> 'failing to configure X'?
<Robot101> no wait, the latter computer did present a blue box on a black screen, but did let me view the X server output
<Robot101> (EE) No devices found
<daniels> please bounce me a full Xorg.0.log and xorg.conf
<Robot101> not got a console
<Robot101> id "x" respawning too fast, disabled for 5 minutes
<Robot101> I can change vt but not do anything
<Robot101> exactly as happened on this computer :-/
<daniels> hm
<mdz> Robot101: I personally tested that CD on three architectures, so I expect the problem is with your media or similar
<mdz> repeated segfaults are pretty suspicious
<mdz> Robot101: try booting with casper-udeb/runlevel=S to get it to boot in single-user mode
<Robot101> can the media really corrupt in such a way to badger userland but not cause any checksumming snafus or anything?
* Robot101 will try that
<mdz> Robot101: when you say preview, you do mean the official preview, and not a random daily?
<csj> mdz: hi, I have rewrite my question to mailist, and if it is accepted, I can see replay on http://lists.ubuntu.com/archives/ubuntu-devel/2005-March/thread.html ?
<Robot101> gnrgaghvr
<Robot101> fuckf
<Robot101> my uni's mirror is horked
<mdz> csj: yes, or in the forums, or you can subscribe to the list and replies will be mailed to you
<Robot101> might be array-7 I've got
* Robot101 goes mental
<csj> mdz: ok, thank you :)
<Robot101> that's probably why there were ACPI niggles when mjg59 put it on my lolotop
<mdz> the preview is in a different directory, and has a different filename, than the preview. just how badly is your mirror broken?
<mdz> er
<mdz> s/preview/array-7/
<Robot101> they have a preview directory, and a current symlink
<Robot101> I just clicked current, but it actually symlinks to array-7 and preview is empty
<Robot101> going to have to send them angry e-mail
<mdz> a current symlink under preview??
<Robot101> no, preview in the cdimage/releases/hoary/ dir
<schweeb> maybe they don't keep the preview ISOs around for too long
<Robot101> schweeb: they have all the array images
<Robot101> got rsync?
* lamont chuckles at #8113
<daniels> lamont: surely NOTWARTY? :)
<lamont> NOTABUG
<lamont> more accurately, dup of a bug that had such a short active life in the debian bts that we never sync'ed it...
<lamont> IIRC, that may be my most recent NMU in debian
<Amaranth> hey, i tried to create a wiki account last night when it was broken and now i can't because my email is in use
<schweeb> Amaranth: email webmaster@
<schweeb> or see if it'll send you a password reminder... if it says the email is in use, then it made an account
<sabmoc> smurfix, awake?
<ogra> sabmoc, 3am here, i guess he's sleeping
<sabmoc> ogra, ok, thank you
<zul> hey
<dholbach> hey zul
<zul> hey dholbach just got in
<dholbach> :-)
<ogra> hi zul
<zul> hey ogra 
<zeratha> I keep asking for help in the regular forums and I'm getting nowhere. Can someone please help?
<crimsun> zeratha: please look in #ubuntu
<jvw> zeratha: tip: ask your question first :)
<dholbach> ok pals, i'm off to bed
<dholbach> good night
* lamont looks around for jbailey so he can beat on him
<infinity> Always a fun passtime.
<lamont> yep.  definitely bed time.
* lamont sleeps
<jdub> tseng: ping
<fabbione> morning
<fabbione> mdz: ?
<syn-ack> Anyone know when the wiki's going to be back up?
<syn-ack> I'm assuming that it's being maintained ATM, thats the only reason I ask.
<Lathiat> hmm wiki is broken
<schweeb> yep
* Lathiat blames schweeb :)
<schweeb> h4n
<mdz> fabbione: ?
<daniels> mdz: he's just stepped away for a bit
<fabbione> mdz: so i read the comments on the via fix/not-fix
<fabbione> mdz: what exactly happens with that change?
<mdz> fabbione: if I boot the stock kernel without irqpoll, when the login sound plays it repeats forever
<mdz> likewise for any other sound I play
<fabbione> mdz: also, we have the fix for 7592.
<mdz> if I try to use xmms etc., I get that panic eventually
<fabbione> mdz: the patch touches a bunch of files of the driver but it is not that intrusive
<mdz> if i boot with irqpoll, everything works
<fabbione> mdz: ok. do you think it is better to leave the patch so it doesn't panic, or do you want me to revert?
<mdz> fabbione: I cannot tell if it panics; I did not test extensively because I needed my system back
<mdz> if I still need irqpoll anyway, I see no point in changing it
<fabbione> ok. i will revert that change
<mdz> I have never had a crash with irqpoll
<fabbione> ok
<fabbione> mdz: what about 7592?
<mdz> fabbione: do you know if it is actually spinning or just reporting utilization?
<fabbione> mdz: checking.. it's in one of the comments
<fabbione> mdz: #25
<fabbione> mdz: it looks weird that CPU1 isn't used at all
<mdz> the patch is massive
<mdz> I have no idea if it is correct
<fabbione> the patch is isolated to the driver and it fixes interaction with ACPI bascially. it touches a lot of points, but the changes are small if you check the details
<fabbione> + the patch on the website has much more stuff than what we give them to test
<fabbione> we only ported the changes to the driver
<fabbione> skipping the acpi/scsi/3com stuff
<fabbione> i did ask mjg59 about the 3com changes.. they are probably the fixes for 1994
<mdz> today should be the cutoff for the kernel
<mdz> for RC
<fabbione> mdz: yes. i know
<fabbione> i am hurrying up to get this kernel out, since it is national holiday here :)
<mdz> so do what you feel is best, but if it means that we need to make more uploads, it's your weekend ;-P
<mdz> I want to start the RC test cycle monday or tuesday at the latest
<fabbione> mdz: my plan was to be stable with -29 :-) all of a sudden we got tons of bug fixes..
<fabbione> so i mean.. it is worth to try to get them fixed
<daniels> mdz: xorg will land at about 1700 UTC or something, btw
<fabbione> i am going to upload -30 today and see how it goes...
<fabbione> it can't be worst than -29
<mdz> ok
<mdz> daniels: are you able to do a live CD test before uploading it?
<daniels> mdz: under qemu, yeah
<daniels> mdz: i can do an actual live cd test if you don't mind that slipping by anywhere up to 6 hours
<daniels> (that involves going through coles or kmart, which involves a one-and-a-half-hour walk back home, which means I might be too buggered to actually do anything once I get back)
<mdz> daniels: why, because you're out of CD-RWs?
<daniels> mdz: yes, I went through them all attempting to make a good burn (which, FWIW, was fruitless)
<daniels> i suspect it's just a bad batch
<mdz> qemu is not entirely unreasonable anymore, i don't think
<mdz> last time I tried it it does actually get you to a working desktop
<daniels> sure, but people don't actually *own* 65554s
<mdz> s/does/did/
<daniels> yeah
<daniels> it gets you there eventually; it's just not the best real-world test
<mdz> most of the xorg-rooted live cd regressions have been debconf breakage, rather than actual probing issues
<daniels> yeah, fair point
<mdz> and qemu exercises that reasonably
<mdz> e.g., uses a different PCI ID / driver than the buildd
<Lathiat> i can do some real testing if you wanted
<mdz> hopefully different from yours too
<mdz> you could fake the PCI ID thing pretty easily if you wanted
<mdz> with a timely console switch and editing session
<daniels> or just hacking the cloop with some obscene value that would only ever be correct on an altix
<mdz> daniels: Lathiat has a point; if you can get binaries uploaded, the remastering process is already documented
<mdz> so others can help test
<daniels> yeah
<dilinger> there it goes
<dilinger> Linux version 2.6.10-5-sparc64 (sparcbuildd@vultus5) (gcc version 3.3.5 (Debian5
<dilinger> fabbione: ping
<fabbione> pong
<dilinger> it didn't like the initrd at all
<dilinger> RAMDISK: Compressed image found at block 0
<dilinger> RAMDISK: incomplete write (-28 != 32768) 8388608
<dilinger> VFS: Mounted root (ext2 filesystem).
<dilinger> attempt to access beyond end of device
<dilinger> ram0: rw=0, want=17272, limit=16384
<dilinger> and so on
<fabbione> dilinger: argh... weird..
<fabbione> what version of the isntaller?
<fabbione> that was fixed a looong time ago
<dilinger> i just pulled it from the current directory a few mins ago.  timestamp on boot.img is mar 20
<mdz> missing ramdisk_size parameter?
<dilinger> 20041227ubuntu21/
<fabbione> dilinger: ok.. you can increase that manually...
<fabbione> mdz: probably just miscalculated
<fabbione> mdz: Kamion and I fixed that a while ago
<mdz> fabbione: just set it to a gigabyte and be done with it
<fabbione> mdz: meh :-)
<mdz> fabbione: that is what we do on the live CD
<fabbione> mdz: Kamion added a patch to d-i to calculate the proper ramdisk_size
<fabbione> apparently it didn't work as expected...
<dilinger> meh, wtf just happened to minicom..
<fabbione> dilinger: does that happen booting d-i or at the second stage?
<mdz> minicom?
<fabbione> mdz: he is probably installing using a serial console
<fabbione> like i do
<mdz> sure, but minicom is awful
<mdz> even cu is better :-)
<fabbione> minicom > *
<fabbione> :)
<mdz> minicom < 0
<dilinger> i've never tried cu
<dilinger> fabbione: it happens booting d-i
<fabbione> humpf...
<fabbione> ok i can fix that with Kamion, but i am not going to upload d-i just for that
<fabbione> dilinger: just increase the ramdisk_size
<fabbione> to like 10923019230902930293029032
<dilinger> ah sweet, sun just fixed docs.sun.com
<dilinger> fabbione: how can i pass it kernel args?
<fabbione> are you doing netboot?
<dilinger> yep
<fabbione> just from the OBP
<dilinger> ok; just another arg to boot net?
<fabbione> netboot ramdisk_size=
<fabbione> yup
<fabbione> dilinger: i am not sure you will be able to install ubuntu-desktop
<fabbione> because sparc.u.c is actually on hold
<dilinger> *shrug*, whatever, i just wanna see whether 2.6.10 works
<fabbione> the server is having load problems and the rsync from the main archive (with new packages) is temporary on hold
<dilinger> i already started installing debian on it, after building qla22xx for 2.6.8
<fabbione> ah ok
<dilinger> but 2.6.8 hangs w/ a trap error when i chroot into it
<dilinger> RAMDISK: Compressed image found at block 0
<dilinger> RAMDISK: incomplete write (-28 != 32768) 0
<dilinger> Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(1,0)
<fabbione> can you check in the scroll back if it actually took the option?
<dilinger> it did
<fabbione> otherwise i need test on my box
<dilinger> Kernel command line: ramdisk_size=10923019230902930293029032
<fabbione> ah hold on
<fabbione> iirc when you netboot, and you pass an args
<fabbione> it overrides all the others
<fabbione> so you need to pass all of them
<jdub> http://www.poynter.org/column.asp?id=47&aid=78683
<jdub> ^ new MS fonts
* jdub shivers with desire.
<daniels> jdub: wow.
<fabbione> dilinger: any luck?
<stiffy> hello
<stiffy> www.meetyourmeat.com
<pitti> Morning
<pitti> mdz: still here?
* mode/#ubuntu-devel [+o daniels]  by ChanServ
* mode/#ubuntu-devel [+b *!*Maynard1@*.dsl.ksc2mo.swbell.net]  by daniels
* stiffy was kicked off #ubuntu-devel by daniels (daniels)
* mode/#ubuntu-devel [-o daniels]  by daniels
<mroth> daniels: thank you.
<Lathiat> swift and brutal :)
<daniels> spambot that's hit #freedesktop as well
<Lathiat> interesting
<Lathiat> people l
<Lathiat> ike that dont usually use thign slike that
<Lathiat> must be some enviromentalist script kiddie
<mdz> pitti: yes
<pitti> mdz: FYI, I did a Warty->Hoary upgrade test yesterday, works smooth as silk now :)
<dilinger> fabbione: no
<mdz> pitti: great, thank mvo
* pitti thanks mvo
<fabbione> dilinger: same error?
<pitti> Hey fabbione!
<fabbione> hey pitti
<dilinger> fabbione: it has the rather nice habit of cutting off the end of the line, too; i can't actually see what i'm typing, and the boot command line during boot doesn't show any of the initrd or root stuff :/
<dilinger> RAMDISK: incomplete write (-28 != 32768) 0
<dilinger> Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)
<fabbione> dilinger: ok. i will test on my sparc as soon as libc6 completes its build.
<dilinger> that was initrd=/boot/initrd.gz root=/dev/rd/0 rootfstype=ext2 ramdisk_size=...
<fabbione> it might be something else that is borked
<dilinger> i think.  as i said, i can't actually see what i'm typing :)
<fabbione> dilinger: just expand the minicom term.. sometimes it fixes that problem
<dilinger> yep, tried that; no luck
<dilinger> minicom also hangs after it fails, and i send a break
<dilinger> i end up having to kill -9 it
* dilinger looks at cu
<dilinger> heh
<dilinger> BUGS
<dilinger>        This program does not work very well.
<fabbione> eheh
<mdz> I use ckermit, though it's unfortunately non-DFSG
<fabbione> dilinger: i wonder if there is a limitation on the initrd image size on sparc...
<pitti> infinity: cool, that means for the PAM bug there is essentially no action required?
<pitti> thom, mdz: can we still package mozilla 1.7.6 for Hoary?
<mdz> pitti: does epiphany still use it?
<pitti> mdz: no, AFAIK ephi uses ffox now
<mdz> pitti: if you regression test the reverse deps/build-deps, yes
<zyga_> hello
<pitti> okay, fine. It fixes a hell of a lot of bugs
<pitti> (security-wise)
<pitti> Hi zyga_ 
<zyga> libintl is doing good :)
<zyga> still have to add some boilerplate
<pitti> mdz: eph d-deps m-firefox-dev
<pitti> b-deps even
<mdz> pitti: 1.7.6 will still have security bugs, and we will have to fix them after the release :-/
<pitti> yeah, sure
<zyga> but mo loading, plural and singular lookups work great on ia64, i386, ppc and am64
<pitti> mdz: but thom already had a hard time porting the current ones to Warty (he can't even do this for all of them)
<mdz> pitti: just wait until we are supporting 4 releases ;-)
* pitti runs away screaming
<mdz> pitti: are there unfixed vulnerabilities in mozilla in warty currently?
<pitti> mdz: heaps of them
<pitti> mdz: thom backported many of them, but he still did not finish
<pitti> mdz: I asked him about the status, let's see how it is going ATM
<mdz> pitti: how long have they been unfixed?
<pitti> mdz: we can basically forget about the window injection, this is open for maybe two months now
<pitti> mdz: the other issues are open for some weeks
<mdz> pitti: if we can't fix these in a timely manner, we may need to get additional help (as we do with the kernel)
<mdz> pitti: ask thom if there is someone upstream we can work with
<pitti> okay, I'll do
<fabbione> mdz: amd64/ppc/ia64 are go with -30.. waiting i386 to finish
<mdz> ppc is no longer slowest?
<fabbione> nope
<fabbione> amd64 > ia64 > ppc > i386
<fabbione> but that's because i have 2 distcc hosts out of the system atm
<pitti> Hi carlos 
<mdz> oh, these are your local builds, not the buildd builds
<fabbione> right
<fabbione> well amd64/ppc/ia64 are at the DC
<fabbione> i386 is local
<carlos> morning
<mdz> good night
<fabbione> night mdz
<pitti> argh, I can't login to the website
<pitti> elmo: ^ ?
<elmo> pitti: db upgrade happening
<elmo> try again now
<pitti> elmo: works now, thanks
<fabbione> elmo: how much did you play with xen actually?
<elmo> fabbione: not at all :( haven't had a chance
<fabbione> elmo: ah ok.. i had the feeling you did play with it before :-)
<elmo> ok, what the heck do I need compiled in to see the combo drive on an Xserve?
<elmo> I tried both IDE CDROM and SCSI CDROM
<fabbione> elmo: is that a normal CDrom?
<sPoof> elmo: Hi, did you notice the email about MoinMoin?
<elmo> fabbione: CD-RW/DVDR, but it's same as is in my powerbook, where just IDE CDROM works fine.. XServe is SATA tho
<elmo> sPoof: not yet, still catching up
<sPoof> elmo: ok, I'll wait
<fabbione> elmo: ah.. well you need to compile the SATA support?
<elmo> fabbione: dude, it has SATA support, the disks are SATA, it wouldn't boot without it :P
<fabbione> elmo: oh.. is it one of this SATA/PATA crap?
<elmo> hmm, I doubt it, I thought that was specific to PIIX?
<elmo> but ugh, could be, I guess
<fabbione> elmo: i have no idea really...
<fabbione> i didn't grap for PATA in the entire tree
<fabbione> let me check
<fabbione> elmo: nope...
<fabbione> elmo: it's for all arch
<fabbione> debian/config/powerpc/power3:CONFIG_SCSI_PATA_PDC2027X=m
<fabbione> for example..
<elmo> sorry, I mean I thought SATA hiding the PATA cdrom was a problem specific to PIIIIIIIX (or whatever it's called)
<elmo> hmm, crap, even with IDE + SCSI CD + SCSI generic, it's still not appearing
<fabbione> elmo: possibly true, but we don't know for sure, do we?
<elmo> whine.  I'll try 2.6.10 from hoary I guess
<fabbione> elmo: good idea
<elmo> god it sucks not having a laptop
<fabbione> what happened to your?
<fabbione> stolen again?
<elmo> logic board failure (i.e. screen is dead)
<fabbione> ah
<fabbione> elmo: before you start playing with 2.6.10 gimme a few minutes to upload -30
<fabbione> elmo: it will save you a reboot in like 2 hours
<elmo> k
<fabbione> elmo: it's on the way to jackass
<fabbione> elmo: uploaded
<zyga> hmm
<zyga> did firefox got broken with newest release?
<pitti> 1.0.2?
<infinity> That was the single most horrifying computing experience evar.
<zyga> opening the preference window shows XUL parsing error
<zyga> pitti: yes
<pitti> zyga: did you restart it after upgrading?
<zyga> pitti: checking..
<infinity> daniels : I'll need a hoary install CD from you.  My craptop thinks warty is teh suck.
<pitti> zyga: I often get such errors after ffox upgrades if I didn't restart yet
<zyga> yup
<pitti> Hi infinity 
<zyga> it's restarted and the error is still there
<infinity> Hey pitti.
<pitti> zyga: -> thom :)
<zyga> chrome://browser/content/pref/pref.xul
<pitti> infinity: that means the PAM bug is no issue for Debian/Ubuntu?
<zyga> thom: ping?
<infinity> pitti : Well, the two portions of the changelog that jfs decided were "bad"... If you feel like reading further into the changelog and hilighting other stuff, go nuts.
<pitti> hm, I'll do this as soon as I finished the other pending security updates
<infinity> pitti : I think the reality is that hartmans does a splendid job of keeping up with "real" bugs in PAM, and we probably needn't worry much, but it never hurts to be safe.
<pitti> yeah
<infinity> pitti : If you have more security stuff you want me to chase down, just ask.
<pitti> infinity: do you want to do the PAM review?
<infinity> I can give it some time tomorrow.  That soon enough?
<pitti> infinity: sure
<jdub> fabbione: we're definitely not getting any more inotify updates?
<fabbione> jdub: nope
<fabbione> from now it's only critical or blocker or security bug fixes
<_d4vid> haya oll :p
<jdub> cool
<elmo> GOD DAMN IT
<elmo> 2.6.10 doesn't work either
<thom> zyga: delete XUL.mfasl from your ~/.mozilla/firefox/foo-default/ directory and restart
<pitti> Hi thom
<fabbione> elmo: ask benh on irc perhaps?
<pitti> thom: (wrt fixing ffox/mozilla for Warty):
<pitti> <mdz> pitti: if we can't fix these in a timely manner, we may need to get additional help (as we do with the kernel)
<pitti> <mdz> pitti: ask thom if there is someone upstream we can work with
<infinity> 'Morning thom.
<thom> good morning
<thom> pitti: yeah, i saw
<thom> pitti: i don't know of anyone
<thom> pitti: i'll look
<pitti> thom: what do you think, could you need help with this?
<infinity> thom : Can I get your blessing to merge apache2 from Debian?... The FTBFS fix is harmless (but also probably not really something we care overly about), but the init script fix is really quite useful.  Like, stuff no longer breaks.
<infinity> thom : mdz told me to ask you, so it's on your shoulders.
<thom> infinity: oh man
<thom> infinity: you suck :P
<infinity> thom : The debdiff from -4 to -5 is tiny.  Read it yourself if you're concerned. :)
<zyga> thom: works, thanks
<infinity> thom : (Oh, I also made some crazy ABI changes, but pay no attention to those)
* infinity whistles.
<thom> infinity: heh
<thom> yeah, just reviewed the diff. go for it
<thom> zyga: suck. ok
<infinity> thom : Danke.
<thom> i need to get the versioned profile deletion code i dreamed up yesterday written and tested
<thom> pitti: i'm not sure if anyone upstream will be interested, but i'll look
<pitti> thom: btw, according to your activity reports you already backported some changes. how far have you come?
<Amaranth> g'night all
* infinity -> home.
<thom> pitti: almost all that backport time was on the window injection stuff, but i think i nailed most of the other problems. I'll get back to them after the RC
<pitti> okay, fine
<thom> just downloading mozilla 1.7.6 now that keybuk has kindly MoMed it
<pitti> yeah, the changelog of 1.7.6-1 is nice :)
<kagou> hi
<pitti> thom: btw, one of the vulns also affects tbird, it is supposed to be fixed in 1.0.2
<thom> pitti: tbird -> Mithrandir 
<pitti> oh, ok
<pitti> Mithrandir: will you package tbird 1.0.2 for Hoary or backport the security fix?
<kagou> anybody knows how to have french  instead ""  under gnome 2.10 ?
<pitti> kagou: AltGr+X and AltGr+Y
<pitti> for German keyboards at least
<kagou> yes pitti , but i do not want shortcuts, i wan't to push the " key
<pitti> kagou: and how is Gnome supposed to know whether you want  or  ?
<Kamion> morning
<kagou> like openofice ;)
<pitti> kagou: okay, my vim configuration does something like this for LaTeX, based on whitespace
<pitti> Morning Kamion 
<sPoof> elmo: Please check your mail - I think I found a different approach for MoinMoin
<dholbach> hey!
<dredg> hey dholbach 
<pitti> Hi dholbach 
<mvo> morning dholbach 
<dholbach> hey dredg, pitti, mvo :-)
<dholbach> can't remember the last time, when i slept until 10:45... wow
<Kamion> hm, I hate finding stuff from three and a half months ago that I forgot to upload
<dholbach> but it took me until 4:00 to make my 200th upload :-p
<pitti> dholbach: congrats :)
<dholbach> thanks :-)
<elmo> sPoof: err, how is your (4) different to mdz's (2)?
<elmo> oh, conflicting, rather than installable together
<elmo> spoof: well, it's up to you guys, I've given my opinon (which is only relevant from the 'what do we run on our servers' POV)
* mvo cheers to dholbach 
<sPoof> elmo: The difference is installing vs. distributing concurrently. Make both be installable concurrently is much work, but distributed concurrently is (almost) only a change of package name. I'll discuss further with Matt.
<haggai> so I'm doing kdebindings for kubuntu, and also thinking about moving into main.  Am I right in thinking the .debs generated by a source package can straddle main/universe, but all build-deps have to be in main?  My problem is, I want things like python bindings in main but there are java & rugby build-deps that are only in universe
<jdub> haggai: we've split things for this previously (see dbus mono)
* enrico notices that the wiki frontpage displays a Site error
<enrico> jdub: [ping]  bringing docteam documentation in Yelp's front
<enrico> jdub: [ping]  how is your review of the quickguide doing?
<enrico> jdub: [ping]  you wanted to talk with me about the packaging of documentation?
<jdub> enrico: yo
* enrico did his routine jdub pinging for today
<jdub> enrico: it's far more useful to mail me
<jdub> just for future reference
<enrico> I've generally been unlucky in pinging Canonical people on any media
<jdub> very busy, all of us :)
<enrico> Fairly frustrating to me
<Kamion> at least those pings came with a content payload - far too many pings don't, incurring an extra round-trip time :)
<jdub> enrico: email is almost always a better way to ping though
<enrico> Unrelated to pings, the wiki frontpage displays "Site error".  Is anyone aware of it?
<jdub> enrico: yes, being looked at atm
<enrico> jdub: ok, cool!
<pitti> elmo: can I please have libiodbc2-dev in concordia:hoary dchroot?
<fabbione> elmo: can you please kick-back linux-source-2.6.10 -30 on ppc? usual random crash
* pitti releases his 100th security advisory
* fabbione congrats pitti
<Kamion> pitti: happy anniversary
<dilinger> pitti: that's a lot of candles
<pitti> thanks :)
<dholbach> pitti: woohoo!
<fabbione> pitti: and that's only warty!
<fabbione> let's see with hoary.. breezy.. and so on...
<Keybuk> sneezy snail
<pitti> fabbione: I look forward to the time when I have to fix four releases...
<fabbione> pitti: so do i :-)
<pitti> amu, Riddell: did I already forward you the long-outstanding TIFF vulns in kdegraphics?
<pitti> thom: can you install packages into dchroots?
<thom> yes
<pitti> thom: can I please have libiodbc2-dev in concordia:hoary dchroot?
<tseng> jdub: pong
<jdub> tseng: dude
<jdub> tseng: bad news
<tseng> jdub: ya?
<jdub> tseng: beagle 0.0.8 requires a mono micro upgrade
<tseng> ergh
<jdub> more goalpost shifting :)
<tseng> micro = ?
<jdub> 1.0.5 -> 1.0.6
<tseng> um
<tseng> the gentoo maintainer advised against that one
<tseng> and he knows better than I
<tseng> ill see if he has a fix for whatever issue
<fabbione> seb128: ping?
<seb128> pong
<fabbione> seb128: do you live in Paris, right?
<seb128> no, 400km away from here
<fabbione> ah ok.. 
<seb128> ddaa does
<fabbione> bubulle and ddaa do
<fabbione> is ddaa a DD?
<seb128> no
<seb128> why ?
<fabbione> i am searching 2 DD's to sign a key for an NM
<seb128> /j #debian-devel-fr
<Mitario> i everyone
<seb128> hi Mitario 
<Treenaks> hi Mitario 
<Mitario> hi*
<fabbione> seb128: thanks
<seb128> fabbione: on d-d-f there is a bunch of DD from Paris
<seb128> np
<pitti> doko: ping
<thom> pitti: done
<pitti> thanks
* Kamion belatedly attempts to baz get openssh@arch.ubuntu.com/openssh--MAIN--0
<Kamion> this is going to take a while
<Kamion> patch-4058
* Lathiat would think the revisions would be cached somewhere
<doko> pitti: pong
<Kamion> Lathiat: yeah - but it has to go back through all the old signatures while calculating ancestry
<Lathiat> heh heh
<Kamion> Lathiat: cacherev every 50 revisions I'm told
<Lathiat> go arch :)
<Kamion> it's your birthday
* Lathiat laughs
<tseng> jdub: i really wouldnt be happy with a mono core upgrade this late in the game anyway
<tseng> jdub: there no other way?
<jdub> we could backport a fix
<jdub> i wonder what the total diff is
<tseng> that would be cool
<jdub> bad time for bugging #dashboard
<sabmoc> smurfix, what is the german team using for a website/forum?
<tseng> yeah im going to work soon too
<jdub> oh well, later tonight :)
<tseng> yeah this might have to happen over mail now
<tseng> time zones and all
<Mitario> mvo, here?
<dholbach> fabbione: did you look at http://nm.debian.org/gpg_offer.php? kelbert@d.o and treinen@d.o are in paris
<mvo> Mitario: yes
<Mitario> mvo, can we discuss the plan abit for u-m in hoary?
<fabbione> dholbach: thanks.. we already solved :-)
<dholbach> fabbione: ok... rocking :-)
<dholbach> we need such a list for ubuntu as well... it's the main reason that keeps people from MOTUness
<fabbione> it the choise of .fr debian people.. either they sign.. or their X will explode :P
<Mitario> mvo, my idea would be to freeze the code at some day now and let the documenters/translators have some time, and let that release go into hoary
<mvo> Mitario: sure, should be go to /msg for it?
<mvo> (to not spam the channel too much)
<trukulo> tseng, have you seen beagle has released 0.0.8 ?
<tseng> trukulo: yes, I have..
<fabbione> dholbach: good point...
<fabbione> food time
<trukulo> tseng, k, just informing
<trukulo> good morning, everyone, of course
<dholbach> elmo: did you hear my morgue-request yesterday? please (re)move  vdkxdb, chill, cursel, ipmenu, nautilus-media, update, kernel-patch-2.4.25-m68k, kernel-patch-2.4.26-m68k, glademm, torch-examples, libmrproject 
<dholbach> (for the removal of  gcc-2.95  and  gcc-3.2  i'd like to have more adversaries)
<adobbie> 2.95 is still useful for old programs that haven't been updated
<adobbie> not much use for gcc-3.2 imho
<dholbach> well they're not supported anymore :-/
<adobbie> not supported by upstream you mean?
<dholbach> i don't think anyone of the MOTU crew would be able to fix gcc bugs
<pitti> adobbie: do you know a concrete case?
<fabbione> pitti: CAN-2005-0204, i think we should still apply it
<pitti> fabbione: in Warty?
<fabbione> pitti: we don't know for sure that users don't rebuild their kernels with the 4/4G patch
<fabbione> pitti: yes. it is in hoary already
<pitti> fabbione: hmm, okay
<pitti> fabbione: I ask Herbert to patch it (simple patch...)
<fabbione> pitti: exactly
<adobbie> pitti: I have no time to make such a case
<pitti> adobbie: no, I was just curious
<pitti> dholbach: however, if gcc-2.95 has serious issues (does it really? it's there for ages), just drop it
<pitti> dholbach: i. e. if it would be harmful to compile software with it
<dholbach> not harmful, but some packages hard-depend on it and they are all cracked-up, i had an issue somewhere, don't remember, someone advised me to drop it
<dholbach> but it's one of the cases where people might thrash me across the place for :-)
<dholbach> so i wanted adversaries :-)
<svenl> daniels: agp capability removed by the firmware now. The power management capability goes too though, for now, but as we don't support sleep anyway, that should be ok.
<svenl> daniels: will make the cleaner fix next time.
<thom> dholbach: i don't think adversaries is the word you mean to use, there
<dholbach> oh yes
<dholbach> <--- not awake yet
<thom> :-) 
<dholbach> advocates of cours
<dholbach> e
* dholbach blushes crimson
<thom> hey, i have no idea what either advocate or adversary would be in german :-)
<dholbach> thom: i always have   ding <word>   in place :-)
<ajmitch> dholbach: about gcc packages, there are some potential MOTUs with gcc hacking experience
<dholbach> ajmitch: oh nice
<Kamion> elmo: rookery's mirror seems to be wedged again; not updated for over a day
<thom> yo MOTU; should the universe comment in bugzilla tell people to use malone now?
<Treenaks> thom: has it stopped giving out 502's yet?
<froud> mvo: ping
<mvo> froud: pong
<dholbach> thom: tell them to either  1) try malone, 2) drop in #ubuntu-motu, 3) mail ubuntu-users@  :-)
<elmo> err, I need to down jackass (aka ftp-master, aka upload.ubuntu.com), for 10-15 mins... anyone got any major objections?
<fabbione> elmo: not from me
<thom> dholbach: um, choices bad :-)
<thom> dholbach: i'll leave as is
<Treenaks> dholbach: we could change malone's 502 page to one refering to the mailinglist :)
<Treenaks> dholbach: and just refer to malone
<dholbach> yeah... people should try it and file bugs against malone too, if they run into trouble
<dredg> is it me or does the most recent firefox default to a grey background, overriding the specified default of white?
<thom> it defaults to the gtk background, eys
<dredg> ok
<dredg> so if i want firefox to have a different default font and background colour i have to change my theme? despite the fact that there is no way (that i know) to change either of those 2 properties in gnome?
<thom> dredg: just untick "use system colours" in the fonts and colours dialogue
<dredg> gah. didn't see that
<dredg> cheers
<thom> gah, no ccache love makes mozilla compile a slow, slow affair
<Treenaks> dredg: there is a way to change those in gnome: change your theme
<fabbione> elmo: do you have an idea of when sparc.u.c will be up again?
<elmo> fabbione: tomorrow probably
<fabbione> Kamion: we need to check again the way in which ramdisk_size is calculated in d-i
<Kamion> fabbione: yeah, I saw, I'll have a look
<fabbione> Kamion: last d-i upload it was too small for silo/netboot
<fabbione> Kamion: thanks!
<fabbione> elmo: great!
<fabbione> btw.. the installation works like a charm.. 2 errors at the moment.. the keyboard selector doesn't allow "No keyboard connected"
<fabbione> and the missing packages from sparc.u.c
<fabbione> all the other things are working fine
<elmo> Kamion: today's daily okay for testing?
<elmo> (live)
<thom> pitti: evo still builds and runs fine with new mozilla
<thom> pitti: so i'm gonna upload; agree?
<pitti> cool
<pitti> thom: evolution uses mozilla?
<thom> pitti: yeah, libnss3
<pitti> ah, ok
<pitti> is this library affected in the first place?
<pitti> I thought all of the vulns were at higher GUI-levels
<Kamion> elmo: should be
<thom> no, but it's built out of the same package
<thom> and it's the only thing in main that is used by something else, so i needed to check
<Kamion> thom: firefox background> Kinnison says "spank you"
<pitti> thom: okay, thanks for checking this
<thom> Kamion: heh; i'll assume he means it in a good way ;P
<dholbach> seb128: ready to nuke gtkhtml3.{1,2} ?
<Kamion> thom: you know Daniel ;)
<Kamion> thom: ah, he has corrected my spelling to "spankoo"
<thom> heh
<seb128> dholbach: sure
<dholbach> seb128: it's on our cracked-up lists, so i came across it
<dholbach> elmo: would you please morgu-ify gtkhtml3.1 gtkhtml3.2 ?
<elmo> dholbach: can you mail me a list?  I'm busy in the DC atm, sorry
<pitti> seb128: hmm, installing m-f-locale-fr (and -fr-fr) works fine here
<dholbach> elmo: alright, will do
<seb128> pitti: perhaps the guy has installed a package from somewhere ...
<thom> elmo: still working on jackass?
<seb128> pitti: just ignore it if you don't get the bug
<elmo> thom: err, kind of, it  doesn't seem to appreciate being a CD burner
<elmo> thom: should be good to upload ATM tho
<thom> i think you need to kick poppy
<elmo> oh, err yeah
<elmo> done
<thom> yeah, looks good now. thanks
<Kamion> elmo: surprised you didn't use little, since it's got the CDs to hand ;)
<Amaranth> so...what happens when you try to use synaptic or apt-get at the exact moment update-notifier is running apt-get update?
<Kamion> Amaranth: it hits the lock file and errors, I imagine
<zul> hey
<pitti> seb128: ah, you didn't get it yourself?
<seb128> pitti: no, I don't use firefox, I don't even know if I've that installed
<seb128> pitti: that's from a GNOME guy
<pitti> seb128: do you still know the version he upgraded from?
<mvo> Amaranth: you get a message that there is something going on. and update-notifier will set itself to insensible
<pitti> seb128: m-f-l-fr-fr already has a Conflicts: mozilla-firefox-locale-fr (<= 1.0-1)
<pitti> seb128: maybe this is not enough
<pitti> argh, yes
<pitti> it should be <= 1.0.1-1
<seb128> k
<pitti> seb128: so do you know the version he upgraded from?
<seb128> nop
<pitti> ok
<seb128> that's not in the upgrade message he gave me
<seb128> but I think he upgrades his hoary system quite often
<pitti> okay, I tightened up the conflicts/replaces
<seb128> thanks
<elmo> kamion: little has slimline cd drive
<elmo> kamion: and I got > 60Mb/s dl-ing the image to jackass, so having the images locally isn't much of a win ;)
<elmo> Kamion: is the keyboard selector stuff meant to dump me back at the list once I finish pressing keys?
<elmo> or smurfix ^-- too
<fabbione> elmo: yes
<fabbione> it asks to confirm the keyboard
<Riddell> lamont: any idea what went wrong with the two failures here?  http://people.ubuntu.com/~lamont/buildLogs/k/kdelibs/4:3.4.0-0ubuntu3/
<Riddell> one says no /usr/bin/doxygen which there should be
<elmo> it's a very confusing UI
<Riddell> other has problems with libraries
<lamont> Riddell: doxygen is a build-dep-indep, will only be there on i386
<Kamion> elmo: it was pretty confusing beforehand, to be fair; you had no visual indication of what the thing had picked
<lamont> hrm
<Kamion> elmo: so you were left wondering "did I press the right keys?"
<elmo> eh, when I scroll back in less in a gnome terminal, it does this weird thing where it repeats the first line n times (where n is the num of lines on screen), _then_ paints in the previous page.. very visible.  on a very fast machine.  anyone know what that might be?
<Riddell> lamont: how would that effect it?
<elmo> kamion: yeah, but now, I'm left thinking "WTF?  did it crash?" because I get dumped back to the same menu I started at, with no warning/info at all
<Kamion> elmo: yeah, I think it might be better if it dropped you into the test mode immediately and said which keymap it had picked, and then you could select "go back" or "continue" depending on whether it got it right
<elmo> kamion: if the keyboard language line/selection was separate somehow from the other choices, it might be easier
<elmo> + too
<Kamion> mm, could be
<lamont> Riddell: was looking at the ppc log
<elmo> seb128: iz gtk bug?
<lamont> Riddell: will look at it when I get back from taking kids to school.
<Kamion> elmo: mm, I notice that too, it's weird
<Kamion> (just confirmation, no actual information or help or anything)
<seb128> elmo: hum, I don't get this bug here (or I don't understand it correctly)
<elmo> I only see it with gnome-terminal too, xterm is fine
<seb128> what do you do exactly ?
<Kamion> I see it on fresh installations all the time
<elmo> seb128: less /var/log/dmesg, press '>' to go the end, then press 'w' to go a page back up
<elmo> if you have the bug, you'll see exactly what I mean
<Kamion> I think the problem is that the terminal is not an exact number of lines high by default
<Kamion> there's always half a line or so of text at the bottom
<Kamion> because it's fine in Debian where the font/terminal-size combination makes the terminal an exact number of text lines high
<seb128> oh
<seb128> lemme try with an another font, I use "fixed" :p
<seb128> hum, yep, I get it in a gdmflexiserver with a fresh config
<daniels> infinity: Errrrr ... will Saturday do?  I don't think I can download it by tomorrow.
<daniels> svenl: cool, thanks (I assume you just set the first capability pointer to 0x0)
<thom> hrm, we really ought to turn bugzilla's quips off
<Treenaks> thom: why?
<thom> Treenaks: have you *looked* at the list?
<thom> https://bugzilla.ubuntu.com/quips.cgi?action=show
<Treenaks> thom: not too bad, is it
<thom> each and everyone of the last half of the list causes me pain everytime i see them ;-)
<Treenaks> thom: so all we need is a quip moderation system 8)
* thom goes to visit his poorly brother
<thom> have a good easter, folks
<Treenaks> you too
<pitti> thom: you too, have fun
<seb128> have a good weekend thom :)
<seb128> thom: that's no a theme issue, I'm reassigning to firefox :p
<thom> seb128: even though OOo is broken too?
<thom> sorry dude, not my bug
<seb128> have you read the mozilla bug ?
<seb128> they say that's fixed in 1.1
<mvo> have fun thom 
<seb128> (for firefox)
<mvo> (on easter)
<thom> seb128: they also claim world hunger is fixed in 1.1, but i'm not backporting that, either ;-)
<seb128> ah ah
<seb128> I'm not asking to fix it 
<seb128> just don't reassign bugs to the wrong place, I've enough real bugs in my list :p
<thom> so one more won't hurt ;-)
* seb128 slaps thom
<lamont> Riddell: question: what happens when buildd-watcher decides to launch a _second_ buildd?  Answer: your logs.
<lamont> fixed
<lamont> well, 2nd buildd killed./
<Riddell> lamont: why would it decide to do that?
<lamont> Riddell: because it has a bug
<Riddell> pesky beastie
<lamont> buildd-watcher is specifically tasked with starting a buildd if and only if one is not currently running
<Riddell> lamont: are you going to send it back for another compile?
<lamont> already did, but I'll see what else there is and kick them too
<smurfix> elmo, Kamion: I can add an empty line below the current keymap, and maybe add a "Your keyboard:" line before that. Would that help?
<smurfix> I'm a bit hesitant to shunt people to the try-this dialog directly
<elmo> smurfix: I think it might be better, yah
<smurfix> I'll work on it tonight -- need to go shopping + fetch family from airport now :-/
<schweeb> elmo: I've been told I should ask you to whitelist my email
<bob2> where there ever any PPC macs without openfirmware?
<Kamion> bob2: not AFAIK, but some of them (oldworld) had very broken OF
<Kamion> I might be wrong, there may be one or two exceptions
<bob2> Kamion: would sarge work on such a machine?
<elmo> schweeb: done
<Kamion> bob2: no
<Kamion> bob2: er, you said sarge
<Kamion> bob2: "maybe"
<zyga> does acpi stuff works on recent ppc?
<Kamion> bob2: you have to use Sven's miboot floppies for oldworld, or mess with BootX
<Kamion> zyga: powerpc doesn't have ACPI at all
<Kamion> zyga: the power management system is different
<zyga> Kamion: ah
<schweeb> elmo: thx
<zyga> Kamion: is it supported by recent kernels?
<lamont> mvo: you around>?
<zyga> Kamion: I'm planning tu buy a mac and still cant decide mac mini vs ibook
<zyga> s/tu/to/
<Kamion> zyga: yes, it's supported
<Kamion> zyga: suspend-to-disk doesn't quite have userspace support yet, but it's nearly there AFAIK
<bob2> zyga: ubuntu kernels do not yet support sleep on g4 ibooks, tho
<Kamion> works fine on powerbooks
<Kamion> dunno if there's some ibook quirk
<bob2> Kamion: #4759
<Kamion> this sort of thing is often model-specific
<Kamion> bob2: which is, er, RESOLVED/FIXED
<zyga> hmm powerbooks don't have the nifty educational discounts here :/
<bob2> Kamion: oh, oops
<zyga> thanks anyway 
<Kamion> bob2: do keep up at the back ;)
<schweeb> lamont: I can't find which file it's in... it's in this one though, and it's on the MOTOTodo http://people.ubuntu.com/~lamont/buildLogs/Test/Lists/hoary-test.all.i386
<Kamion> zyga: should be fine either way
<bob2> zyga: so, hoary does support sleep on those ibooks now
<schweeb> lamont: and here's the build log http://people.ubuntu.com/~lamont/buildLogs/Test/k/kismet/2004.04.R1-5/kismet_2004.04.R1-5_20050323-1031-i386-failed 
<bob2> Kamion: hah, I've been bugging fabbione for like 4 months now, didn't notice he'd actually done it ;)
<zyga> bob2: that's great to know
<pitti> bob2: works great now
<pitti> bob2: with fabio's latest patch it might even work with DRI
<bob2> oh, cool
<trulux> pitti: how good is a ssp-supported toolchain for you if providing it within Hoary+1?
<pitti> trulux: if it's compatible with the direction that gcc-4.0 goes, it'd rock :)
<trulux> pitti: I was studying the case and definitely, SSP/ProPolice shouldn't be enabled by default in the "default" profile, so, we can end in using profiled gcc installations, which provide "Plug & Play" support for such technologies
<pitti> trulux: however, it has to go through universe first
<trulux> pitti: I have started porting SSP to 4.0
<pitti> cool
<trulux> pitti: I have many work done, just in need of help from a gcc hacker to get rid of the old in_stack related functions, which are now split up or removed
<pitti> amu, Riddell: http://bugs.kde.org/show_bug.cgi?id=102328
<trulux> doko: ping
<pitti> seb128: "gnome-session-remove nautilus" doesn't finish
<pitti> seb128: I already tried this some days ago when debugging g-vfs-daemon
<seb128> are you runnin nautilus in your session ?
<pitti> hmm, I suppose ...
<seb128> if not killlall nautilus is enough
<seb128> it should not respawn
<seb128> try to killall it
<seb128> does it restart ?
<pitti> okay, I did killall, but g-s-r nautilus still hangs
<seb128> ctrl-C
<pitti> still respawns, already tried that
<seb128> that's because it doesn't find a nautilus in the session
<seb128> try the remove again ?
<seb128> that's weird
<pitti> $ pidof nautilus; killall nautilus; sleep 1; pidof nautilus
<pitti> 983
<pitti> 996
<pitti> ah, now it terminates
<seb128> nice :)
<pitti> cool. it's away
<pitti> thanks
<seb128> np
<amu> pitti: thx, worth to add the patch
<lamont> Riddell: everything failed from mcmurdo given back
<Riddell> lamont: I don't see any logs
<doko> trulux: pong
<pitti> seb128: I know the solution
<pitti> seb128: enable debugging by default, then it won't ever happen :)
<seb128> pitti: it works with debug ?
<lamont> Riddell: like 2 minutes ago
<pitti> seb128: no, I could reproduce some of it even with debugging
<trulux> doko: do you have any knowledge on 4.0 changes from 3.4, talking in trms of reg related functions and RTX macros?
<doko> trulux: the right thing for work on SSP is HEAD, not 4.0, then yuo may consider a backport.
<doko> trulux: no
<trulux> I'm working on gcc-4_0-branch
<trulux> from yesterday snapshot
<doko> so why not head?
<trulux> just as specified in the CVS "faq", they recommend to use the development branches
<doko> who is "they"?
<trulux> doko: why HEAD? the trunk shouldn't be that different from the 4.0 branch
<trulux> doko: gcc.gnu.org
<trulux> :)
<doko> trulux: the GCC project never ever had new functionality added in any development branch. HEAD only. I'd say, they won't change their mind for SSP
<pitti> seb128: so, now I have four logs for cp works/fails and rm works/fails
<trulux> doko: no point for that, it's work for Ubuntu Hardened
<trulux> we want to have ready a gcc-4.0 +ssp toolchain
<doko> trulux: "the trunk shouldn't be that different", so why not HEAD?
<elmo> trulux: ubuntu isn't going to adopt it, if it's not adopted upstream
<elmo> (to put what doko's saying into context)
<seb128> pitti: anything interestant in the log ?
<pitti> seb128: yeah, might be
<pitti> seb128: in the failed case, I get "dropped" logs
<trulux> elmo: ask pitti
<pitti> seb128: I just attach all this crap to the bug
<seb128> thanks
<trulux> doko: I will use HEAD, just lemme finish the work with the branch and then make a diff to apply to HEAD
<doko> trulux: :)
<trulux> doko: I'm getting pissed off by the wanker who changed the place of *_into_stack_*() functions :D
<Riddell> lamont: how come there's no new build logs for kdelibs if it's failed?
<daniels> mdz: right ... i haven't slept near enough yet and continuing to stay awake to work on this is just overall detrimental (zombified when I could be sleeping such that I can work properly when I wake up).  i'm going to post a copy of my latest xorg source on chinstrap; totally untested, but should work and quash most of the debconf bugs.  i810 is an exercise for later.  need to sleep now; will just babysit this through patch application, t
<lamont> Thu Mar 24 15:58:52 GMT 2005
<lamont> kdelibs_4:3.4.0-0ubuntu3_20050324-1544   00:34:23 (2 entries, sigma 00:00:41)
<lamont> because we're 14 minutes into a 34 minute build...
<lamont> and I just tossed the ppc build back into the fray as well.
<lamont> and that'll be a 38 minute build or so, once it actually starts
<Riddell> lamont: oh, I misread what you wrote above, ignore me, I'll be patient
<lamont> damn instant-gratification generation, anyway.... :-)
<Kamion> daniels: cut off at "patch application, t"
<daniels> mdz: http://chinstrap/~daniels/, making its way up now
<daniels> Kamion: thanks
<daniels> Kamion: 'then put sources up'
<zul> bbl
<daniels> ok, it's up now; g'night all
<daniels> mdz: (but do *not* upload; there's a neat little corner case related to $MONITOR_SYNC_RANGES that will bite us in the arse if -6 as it stands ever hits the archive)
<seb128> pitti: the gamin issue happens only on the desktop ?
<pitti> seb128: in contrast to?
<seb128> hum ?
<seb128> does it happen in ~/bar by example
<seb128> or is that ~/Desktop specific ?
<seb128> ie: is there general monitoring broken
<seb128> or only for the Desktop dir ?
<seb128> there is a comment from Jeff saying:
<seb128> "communicating changes (not sure which). The bugs are filed about the desktop,
<seb128> because that's where we see most file change notification take place."
<seb128> 
<Burgundavia> it also happens on in home about 2 times out of 3
<seb128> pitti: dpkg -l | grep gamin ?
<pitti> seb128: ah, I see
<pitti> seb128: gf alert here, will do this later
* Kamion hands seb128 a "useless use of grep" award :)
<mdke> lol
<schweeb> Kamion: not necessarily, depends what you're lookin for :p
<schweeb> dpkg -l gamin wouldn't show libgamin
<schweeb> although you could use *gamin*
<pitti> ii  gamin                    0.0.26-0ubuntu1          File and directory monitoring system
<pitti> ii  libgamin-dev             0.0.26-0ubuntu1          Development files for the gamin client library
<pitti> ii  libgamin0                0.0.26-0ubuntu1          Client library for the gamin file and directory monitoring syste
<pitti> seb128: ^
<Kamion> schweeb: \*gamin\* is indeed what I meant
<seb128> and here you reloged with the new version ?
<Kamion> schweeb: (it's even better than using grep - dpkg -l assumes 80 columns when writing to a pipe, unless you explicitly set COLUMNS)
<seb128> Kamion: too lazy to enter 2 "\"
<seb128> need to altgr to get them :p
<zyga> anyone related to gstreamer around?
<Kamion> seb128: your keymap sucks :-)
<seb128> Kamion: ah ah
<Kamion> whew
<Kamion> I think I've committed all of my debian-cd changes in nice little separated chunks now
* pitti goes for a round of table tennis, cu later
<seb128> have fun pitti 
<dholbach> see you later
<_d4vid> hi all
<Mitario> hey again everyone
<mvo> hey, welcome back Mitario 
<svenl> daniels: yep. i just set the first capability pointer to 0. for now, i want to do the proper thing, but i have no static memory in the rtas callback, so it is not all that easy. For next time.
<mdz> morning
<mdz> seb128: my panel crashed overnight again
<ogra> morning mdz
<mdz> seb128: different stack
<mdz> the stack is pretty crazy
<mdz> seb128: this is after moving my ~/.recently-used as you suggested
<seb128> mdz: I've spoken with Vincent about that yesterday, he has not real idea of what could happen
<seb128> the backtraces are weirds
<mdz> my panel has a system monitor, workrave, and weather
<mdz> and then gaim and the mixer have notification icons, and of course the clock
<seb128> he thinks that maybe some gamin events are arriving hours after the action
<mdz> it's strange that it never happens while I am here
<seb128> does it happen when you use your computer sometime ?
<mdz> :-)
<seb128> bah
<seb128> does it happen without the notify area or gaim ?
<mdz> gaim was not running this morning, but there was no crash dialog for it
<mdz> so I may not have left it running
<mdz> I've been rebooting, etc. to test things and am not sure that I connected this time
<mdz> I have some errors in ~/.xsession-errors
<mdz> The program 'gaim' received an X Window System error.
<mdz> This probably reflects a bug in the program.
<mdz> The error was 'BadWindow (invalid Window parameter)'.
<seb128> mdz: gaim does that when the panel crash :/
<seb128> mdz: ie: killall gnome-panel and you get that error
<mdz> ah
<elmo> Kamion: live CD on powerpc started by SW RAID - it didn't on amd64... bug?
<mdz> elmo: what sort of device is the SW raid on?
<Kamion> elmo: "started by SW RAID"?
<elmo> mdz: SATA
<elmo> kamion: s/by/my/
<seb128> mdz: any opinion on https://bugzilla.ubuntu.com/7927 ? That's OO.o/firefox beeing broken with the Simple theme
<Kamion> elmo: I guess so (bug), yeah
<Kamion> mdz: the live CD does do mdrun on startup, doesn't it?
<Kamion> elmo: would be worth checking what /dev/md* / /dev/md/* devices are there
<elmo> /dev/md0 is there
<mdz> Kamion: the live CD does S25mdadm-raid
<seb128> mdz: I think we should just ignore it for hoary. The guy is complaining but that's not a widely used theme and not a gnome-theme bug
<mdz> which runs after hotplug
<elmo> (which is / in the installed system)
<mdz> so in theory it should work
<mdke> seb128, that theme is quite dodgy imo
<mdz> seb128: I agree
<mdke> seb128, you can't read the progress bars either
<mdz> seb128: unless you want to remove the theme
<seb128> no I don't :)
<mdz> elmo: does an explicit sudo /etc/init.d/mdadm-raid start work?
<elmo> mdz: on which arch?
<mdz> elmo: the one where it isn't started
<elmo> oh, I was assuming it wasn't meant to start
<elmo> mdz: I dunno, I'll reboot concordia in a sec
<mdz> it's meant to start
<seb128> mdz: http://bugzilla.ubuntu.com/show_bug.cgi?id=7911, any idea ? kernel issue ?
<ogra> seb128, hmm, a lsmod output would be interesting...
<mdz> seb128: cdrecord sucks
<mdz> either cdrecord or kernel
<mdz> seb128: I have a USB DVD burner which works perfectly for DVD with growisofs and nautilus, but cdrecord doesn't work at all
<seb128> mdz: k
<seb128> ogra: feel free to comment on the bug if you have an idea :)
<ogra> yop, just writing
<seb128> thanks
<mdz> seb128: I think that cdrecord notices that it is a DVD burner and then intentionally breaks CD burning in order to try to get you to buy his DVD burning software
<Mitario> mvo, wb!
<Mitario> mvo, help button is in CVS ;-)
<mvo> Mitario: thanks, you rock!
<seb128> mdz: rofl
<Mitario> mvo, tell me when we're ready to freeze!
<Mitario> oh, i hate it when I can't work on trashapplet..
<dholbach> re
<koke> IIRC, there are plans to run synaptic as user, and separate the root part?
<mvo> koke: it's something I would like to do, yes
<koke> great
<koke> is there any way before that to make synaptic use the user configuration, like "text next to icons"??
<mvo> koke: not in a sane way
<mvo> koke: the theme is one issue, but the proxy settings are way more anoying 
<koke> mvo: anyway, the gui part should run as user
<koke> the problem here is that I'm on a 800x600 desktop
<koke> and the toolbar is too big
<ogra> mvo, so lets go insane ;)
<koke> actually, all is too big :P
<mvo> koke: yes it should, but it doesn't right now
<ogra> mvo, i mean, it would be possible to read the gconf and gnome settings from the calling user....even if it runs as root
<koke> mvo: has someone started to code it, I'd like to help
<koke> even not knowing c++ :)
<mvo> koke: it's something for breezy. noone is working on it right now. it shouldn't be too hard, but there are a lot of corner cases 
<mvo> koke: I have a 800x600 testmachine, it's not _that_ bad :)
<koke> mvo: even 1024x768 is too low for me :)
<mvo> koke: you can use "Settings/Toolbar" to make it "Text beside icons"
<mvo> ogra: it is possible, but it's a can of worms
<koke> mvo: yep, I've done that
<koke> but synaptic runs as root
<mvo> koke: synaptic has a "Settings/Toolbar" in it's menu :)
<koke> mvo: aahm, ok
<mvo> koke: what other areas do you find to big?
<koke> mvo: all :P
<koke> I'm using 800x600 in a 17''
<koke> mvo: anyway the "target users" of this computer haven't very good vision :D
<koke> ogra: just like http://www.grawert.net/weblog.cgi/2005/03/12#2005-02-12_21:46:04_Our_virtual_grannys :P
<ogra> hehe :)
<ogra> koke, blame my girlfriend
<pitti> back
<seb128> mdz: about the panel crash, what does the bt looks like ? Similar to the previous one ?
<mdz> seb128: I mailed it to you
<mdz> it's nonsense though
<seb128> oh, right
<seb128> utch, what's that
<pitti> Hi mdz 
<dross> who here is knowledable with laptops?
<pitti> seb128: the gamin bug is almost worse with other directories
<dross> ide: failed opcode was: unknown
<dross> hda: task_in_intr: status=0x51 { DriveReady SeekComplete Error }
<dross> hda: task_in_intr: error=0x10 { SectorIdNotFound }, LBAsect=156296166, sector=156296166
<pitti> seb128: in any case it fails after a couple of tries
<dross> ubuntu spits that out at me about 8 times in a row at boot. Hardware or software problem? (80 gig drive)
<mdz> dross: most likely hardware
<dross> mdz: any way to tell?
<mdz> dross: #ubuntu, please
<ogra> bradb: ping
<dross> mdz: this isn't a generic question.
<bradb> ogra: hi
<dross> mdz: I'm asking here to know if its kernel related. 
<seb128> pitti: 
<seb128> <DV> seb128: I can't make sense of this problem
<seb128> <DV> seb128: except maybe if the client uses a version 0.0.24 and the server is > 0.0.25
<seb128> <DV> seb128: they must delog/relog after the latest gamin update and try to reproduce the problem
<ogra> bradb, hi, sabdfl told me i could announce malone on the ubuntu-users ML after your "GO"
<seb128> pitti: you have reloged I guess ?
<bradb> ogra: hm
<pitti> seb128: you mean after the 0.0.26 update?
<seb128> yep
<bradb> ogra: i want to be careful about jumping the gun. ubuntu-users is a large audience.
<pitti> seb128: sure, I reboot every day
<seb128> hum, k
<mvo> koke: :)
<ogra> bradb, i'm patient.... just tell me if youre ready to go....
<bradb> ogra: i'd rather rely on word of mouth for the time being, i think. after a week or two of MOTU usage, then maybe we hit ubuntu-users. what do you think?
<ogra> bradb, sure, your baby :)
<bradb> ogra: plus, i think mdz plans to leak it on the Ubuntu bugzilla
<mdz> bradb: just as soon as I can get you jokers to agree on a URL
<ogra> bradb, dont get me wrong, i dont want to push you
<mdz> and actually let people log in ;-)
<dross> oh boy..
<bradb> ogra: i really want 24 hours of admin availability too, which means salgado needs to be 100% ready to take on that responsibility.
<dross> mdz: nevermind. I think the partitioner was confused and partitioned a label past what the size of my drive is
<bradb> mdz: i guess you have to ask sabdfl. i think my URL is the best one to use right now, but mpt decided to complicate matters. :P
<ogra> bradb, ok, i'm _patiently_ waiting until you blow the horn, was just a question, dont feel pushed
<bradb> ogra: sure, i'll let you know.
<ogra> :)
<mdz> bradb: what about logging in?
<bradb> registering, you mean?
<mdz> bradb: that would be a prerequisite, yes
* bradb asks mpt
<mdz> bradb: people are already lining up on -users to use malone; it's leaked
<bradb> leak means people have found out about it. an announcement means we're /ready/ for it. :)
<bradb> we're not ready for an announcement yet.
<bradb> case in point: we slashdotted Malone in the MOTU demo. (those problems are fixed now, IIUC.)
* mvo has a appointment now, bbl
<bradb> mdz: as for registering, mpt has a fix for that, he says, so the workaround of having to sign up via the plone site should be very temporary (like a matter of a couple days, one would hope)
<fabbione> hey mdz
<fabbione> mdz: we are go with -31 if nothing special will show up
<bradb> mdz: the bug filing link will be https://launchpad.ubuntu.com/distros/ubuntu/+bugs then
<bradb> well, the Ubuntu bugs home page, that is (+filebug is the actual bug filing screen)
<elmo> mdz: sigh, sorry, my bad - it does start on amd64, I got confused by the "md0: stopped" msg in dmesg, and difference in loudness (amd64 is just one line of "Starting RAID", powerpc was like half a screen of the md auto-detect crap
<pitti> fabbione: still no ppc sleep with enabled DRI with -31
<pitti> fabbione: or, rather, no resume
<fabbione> pitti: tought luck..
<fabbione> we did our best
<pitti> fabbione: sure, thanks for that
<pitti> fabbione: I do have sleep/resume without DRI, that's perfect for me
<fabbione> ok :-)
<pitti> fabbione: I don't play tuxracer so often :)
<fabbione> eheh
<pitti> fabbione: the sleep patch rocks :)
<pitti> cu guys, have nice holidays!
<seb128> same for you pitti 
<dredg> so long pitti 
<ogra> bye pitti 
<pitti> and don't cause me a bad conscience because all of you are still working !!! :-)
* lamont wanders off for a few
<elmo> is there a side-by-side diff program?
<trulux> doko: http://pearls.tuxedo-es.org/patches/gcc-4.0/ssp-propolice.patch
<mdz> elmo: diff -y
<elmo> aha, thanks
<mdz> Kamion: what do you think about starting the RC test cycle on Monday?
<mdz> seb128: do you know when you'll be finished with 2.10.1?
<Kamion> mdz: fine by me, modulo Xhosa translation stuff
<mdz> Kamion: that's due Monday, yes?
<Kamion> yup
<ogra> elmo, koke (Jorge Benal) was approved today, he sent you the key 
<elmo> ogra: has he done the dance with mako?
<ogra> elmo, he was approved as mamber in the last CC meeting, so i guess yes
<ogra> member even
<ogra> koke ^^
<koke> I think he comfirmed that in the community council
<mdz> ogra: the new process is that mako checks credentials, etc. and then passes a list to elmo to process
<koke> I really have to go now, please check the logs
<koke> thanks to all
<mdz> ogra: so if it is not in that list, prod mako
<elmo> ATM, he's not
<dholbach> mako: ping
<ogra> mdz, yeah, i'll do....time was a bit short between the two dates ;)
<koke> elmo: actually I sent it
<koke> what I can't remember is if he comfirmed he'd received it
<ogra> koke, yup, but makos forwarding to elmo is required
<ogra> koke, so we may have a little delay
<koke> ok, I'll be back later
<koke> bye
<ogra> bye koke, and welcome aboard again
<ogra> grr, must get quicker...
<Burgundavia> elmo: ping
<dholbach> daniels: ping
<mdz> jbailey: so are there any unresolved cases left for #1440, or are we finally rid of it?
<jbailey> mdz: I'm waiting for a final confirmation of the install actually finishing.
<jbailey> Then I will burn it in pit and dance naked around it in the moonlite while chanting.
<lamont> wth is /etc/gshadow?
<jbailey> lamont: For group passwords.
<lamont> doh
<zul> jbailey: heh..
<nohar> jbailey: do you maintain libc6 ?
<nohar> i am going to be annoying :)
<jbailey> nohar: Notwithstanding that we don't have a real concept of a sole maintainer, I'm one of the people insane enough to care for it...
<nohar> ok :)
<nohar> i am trying to fix a bug i found
<nohar> which is very annoying for PaX users
<nohar> that is in libc6-i686
<nohar> i do believe it is nptl related
<nohar> hear about such a bug ?
<jbailey> Probably.  It's not like PaX and various apps not playing along well is an unheard of idea. =)
<nohar> well :)
<nohar> i have no problem with apps i use
<nohar> but with ubuntu the system is unusable
<nohar> not even bootable
<nohar> apt-get remove lib6-i686 and the system works like a charm
<nohar> (and this totally rox)
<jbailey> nohar: I need error messages to be of any real use to you.  Do you know how to setup a chroot?
<nohar> yes of course
<nohar> but that's what annoying
<nohar> the only message is segfault :)
<nohar> i tried to strace to locate the bug
<jbailey> Well, I didn't want to assume. =)
<ogra> jbailey, could you take some pictures from the dancing ? i'd like to put them on planet.ubuntu.com
<nohar> ok
<jbailey> For segfault, the only asnwer is probably gdb.
<nohar> and to me, it occures in init() of the tls libc
<jbailey> Does it segfault at startup?
<nohar> yep :)
<jbailey> Hmm.
<nohar> it's definitely while loading libs
<jbailey> nohar: Has this always happened, or did it start recently?
<nohar> i don't this it's ld.so even though i am not 100% sure
<nohar> i tried ubuntu only lately
<nohar> i shoud try older libc packages
<nohar> goot idea
<nohar> see, you already helped me :)
<jbailey> lately is how recently, btw?
<jbailey> Do you mean in the last day, or, say, a few days ago?
<nohar> last week
<nohar> oh a new libc package :)
<nohar> let's try
<jbailey> Oh good.  I had touched the linker code in the upload yesterday morning and wanted to make sure that there was no chance of this being a new bug from that.
<nohar> that's not that
<nohar> well same thing
<jbailey> nohar: Are you on the system without libc6-686 right now?
<nohar> i am on a sid :)
<nohar> i chroot in a ubuntu
<nohar> and i move /lib/tls/i686/cmov out of the way
<nohar> i ma installing libc6-i686_2.3.2.ds1-13ubuntu2.2_i386.deb
<jbailey> I'm curious for you to do an ldd /bin/ls, and tell me which libpthread it's using when libc6-i686 isn't present
<nohar> sure
<nohar>         libpthread.so.0 => /lib/tls/libpthread.so.0 (0x27294000)
<jbailey> 'kay.  Then it's not an nptl issue.
<nohar> ok
<jbailey> nohar: Can you message me the output of cat /proc/cpuinfo ?
<nohar> and flood :)
<nohar> hum
<nohar> how can i debug this
<nohar> i am short of idea
<jbailey> Erm.  I didn't think that k7's were supposed to play along with the 686 libraries.
<elmo> they're not
<nohar> damn
<nohar> well
<nohar> very wierd it's only crashing with a pax kernel
<nohar> jbailey: the loader is supposed to automatically chose the proper libc  to load ?
<nohar> ah gf calling
<jbailey> nohar: Yes.  But I see on my k7 box here that it's using tls/i686/cmov libraries too...
<nohar> i figured that was normal since i had no probs with the default kernel
<mdz> elmo: /dev/shm/root is odd
<nohar> i really would like to understand this one...
<nohar> i have to eat ++
<nohar> thanks for your time jbailey :)
<elmo> mdz: it then errors out and dumps me at "enter root password" to continue prompt, but isn't accepting what I'm 99% sure is the right password
<jbailey> nohar: I can't offer you anything that will help you understand it quickly.  Basically you'll need to static link with debug symbols, start somewhere in _libc_start and walk through the disassembled instructions.
<jbailey> nohar: The C code is unlikely to be enlightening.
<elmo> mdz: it's not a CD in the drive tho (I'm on crak OF wouldn't boot off it)
<nohar> i will
<Burgundavia> elmo: did you get my (corey Burger) email regarding whitelisting my email addy?
<mdz> elmo: massive filesystem corruption?
<elmo> mdz: yes, suspect so
<elmo> oh, to the point of /etc/passwd being hosed..hmm
<mdz> yeah
<mdz> init=/bin/sh?
<elmo> Kamion: how do I get yaboot to stop, so I give it arguments?
<mdz> it doesn't pause by default?
<jbailey> elmo: Mine just pauses..
<mdz> I thought it did
<elmo> nm
<elmo> mdz: I didn't see one on last reboot
<elmo> but just holding a random key worked :)
<elmo> okay find / when C-c doesn't work sucks
<mdz> why is it that someone renames FrontPage in the wiki every other week?
<elmo> mdz: maybe we should ask sm to acl it so they can't?
<bluefoxicy> dammit, I can't find an RFC for tar.  Nevermind then.
<mdz> elmo: if it's possible, sure
<Kamion> elmo: the pause is 5 seconds by default, or 10 seconds if there were other OSes installed
<sm> I was thinking that this morning and forgot.. will do
<ogra> wasnt that done when we switched to the plone wiki
<Kamion> elmo: but maybe it takes that long for the prompt to appear or something
<mdz> jbailey: is @euro the problem in http://bugzilla.ubuntu.com/show_bug.cgi?id=8155 ?
<Kamion> ogra: haha, you're assuming zwiki has features
<ogra> heh
<sm> trouble is, I'm not sure it's the right version 
<ogra> Kamion, iirc someone told so
<ogra> :)
<sm> to lock
<Kamion> mdz: .UTF-8@euro is harmless apart from being pointless; it's identical to .UTF-8
* bluefoxicy wanted to get information to write an RFC describing a .deb based on the RFC for gzip/bzip2 and tar, though there seems to be no tar RFC, nor bzip2, but a gzip one
<Kamion> mdz: although I suppose it might confuse the odd thing that does textual parsing of locale names
<mdz> Kamion: in #8155his applications seem to be acting as if they don't grok UTF-8
* sm simply disables FrontPage delete button
<bluefoxicy> none of the package formats (tgz, deb, rpm) have an RFC o.O
<bluefoxicy> at all
<Kamion> mdz: sounds to me as if the shell's locale is UTF-8 but the terminal's is not
<mdz> bluefoxicy: not every file format is an IETF standard; this is not a bug
<Kamion> mdz: *something* is generating UTF-8 or he wouldn't be seeing that at all
<bluefoxicy> mdz:  true.  I just like standards
<Kamion> RFCs are not the only kinds of standards :)
<Kamion> I'd be kind of surprised to find very many file formats standardised in the same medium used for Internet protocols, TBH
<bluefoxicy> Ogg has its own RFC
<Kamion> ogg is streamed over the net
<jbailey> mdz: No, that shouldn't be it at all.
<bluefoxicy> Kamion:  and gzip, and zlib too :)
<Kamion> bluefoxicy: *shrug* who cares :)
<haggai> mdz: kdebindings has been problematic - it build-deps on python, perl, java and ruby, and the last two are only in universe.  I've ripped those out for now but now we have less functionality..
<dholbach> haggai: can't you package those just for universe?
<haggai> dholbach: yeah that's my worst-case option
<mdz> that would require splitting the source
<haggai> exactly
<dholbach> haggai: or do you need them in main?
<dholbach> ah ok
<mdz> haggai: which Java does it use in universe?
<bluefoxicy> Kamion:  yeah, it wouldn't help third party vendor support, seeing as different distros will have different "x11-common" "xserver-xorg" vs "x-common" "x-server-xorg"  or "gnome-desktop" versus "gnome-desktop-environment" etc
<elmo> Couldn't find ext2 superblock, trying backup blocks...
<elmo> fsck.ext3: Bad magic number in super-block while trying to open /dev/sdb3
<haggai> mdz: it needs javah, and to satisfy that it looks like I need gcj 4
<elmo> yet, I can boot in init=/bin/sh mode and the FS looks fine?
<bluefoxicy> Kamion:  that's really the only reason for standards anyway; to get all third parties on the same page
<Kamion> bluefoxicy: that's why the LSB packaging format exists, and why we support it
<Kamion> bluefoxicy: creating another standard because you don't like the existing standard seems particularly perverse in the case where there's currently only one plausible one :P
<jbailey> mdz: Those two characters show up for  when you've got something displaying as latin-1 the character that's really encoded as utf-8
<mdz> jbailey: yes
<elmo> hmm.. because the kernel's booting of /dev/sd_a_3 ... fascinating
<ogra> uuuh
<zul> elmo: huh?
<elmo> zul: /etc/fstab says /dev/sdb3, kernel says /dev/sda3
<Kamion> mdz: 'ps axewww' would find the locales that all processes think they're in
<zul> elmo: wieeeerd
<Kamion> elmo: wrong yaboot.conf?
<elmo> kamion: give sdb3 doesn't have any ext2 superlblocks, I think right yaboot.conf :)
<mdz> Kamion: seems like a kubuntu-specific problem based on this discussion, so I'm no longer directly concerned about it
<Kamion> elmo: 'k :)
<mdz> haggai: those deps are new in 3.4?
<mdz> oh, no, kdebindings is in universe
<haggai> mdz: yes its in universe and I want to try to get at least the perl/python bindings in main
<haggai> and javascript.  I've got those three all packaged seperately already
<mdz> haggai: we've managed to dodge ruby so far; I think vim is the only thing in main which wants it and doesn't get it
<mdz> it wouldn't be the end of the world to start supporting it, but it seems silly to support a language platform just to build bindings for it
<haggai> mdz: right, so I think the decision I made (pull ruby/java for now) was probably as good as I could
<mdz> haggai: no way to use gcj-3.3?
<haggai> there is no javah
<seb128> mdz: about 2.10.1, tarball are due on 4th of april
<elmo> giggle
<seb128> mdz: I guess they will roll tarball 4-5th 
<mdz> haggai: classpath-tools  and kaffe have it, but they're not in main either
<haggai> mdz: exactly
<seb128> mdz: so probably 5th april in the afternoon UTC
<mdz> seb128: the whole reason for the week between RC and final was to get 2.10.1...
<haggai> mdz: I suppose if I'm going to the effort of splitting out ruby it isn't much more to move java too..
<mdz> seb128: and 2.10.1 is coming out after RC?
<seb128> mdz: 4th april tarball, 6th april 2.10.1
<seb128> mdz: that's the GNOME schedule according to jdub
<mdz> that completely undermines our release candidate
<mdz> there isn't any point in doing it without 2.10.1
<mdz> "release candidate" = "we're not changing anything else unless we fucked up"
<seb128> that's the same situation as for warty IIRC
<mdz> I know, that's why we CHANGED it for Hoary :-)
<mjg59> Ah!
<ogra> oh
<nohar> hey jbailey 
<nohar> i said something wrong
<mjg59> jbailey: Around?
<nohar> the libpthread used is the one in i686/cmov
<mjg59> jbailey: I think we need fan and thermal modules in initrd
<jbailey> mjg59: Yup
<jbailey> mjg59: Umm..  You're kidding right?
<mjg59> jbailey: On resume from disk, we have the potential for heavy CPU load
<Kamion> mjg59: er, I thought we shoved them in pre-warty
<mdz> Kamion: we did
<mjg59> Kamion: Ah. Hang on, let me check this.
<Kamion> initrd-tools (0.1.70ubuntu4) warty; urgency=low
<Kamion>   * Load thermal and fan support (Warty: #489)
<Kamion>  -- Thom May <thom@planetarytramp.net>  Fri, 27 Aug 2004 16:58:37 +0100
<mjg59> Do they get loaded before or after resume from disk is triggered?
<seb128> mdz: 
<seb128> mar 23 15:07:06 <seb128>        jdub: when is planned GNOME 2.10.1 ?
<seb128> mar 23 15:08:01 <jdub>  seb128: april 4th/6th
<seb128> mar 23 15:08:20 *       jdub pokes tongue out at seb. :-)
<seb128> mar 23 15:08:40 <jdub>  i was wearing my gnome hat when i scheduled that ;)
<seb128> mdz: I've my informations from here
<mdz> mjg59: loadmodules is processed before swsusp resume, looks fine
<mjg59> mdz: Hm. Right.
<mdz> seb128: I believe you; I'm saying that it's a fuckup
<seb128> agree
<mjg59> mdz: Oh, ugh, I think I might understand what the trouble is then
<seb128> mdz: do we want to package 2.10.1 or not ?
<mdz> seb128: not the day of release, no
<seb128> mdz: we probably do from a QA point of view
<mdz> I do not want to go through that again
<seb128> there is a bunch of fix in the current CVS than we want for hoary
<Kamion> from the QA point of view it's a trade-off surely
<seb128> we have the option to backports them
<mjg59> jbailey: Ok, I think we're hitting a potential issue when fan and thermal are loaded, and then we resume a kernel that has different ideas about thermal state
<seb128> or to package 2.10.1 tarballs
<Kamion> last-minute fixes are a QA loss; not having those fixes is a QA loss
<mdz> if they're in CVS, and we want them for Hoary, they need to go in now
<seb128> tracking the CVS take time
<jbailey> mjg59: Ah, so fans stop running that ought to be?
<seb128> which could be used to fix bugs while waiting on 2.10.1 tarballs
<seb128> what we did for warty
<mjg59> jbailey: In this specific case, the machine resumes and shortly afterwards kacpid goes into a tight loop processing acpi events
<Kamion> mdz: mm, "not changing anything else" => that was why I wanted to check with you about stuff like late installer translations ...
<mjg59> I think because a thermal trip event has happened at some point in the intervening period
<Kamion> the other day
* mjg59 tries to work out the right way of doing this
<mdz> Kamion: didn't we agree on the 28th as a deadline?
<mjg59> Can we try loading fan and thermal /after/ resume from disk?
<mdz> at least for non-langpack stuff
<seb128> Kamion: speaking about translations for the installer, the template is correct now ?
<mdz> mjg59: then don't we run into the problem that you first thought it was?
<jbailey> mjg59: That doesn't make sense to me, though.  After resume from disk the modules should already be loaded, shouldn't they?
<jbailey> mjg59: From the initial boot up.
<Kamion> 16:11 < Kamion> mdz: what's your opinion on the last date when I could upload installer translation changes for hoary?
<Kamion> 16:11 < Kamion> mdz: the Xhosa team are working to quite a tight deadline
<Kamion> 16:12 < Kamion> mdz: ok; I'll try to get as much in before that time as possible
<Kamion> 16:12 < Kamion> mdz: as far as I'm concerned any time up to two days before release is possible, but I wanted to check
<Kamion> 16:12 < mdz> Kamion: fine by me
<mjg59> jbailey: The hardware state will be inconsistent with what the kernel thinks
<mjg59> The thermal code will have fiddled with registers before the old kernel comes back
<Kamion> seb128: not quite, rookery's mirror is out of date which makes it kind of hard to update it
<mdz> Kamion: I must have mis-parsed "release" as "release candidate"
<jbailey> mjg59: So are you thinking onload the thermal driver on suspend, load it once in the initrd, load it again on resume?
<seb128> Kamion: please ping me when that's fine
<mdz> Kamion: but even so, translations are a different story from new upstream code
<mjg59> jbailey: Urgh, that sounds bad too.
<mdz> we've said that we'll update translations even after release
<mjg59> I think this is probably a situation where we need to be *exactly* compatible with Windows
<mdz> though no particular plan to implement that has ever taken shape
<Kamion> mdz: could you follow up to Adi about that? I think she's now under the impression that her deadline is looser, although I did try to impress on her the importance of getting them early
<jbailey> mjg59: Do tell. =)
<Kamion> mdz: of course that isn't possible for the installer
<Kamion> seb128: yes, will do
<elmo> mdz: language-pack uploads to warty-updates?
<smurfix> Kamion: btw, I just fixed up some of the Xhosa bit in kbdchooser
<mjg59> jbailey: Ok. ACPI has _WAK methods, which are called if you use the platform method to suspend the machine.
<elmo> err, hoary-updates
<mdz> elmo: which nobody uses
<mdz> we don't even enable it by default
<Kamion> seb128: I plan to mail ubuntu-devel and/or ubuntu-users and/or rosetta-users once I have a hopefully-final template
<elmo> whine
<mdz> we don't even put it in sources.list commented out
<mjg59> In principle, they should resynchronise kernel/hardware state
<Kamion> smurfix: mm, what was broken with it?
<elmo> whine whine whine
<elmo> can we not fix that?
<smurfix> Translating "Atari keyboard" to "USB" didn't strike me as correct
<elmo> that's why we do the horrible abuse of -security with the calendar
<seb128> Kamion: cool
<elmo> smurfix: hahaha
<Kamion> mdz: beg pardon?
<Kamion> ## Uncomment the following two lines to fetch major bug fix updates produced
<Kamion> ## after the final release of the distribution.
<Kamion> # deb http://$HOST$DIR $DIST-updates main$NONFREE
<Kamion> # deb-src http://$HOST$DIR $DIST-updates main$NONFREE
<elmo> woo
<mdz> oh, ok
<Kamion> elmo: I would fix it if hoary-updates existed and worked :-P
<mdz> Kamion: do we enable those along with the other network repositories?
<mdz> ah, guess not hen
<mdz> then
<elmo> kamion: eh?
<mjg59> hoary-updates currently doesn't seem to exist
<Kamion> $ HEAD http://archive.ubuntu.com/ubuntu/dists/hoary-updates/
<Kamion> 404 Not Found
<mjg59> If you enable it, apt complains
<elmo> oh, boggle
<elmo> well y'all suck for not telling me. lalala
<Kamion> smurfix: *grin*
<Kamion> elmo: I'm sure I bitched about it pre-warty for warty-updates, assumed you'd got the message :P
<mjg59> jbailey: Ok. So, we have fan and thermal loaded. They work. The machine is suspended. We reboot. Fan and thermal are loaded, and possibly fiddle with hardware state. We resume. _WAK methods are called, and in theory resynchronise the kernel and hardware state. Everything then works.
<mjg59> Except that, uh, it doesn't.
<Kamion> smurfix: um, confused; there's no "Atari keyboard" msgid in kbd-chooser
<mdz> I wonder if synaptic provides a proper description for hoary-updates
<mjg59> On this hardware, at least.
<elmo> mdz: btw, when do we want breezy?  post-release?
<mdz> elmo: breezy is next month's problem
<elmo> ok
<mdz> I don't even want to hear the word breezy for 2 weeks
<elmo> well.. I need to do something about ia64 and sparc
<mdz> not even in high wind conditions
<elmo> well, err ia64 anyway
* dholbach comforts mdz and hands him a cup of tea
<elmo> I mean presumably we don't want it left in hoary?
<mdz> ia64 is even less interesting than breezy for the next 2 weeks
<smurfix> Kamion: ../keyboard-atari.templates:3
<mdz> elmo: if you want to move ia64 to a different directory, that's OK by me
<Kamion> smurfix: which appears to be missing from templates.pot, and so is not in xh.po
<Kamion> smurfix: I think you're seeing a fuzzy translation
<mdz> very fuzzy
<smurfix> Kamion: grumble
<Kamion> please don't tell me the templates.pot differs depending on what architecture you use to generate it
<elmo> mdz: well leaving it in hoary gives the wrong impression, don't you think?
<Kamion> mdz: fuzzy translations are never displayed, so ...
<mdz> elmo: so does putting it in breezy, frankly
<mdz> elmo: it wants to be on ia64.ubuntu.com
<elmo> oh.  ok.
<Kamion> smurfix: shall I fix? I have the full xh translation file here
<koke> Mitario: there are .svn dirs in gnome cvs (update-manager) at help/C and help/C/figures
<Kamion> smurfix: kbd-chooser/debian/po/xh.po is just an automatic excerpt from it
<smurfix> Kamion: ah, that explains it
<mdz> elmo: unless you want to merge sparc and ia64 into some pre-release-architectures.ubuntu.com
<elmo> mdz: yeah, might as well
<elmo> I KNOW!
<elmo> how about second-class-citzens.ubuntu.com???
<Kamion> haha
<ogra> *g*
<Mitario> koke, yeah i noticed
<Mitario> koke, still have to remove them :-)
<Kamion> -#: debian/kbd-chooser.templates:4
<Kamion> +#: ../kbd-chooser.templates-in:4
<Kamion> I don't want to know how that happened, I think
<Kamion> gettext gives me enough of a headache as it is, cool though it is#
<smurfix> Kamion: ugh
<lamont> mdz: can I pretty please upload a new dhcp3 client that requests interface-mtu as well as all the other stuff?
<Kamion> 1.09ubuntu12 uploaded
<mdz> lamont: I remember fixing that like 2 years ago in Debian, wtf?
<lamont> current hoary does not request it
<lamont> and it breaks my machines
<lamont> I could just force it from the server side, but....
<lamont> I'd have to find that
<mdz> lamont: #77328
<lamont> wow
<lamont> so I take it that's a yes, then?
<elmo> do we have a dhcp-client that sends it's hostname yet?
<mdz> elmo: hell no
<elmo> jeez, that use to annoy the CRAP out of me at my previous job
<mdz> we'll do that one as soon as we have a dhcp client that doesn't suck
<elmo> mdz: mozilla-thunderbird-locale-pl wants to sneak into main.  ok?
<mdz> elmo: yes
<dholbach> hey mvo 
<Kamion> mdz: did that synaptic --set-selections thing get implemented or deferred?
<Kamion> I'm getting bored of my hoary installs downloading dozens of megabytes of crap
<mjg59> jbailey: Ok, I've just triggered it into that state again
<mjg59> It's, uh, unhappy now
<lamont> mdz: so I'll upload the request then
<Kamion> FUCKING BAZ
<mjg59> jbailey: I can reduce the problem to some extent just by renicing kacpid, but even so it's taking up all spare CPU time
<Kamion> opens a billion concurrent sftp connections and runs my server out of open files
<Kamion> 'cos, uh, that's highly intelligent behaviour
<mjg59> Bah, why can't I ptrace kernel threads?
<elmo> who  ptrace's the ptracer?
<elmo> it's 5.04 right?  not 5.4?
<ogra> jop
<mvo> dholbach: hey
<mvo> Kamion: synaptic --set-selections is implemented (you can feed it a list of selections via stdin)
<Kamion> mvo: oh, in the archive?
<mdz> Kamion: deferred
<Kamion> mdz: aargh
<mdz> Kamion: synaptic --set-selections is not what you want
<mdz> though that does exist
<Kamion> what do I want?
<mdz> you want a way to queue packages for later installation, no?
<mdz> synaptic --set-selections ~= apt-get dselect-upgrade
<Kamion> uh, ok, odd when compared with dpkg --set-selections
<mvo> ups, sorry for causing confusion
<Kamion> mdz: so, I think the way the installer sits and downloads a batch of stuff for many languages is a fairly serious regression, particularly for large deployments
<Kamion> mdz: if there's no other reasonable fix, I'd like to restore the "download packages from the internet?" question I removed
<mdz> Kamion: if you want to see it as a regression, then the fix is simply to turn of language-support installation for those languages
<mdz> that puts us back at Warty behaviour
<Kamion> means we have to reopen a number of bugs though
<mdz> elmo: yes, 5.04; though I personally prefer 5.4
<Kamion> hmm
<mdz> Kamion: I thought you had a local mirror?
<Kamion> large deployments> well actually more medium-sized ones, two simultaneous installs leave me unable to do much else with my ADSL ;)
<Kamion> mdz: yeah, and the installer totally ignores it
<mdz> ah, right
<mdz> tell your local DNS server that gb.archive.ubuntu.com is your local mirror ;-)
<Kamion> ugh :)
<Kamion> anyway I don't want to have to tell users to do that
<mdz> I hate it too, but CDs are only so big
<Kamion> and furthermore it's *.archive.ubuntu.com depending on the country I selected
<mdz> if you feel it's a show-stopper, the only reasonable solution is to turn it off
<Kamion> I think asking about it would be reasonable
<mdz> "do you want to download packages from the internet?" -> "do you want me to ignore your language preferences?"
<Kamion> for a number of languages, you'll still be able to do quite a lot of things with just the language pack
<Kamion> for example, all that language-support-xh gives you is the Xhosa Firefox locale
<Kamion> so you can still use all of GNOME; it's basically just OOo and Firefox that suffer
<Kamion> which is not good, but not totally ignoring either
<mdz> restoring the question seems to introduce more unknowns, but if we're going to do it, it has to be today
<mdz> daniels: morning
<dholbach> hi daniels
<daniels> good morning
<ogra> hi daniels
<Kamion> hmm, I didn't realise that no language-support-* other than -en were on the CD
<Kamion> could we trade off some language-pack-* for more language-support-*?
<dholbach> daniels: i uploaded a fix to fdclock from siretart
<dholbach> daniels: just thought you should know :-)
<mdz> Kamion: language-support-foo are generally an order of magnitude larger than language-pack-foo
<mdz> we'd basically trade all our language-pack-* for one more language-support-*
<mdz> Kamion: can we ask the question only if the user's lanugage-support is not on the CD?
<daniels> dholbach: ah cool, thanks; what was the fix?
<Riddell> LWN review http://muse.19inch.net/~jr/tmp/lwn-ubuntu-kubuntu-review.html
<dholbach> daniels: some missing #include somewhere
<Kamion> well, I guess it should be "Do you want me to install language support?" or similar certainly
<Kamion> mdz: I think so
<mdz> Riddell: that is copyrighted content...
<dholbach> daniels: he dpatch-applied it, so you should easily find out
<mdz> Kamion: we don't have time to translate a new question, I don't think
<Kamion> mdz: the old question was untranslated anyway
<mdz> oh? hell
<mdz> that's +1 for not asking it
<Kamion> very little of our new installer stuff has been translated into more than like four languages
<Kamion> I hope to fix that a bit over the next week
<mjg59> jbailey: Ok, it's looking like removing fan and thermal before suspend and inserting them on resume /may/ work
<Kamion> since I now actually have semi-decent infrastructure for doing that
<Kamion> much better than was available for warty
<jbailey> mjg59: So inserting once after the resume has finished, or twice, one to cope with disk/cpu activity and again with the kernel that's now in memoery
<mjg59> Hrm. It might be ok to leave the initrd as is, to be honest
<lamont> http://www.colinux.org/
<lamont> hrm...
<mjg59> lamont: Cool, isn't it?
<lamont> haven't even visited the site
<lamont> just heard about it
<daniels> dholbach: ah
<bluefoxicy> hey, check it out.
<mjg59> jbailey: For now I'll stick those in the suspend/resume scripts and see if it's ok. I've only managed to trigger this on one piece of hardware, so it may just be more fragile
<bluefoxicy> bluefox@icebox:~$ :(){ :|:;};:
<bluefoxicy> bash: fork: Resource temporarily unavailable
<bluefoxicy> Terminated
<Kamion> bluefoxicy: set a sane ulimit
<bluefoxicy> no kernel hacks.
<bluefoxicy> Kamion:  /etc/security/limits.conf right?  :)
<Kamion> bluefoxicy: that would be one option, yes
<bluefoxicy> it took me forever to figure that out, since everyone just says "ulimit"
<jbailey> mjg59: Cool.
<Kamion> bluefoxicy: well, ulimit *is* a shell builtin
<bluefoxicy> Kamion:  someone in ubuntu user channel is saying I should suggest that as a default setting and file a bug report, so I'll go do that now :)
<Kamion> mdz: I could ask it in archive-copier, which knows about what packages are on the CD already; that would have the additional bonus that netboot installs wouldn't ask, and I can suppress it for server installs too
<mdz> lamont: when was the most recent successful cloop build for amd64?
<mdz> Kamion: estimated time to implement+test?
<Kamion> mdz: can do it tonight
<mdz> Kamion: if you can get it in tonight, it's OK by me
<lamont> mdz: in about 30 minuytes
<Kamion> since it won't show up for English, sabdfl would probably not notice ;)
<mdz> lamont: most recent _completed_ successful cloop build
<mdz> lamont: the gdm in the current cloop is 2 revs old, and doesn't have a fix I made for the live CD
<lamont> 20050318
<mdz> which I made three days ago
<mdz> you are fucking kidding me
<lamont> nope
<mdz> the cloop builds have been failing for 6 days?
<lamont> can't reproduce the why, but livecd builds were disabled after 0318, renabled about an hour agop
<lamont> untried
<lamont> not failing
<mdz> all arches?
<mdz> or only amd64?
<mdz> looks like all
<mdz> gdm             | 2.6.0.7-0ubuntu1 | live_cloop       | i386 amd64 powerpc
<Kamion> Array CD 7 was 20050317
<elmo> you have a madison for live_cloop?
<elmo> that's so sick
<Kamion> that day would've made sense, but the day after ...
<Kamion> elmo: madison is your most successful meme ever, dude :)
<lamont> all
<mdz> elmo: I have an 'are we there yet' which gives me versions for pretty much everything little does
<mdz> s/does/has/
<elmo> Kamion: sadly credit goes to aj and neuro, but yeah, 'tis scary
<mdz> what's on the install CD, what's on the live CD, what's inside the cloop, what's in little's archive
<elmo> thankfully it's one of the less obvious names
<Kamion> elmo: oh, I thought you said once it was yours
<mdz> lamont: ping me when all the builds are done and I will do new live CD builds
<mdz> lamont: and if you hear a knock at your door later today, just open it and come quietly
<elmo> yes, ping me too, I need to make jackass not be a half-out-of-the-rack-and-in-pieces disaster
<Kamion> _Description: Install language support?
<Kamion>  The installation CD does not contain full support for your language. Do you
<Kamion>  want to download the required packages from the Internet?
<Kamion> how's that?
<mdz> elmo: you do? what does jackass care about live CD builds?
<mdz> Kamion: maybe s/: Install/: Download/ ?
<Kamion> sure
<sianis> hi all
<elmo> mdz: live cd sucks from jackass
<sianis> i use ubuntu hoary on laptop
<sianis> but i have a little probleme
<lamont> mdz: the livecd builds care about jackass
<lamont> as do all the buildds
<sianis> when ubuntu loadad fully, i cannot use the brigtness up/donw function keys on may keyboard
<mdz> elmo: oh, since when?  I thought the archive came from mirnyy and the cloops directly from the buildds
* lamont is supposed to pick up his kids in a few minutes, 30 minutes away
<sianis> but when ubuntu not load totally, i can use that
<mdz> lamont: oh, so the build will _start_ in 30 minutes?
<sianis> can some1 help me?
<lamont> mdz:cloop build sucks from jackass
<elmo> mdz: no it's started
<lamont> mdz: no livecd rootfs is building
<lamont> i386 is done
<lamont> doh.  elmo - royal is back to being mine, or no?
<sianis> heyoooo
<elmo> mdz: and the cloop build sucks from jackass for mostly historical reasons (i.e. copied sources.list from a buildd chroot, which has to look at jackass)
<elmo> lamont: sure?
<sianis> can some1 helo me???????
<lamont> ok.
<elmo> all the powerpc buildds are
<lamont> woot
<ogra> sianis, #ubuntu please, this is a development channel
<sianis> i try it there
<sianis> but on ubuntu webpage
<Kamion> how lame, busybox-cvs doesn't have join
<dholbach> sianis: then please try ubuntu-users@lists.ubuntu.com
<elmo> haha
<Kamion> will have to use less cool tools
<sianis> this channel is the chanel of the laptop-team
<mdz> if there is a place on the Ubuntu website which says to ask support questions on #ubuntu-devel, please let me know so that it can be corrected
<ogra> Kamion, no, implement join 
<elmo> kamion: probably because the author wasn't a memember of the twenty-strong "I've heard of join" l33t group
<Kamion> ogra: tempting but perhaps not tonight ;)
<elmo> or a mememememember either
<ogra> heh
<lamont> mdz: when you say all, do  you mean ubuntu or 'ubuntu and kubuntu'
<lamont> ?
* Kamion suspects mdz is in "kubuntu schmkubuntu" mode
<mdz> lamont: depends on whether 'no cloop builds for the past week' means 'ubuntu' or 'ubuntu and kubuntu'
<lamont> both
<sianis> dholbach, i try
<mdz> lamont: for pinging me, ubuntu is sufficient
<dholbach> sianis: cool
<sianis> sorry....
<mdz> for "holy shit we need cloop builds", ubuntu and kubuntu
<lamont> mdz: was gonna let elmo jerk jackass as soon as ubuntu done, which would kill the kubuntu builds, which are serialized.  can start those once he has jackass back up
<lamont> sound goodf?
<lamont> elmo's tired, I expect...
<mdz> lamont: fine, ping #kubuntu-devel when those are done
<Kamion> god, I wish you Americans wouldn't use the word "jerk" so freely, it produces horrible mental images
<lamont> ok
<mdz> Kamion: like 'jerk chicken'?
<schweeb> and "wanker" is much better? :p
<Kamion> mdz: unless that's a euphemism (don't want to know), I don't think so
<mdz> Kamion: it's a food
<Kamion> eww
<Kamion> anyway, I'm not helping the "please don't be off-topic here" cause, sorry
<schweeb> heh
<trulux> bluefoxicy: https://bugzilla.ubuntu.com/show_bug.cgi?id=8170
<trulux> we need to make the bugzilla sending security-related reports to ubuntu-hardened@lists.ubuntu.com
<bluefoxicy> heh
<trulux> so, we can track such security related enhancements within the list
<bluefoxicy> so reassign it?  :)
<trulux> no kidding
<bluefoxicy> oh
<trulux> I was thinking about it
<bluefoxicy> send it to a list automatically, good point, like with gentoo's "SECURITY" checkbox that privatizes the security report to the hardened team
<trulux> today I need to announce the selinux-support package
<trulux> that's it
<bluefoxicy> trulux: <Rebroad> so.. which should I install? PaX, grsecurity, selinux, stackguard...?
<lamont> mdz: must go fetch children - elmo's going to ping you when  ubuntu livecdfs's built
<trulux> bluefoxicy: stackguard + openwall + retor music + the greatest 80 p0p hits
<bluefoxicy> haha
<trulux> ;D
<bluefoxicy> stack guard is so old . . . propolice is stackguard enhanced (based on the SG source even)
<trulux> propolice is stackguard on steriods
<bluefoxicy> yeah
<bluefoxicy> japanese steroids
<trulux> :D
* bluefoxicy wonders if Etoh and Yoda used the force on SG to make ProPolice
<opi> g'day/night :)
<ogra> hey opi
<trulux> bluefoxicy: http://pearls.tuxedo-es.org/patches/gcc-4.0/
<trulux> hey ogra 
<ogra> hi trulux 
<opi> hi ogra :)
<trulux> bluefoxicy: just started it yesterday and almost finished today ;)
<trulux> bluefoxicy: that's trulux on steroids
<trulux> :D
<bluefoxicy> trulux:  so damn sweet.
<bluefoxicy> gcc 4.0 will rule.  I hope 5.11 goes full GCC4 w/SSP :)
<trulux> bluefoxicy: still there are some bits remaining, but it's almost finished, now it's Etoh's job to take the damn shit and fix protector.c if needed
<trulux> I hope too
<bluefoxicy> aww crap :)
<bluefoxicy> broken shit, knew there was a catch :)
<trulux> bluefoxicy: I will fix most of them, just I need to finish some writing and wiki related tasks
<trulux> among the selinux-support announcement and other things
<trulux> trulux on holidays, lately, is the same as saying trulux on steroids :)
<bluefoxicy> :)
* bluefoxicy should subscribe to ubuntu-hardened@ and lurk
<trulux> yeah
<bluefoxicy> perhaps when I get home from class
<bluefoxicy> trulux:  how are you going to handle X and Gnome when the new crap comes out, aside from trying to get Ubuntu to throw its weight at nVidia and see if they can do what Gentoo couldn't?
<bluefoxicy> or rather, what the hardened gentoo team couldn't, seeing as the rest of Gentoo wanted to fight them half the time :/
* bluefoxicy pulls up some GLX hacks. . . http://ftp.acc.umu.se/mirror/temp/seth/blog/xshots.html  <-- New gnome in 4 or 5 months?
<koke_shower> elmo: what happened finally with my gpg key??
<koke_shower> I had to go
<bluefoxicy> speaking of the new crap, I hope Ubuntu goes with a dynamic GTK theme when Cairo comes out :)
<ogra> koke, its a mako thing, not a elmo thing
<bluefoxicy> but I have class, so I'm out.  I've generated enough line noise here for today.
<koke> hmm, ok
<koke> then I haven't missed anything :)
<ogra> nope
<ogra> mako is still away....he has to send your signed CoC to elmo to add it to the list, then elmo compares it with your key you sent to keyring@ if i understood it right
<trulux> bluefoxicy: I've been out for a week, and things around you wimps come fast (:D), so, what's happening to them?
<mdz> amu: any new binaries in kde-i18n?
<bluefoxicy> trulux: ?
<bluefoxicy> trulux:  New shots of gnome show GLX hacks being used to make windows melt and wobble and crap as you move them, check the vids at the above link.  Also, dynamic GTK themes generate widgets based on algorithms, so every button is different  -->  http://ftp.gnome.org/mirror/temp/seth/blog-images/monkey-hoot/hand-drawn-window.png
<trulux> bluefoxicy: oh, OK
<elmo> mdz: would you consider a timeout for the live CD "Press enter to continue" thing?  as a wishlist bug, I mean
<trulux> nice indeed
<elmo> mdz: I almost left London with a non-remotely-manageable machine sat at one of those prompts :/
<bluefoxicy> trulux:  yes but remember, anything using nvidia's GLX LibGL will get a quick PaX kill
<trulux> bluefoxicy: where can I find further info. on it?
<elmo> actually, it's remote powerable, so it's not disastrous, but meh
<mdz> elmo: wouldn't you have the same problem anyway, with it booting from the CD?
<bluefoxicy> trulux: no idea
<trulux> bluefoxicy: any possibility of fixing that?
<haggai> mdz: afaik there are new languages in kde-i18n
<mdz> elmo: or did you take the CD out and just not power it off?
<elmo> mdz: I don't think any of the machines here auto-suck-back-in
<haggai> mdz: so that will translate into new .debs
<bluefoxicy> trulux:  fixing nvidia's closed source proprietary drivers?  Either get them to fix them (solar and tseng have tried I believe, for months), or bribe Ajax on #freedesktop #xorg to RE nvidia's drivers
<mdz> elmo: really? wow, every i386 and amd64 system I have seen sucks in
<elmo> mdz: even with slimline cd drives?
<tseng> bluefoxicy: uh, fix what?
<elmo> the non-slimlines we have probably would auto-suck
<mdz> elmo: oh
<tseng> bluefoxicy: they added dlloader, but you are in the wrong channel
<elmo> but I've never seen a slimline that does
<mdz> the ones without motors in them, probably not :-P
<elmo> mdz: :>
<bluefoxicy> tseng:  the dlloader drivers no longer generate runtime code?  :o
<tseng> bluefoxicy: uh
<bluefoxicy> when the heck was this?
<tseng> OT
<haggai> implement a sucking motor in software?  now there's a worthy bounty
<bluefoxicy> tseng:  well I've been +q in #gentoo-hardened for 2 weeks so. . . .
<tseng> so.. stop being annoying there
<tseng> and pasting all your buddies lame quotes
<bluefoxicy> lol
<trulux> tseng: hah
<trulux> tseng: that's what mad eme confused
<trulux> tseng: last thing on it I remember was a "super" or something alike from solar
<trulux> fabbione: ping
<mdz> daniels: xorg status update?
#ubuntu-devel 2005-04-05
<trulux> bluefoxicy: join #ubuntu-hardened
<elmo> Kamion: btw, hoary-updates exists now :P
<Kamion> elmo: ta, will implement in base-config
<Kamion> we want it on by default?
<elmo> I think we should; we only don't in Debian because we have no control over it
<amu> mdz: just uploaded
<Kamion> elmo: righto
<Kamion> does hoary-updates require approval then?
<elmo> kamion: no, but we have mdz wielding the pain stick threateningly
<Kamion> hah
<elmo> and/or we can certainly implement some
<elmo> but realistically the only thing that would have gone it for warty is the calendars which I think everyone can deal with
<elmo> gone in it
<mdz> Kamion: on by default, yes
<mdz> I'm not sure there's really a point in separating security and updates, but it's what we've got
<elmo> mdz: I like it for servers, FWIW
<seb128> elmo: I've uploaded an evolution package in warty-updates :p
<mdz> elmo: can you think of anything we would put in warty-updates that would be a problem for servers?
<elmo> mdz: no, because I don't have evolution or desktop background on mine
<mdz> elmo: I mean *-updates
<elmo> mdz: but if we used it for "bug fixes" to packages I do use on servers, I appreciate being able to distinguish between that and security fixes
<elmo> but hey, I'm also happy to merge them - suites aren't free in katie
<elmo> oh, speaking of, I should probably enable it in buildds too
<Kamion> smurfix: whatever way you're uploading kbd-chooser, it keeps removing debian/po/templates.pot from the source package; could you please sort that out before your next upload? I'm going to fix it up now.
<Kamion> it breaks translation statistics when that happens
<zul> hey
<mdz> Kamion: you have translation statistics for d-i?
<Kamion> mdz: yes
<Kamion> mdz: they're artifically low by about 240 per language at the moment; I'm waiting for rookery's mirror to update in order to fix that
<koke> when exactly does the update-manager turn grey??
<smurfix> Kamion: sorry -- will do.
<Kamion> mdz: http://people.ubuntu.com/~cjwatson/installer-po/statistics
<mvo> koke: when apt is running
<elmo> meh, silly powerpc is still building
* elmo weighs bus vs. ftp-master in bits
<koke> mvo: I think it has a bug :)
<mvo> koke: tell me 
<koke> it fades to grey when running pbuilder too :)
* smurfix doesn't exactly do anything special or different with these uploads, and will investigate
<Kamion> smurfix: it almost looks like you have the file ignored in revision control or something
<mvo> koke: interessting :)
<koke> mvo: wait, not sure
<Kamion> smurfix: because I restored templates.pot in ubuntu11, and your ubuntu12 removed it again
<Kamion> all it took was running debconf-updatepo
<koke> it got color before pbuilder finished
<koke> and now it says 7 updates when I know there are about 200
<smurfix> Kamion: don't re-upload yet
<Kamion> smurfix: I already have
<Kamion> I need working statistics and full translation files
<smurfix> Kamion: bah ;-) I just found a problem when people set the keymap multiple times
<Kamion> smurfix: ok, just please check debdiff between old and new .dscs before uploading :)
<smurfix> Kamion: I'll make sure to double-check next time
<Kamion> thanks
<mvo> koke: strange. I just run pbuilder update and it does not affect the icon
<mdz> smurfix: by the way, I find it a bit awkward that when the user opts to select the keymap from a list, they end up back at the same menu, rather than continuing immediately
<mdz> the confirmation makes sense for the detected layout, but less so for selecting from the list
<smurfix> mdz: Two reasons -- they can check that the map is correct, and having a single exit point is a Good Thing imho. But if y'all think neither is a problem, sure, I can change it
<elmo> mdz: I think all 3 arches are done
<elmo> they stopped buildding anyways
<smurfix> (some places have different keymaps and people might not know which is the right one)
<elmo> right upload.u.c's going away!
<elmo> OH DEAR LORD
<smurfix> which one?
<ogra> heh
<elmo> "/dev/hahasuckeryourscrewed has been mounted 30 times.  Please give over the rest of your life to waiting for the fsck to finish."
* smurfix commiserates
<elmo> that's all right, it's only a .5TB partition with something like 8% free
<elmo> I'm sure it won't take long AT ALL
<smurfix> reboot with init=/bin/sh, tune2fs, reboot again
<ogra> argh
<elmo> won't that dirty the partition
<smurfix> no
<smurfix> it's opened readonly as long as nothing needs to be fixed
<smurfix> You might dirty your root (dunno when that's switched to r/w), but I assume that's a bit smaller
* ogra remembers his last 3TB fsck.... migh take quite some time....
<elmo> e2fsck needs an online check mode
<elmo> who the hell's got time to sit through TB's worth of fscking?
<HrdwrBoB> e2fsck isn't exactly what you'd call an enterprise class filesystem
<HrdwrBoB> *ext2
<schweeb> I like XFS, but its recent problems with grub make it an annoyance to use
<lamont> Kamion: http://www.theonion.com/news/index.php?issue=4111&n=12
<ogra> HrdwrBoB, my last 3TB fs was around 1999 :) i switched the array to xfs in 2000
<HrdwrBoB> ahh cool :)
<ogra> and reiser was never an option, but the only alternative to xfs ;)
<HrdwrBoB> that is going to become more an issue
<HrdwrBoB> esp as large arrays become more commodity items
<zyga> ogra: not that I'm fs guru or something but why reiser was not an option?
<schweeb> back then reiser kinda had a knack for losing data
<schweeb> I know a couple people that got burned by it
<ogra> zyga, reiser is crack i dont let near my systems
<zenwhen> reiser is pretty nice, stable and fast now
<zenwhen> 3.6 that is
<zenwhen> I am not bothering with 4 yet
<zyga> ogra: I see... I'm using reiser since last year only ;] 
* zyga is too young for this :P
<zenwhen> oh cool
<ogra> zyga, hans has a bad attitude to offer buggy stuff as stable....(he just tries it again with the new reiser)
* lamont goes back to cleaning up the mess
<zyga> ogra: reiser4 seemd nice except for /let's/mess/the/namespace 
<zyga> s/md/med/
<Kamion> lamont: haha, excellent
<ogra> zyga, i know hans reiser and how is underpaied slaves have to work for him, i wouldnt touch anything from him before it has matured a while in the kernel tree where sane people have looked it over 
<lamont> Kamion: and true to form for that excellent news source.
<lamont> Kamion: OTOH, it's not exactly kind... :-)
<zyga> ogra: I remember hans' lively discussions on lkml about how r4 is great
<ogra> zyga, but that leaves me biased too much to try it anyway :)
<zyga> ogra: he did have a point, but in the end he was totally deaf to what people were saying
<ogra> yup, thats him... he cant bear critics
<zyga> ogra: it was more like he ignored it and started with the same argument all over
<zyga> ogra: but I pity him, there is no real sane way to do what he did with reiser4
<ogra> zyga, thats what i mean when i say he cant bear critics
<zyga> ogra: well he could also start calling people names but he didn't :-)
<dholbach> good night... i'm off
<mvo> good night dholbach 
<mdke>  night
<Mitario> hi everyone
<mvo> hey Mitario 
* mvo grummbles about modem-applet
<seb128> time to sleep, 'night guys
<lytefyre> apache2ctl complains of no /usr/sbin/apache2 after install through kynaptic..what did i miss ??
<zul> ewww...reiserfs4 i dont think so
* lamont considers options for buildd-health-check scripts
* mvo goes to bed now
* lamont prepares to upload exim4
<Mitario> gn mvo 
<ogra> night mvo
<lamont> my bad.  exim
<mvo> night Mitario, ogra and the rest of you
<mdz> Kamion: mini.iso has cdrom-detect on it, right?
<opi> night guys
<Kamion> mdz: mini.iso is just a format, not an image type; which architecture and directory are you referring to?
<mdz> Kamion: dists/hoary/main/daily-installer-i386/current/images/netboot/mini.iso
<Kamion> oh, actually, all the Ubuntu mini.iso files are netboot
<Kamion> mdz: no, it doesn't
<mdz> crap
<Kamion> it netboots, it doesn't touch the CD after it boots from it
<Kamion> mini.iso is just a handy format to carry the netboot kernel/initrd around in
<mdz> roger
<Kamion> it's possible to build other mini.iso types (like monolithic), but generally only done for debugging
<mdz> helix is able to reproduce #1440 with preview, and I wondered if mini.iso could be used to re-test something more recent, without downloading another complete image
<Kamion> mdz: she could try a netboot install and see if the CD shows up in /dev/cdroms/ after hardware detection
<Kamion> mdz: not a bulletproof test, but it would be interesting, particularly if accompanied by a control test with the netboot kernel/initrd on the preview CD
<Mitario> good night everyone
<Kamion> poo, busybox-cvs grep is missing half the useful options, like -x
<lamont> there.  exim fixed.
<Kamion> <joeyh> debconf-updatepo... also known as "I'm feeling unproductive today.
<Kamion>         Please give me a huge diff to check in"
<Kamion> seems particularly appropriate today
<Kamion> $ dscdiff choose-mirror_1.06ubuntu11.dsc choose-mirror_1.06ubuntu12.dsc | wc -l
<Kamion> 79546
<schweeb> Kamion: you're on the community council, right?
<Kamion> schweeb: yeah
<lamont> Kamion: that's just poupdate?
<Kamion> lamont: pretty much
<schweeb> Kamion: wiki said I should consult a CC member about becoming a ubuntu member... I threw myself on the agenda already at dholbach's recommendation... what else do I need to do to make it easier to happen, and when is the next meeting
* schweeb is looking to hopefully become a MOTU soon as well
<Kamion> schweeb: best thing you can do is link to a wiki page about yourself from the agenda, and make sure it has as many things on it that you've done for Ubuntu as you can
<Kamion> schweeb: also, work with other Ubuntu folks until the date of the meeting so that they have good things to say about you
<schweeb> okay, done a pretty good job at that so far
<Kamion> basically give us enough evidence that you're good so that we don't have to defer you pending more evidence :)
<Kamion> schweeb: next meeting's in two and a half weeks; it would have been a week earlier than that, but that's the day before Hoary releases and none of the CC members really wanted to have a meeting at that point
<schweeb> I fixed 2 pkgs yesterday and am probably getting a NEW package into universe (it's approved, just needs to be uploaded)
<schweeb> yea, I figured it'd be deferred
<Kamion> schweeb: we'll probably do membership and MOTU stuff at the same time, to catch up on backlog
<schweeb> ok, cool
<mako> ogra, mdz: the current system is that i keep a master list of signed cocs.. every time i modify it, i gpg sign it and put it in a place that elmo can check
<mdz> mako: and you ping elmo when there's a new batch of entries to process?
<mako> ogra, mdz: however, after the last CC meeting, i think i'm going to put it somewhere public (people.u.c/~mako/)
<mako> i haven't done it yet, it's only a 3 day old process :)
<mako> but that's the idea
<mdz> Kamion: dscdiff?
<mdz> Kamion: any interesting changes to debian-cd recently?  I just pulled the hoary-live-amd64.iso I built earlier today, and it doesn't boot (doesn't even load isolinux)
<mdz> mounts OK, looks OK, md5sums check out so far
<mdz> same test hardware as always
<mdz> I burned an earlier image in the same drive, same media, earlier today, and it booted in the same box
<mdz> guess I'll re-burn
<Kamion> mdz: dscdiff is my alias for debdiff with different completion rules
<Kamion> mdz: today I imported debian-cd into arch and switched little to using that
<mdz> Kamion: ooh, clever
<mdz> debdiff completion is pretty awkward considering its multiple invocations
<Kamion> the code should've stayed pretty much identical though; I was very very careful with diffs
<Kamion> mdz: I also have debdiff-changes, and I made debdiff only complete on .debs
<mdz> Kamion: second burn boots fine; this media must be starting to go
<Kamion> ok, good, you had me worried there
<Kamion> I definitely want to hear about weird CD occurrences at the moment, despite all my paranoid diffing
<mdz> Kamion: a tiny cosmetic thing that's been bugging me; when using kbd-chooser on amd64 and i386, I get "Dvorak", while on powerpc I get "dvorak"
<Kamion> mdz: yes, USB keymap names are different (powerpc always uses the USB keymaps regardless of actual hardware) and I think kbd-chooser always selects the AT names rather than the USB names so the back-translation fails to happen
<Kamion> or something like that
<Kamion> I get "uk" typically
<Kamion> actually just translation rather than back-translation; "Dvorak" is en.po for "dvorak", but powerpc has "mac-usb-dvorak" and the translations will be taking place with reference to that set of msgids
<lamont> Kamion: looking at 3134 (libsmbclient.a is -fPIC), and thinking I don't much care - esp since I think I may have been the one that caused the -fPIC to get there in the first place...)
<Kamion> lamont: I've totally forgotten whatever conversation I had with Steve about that :)
<lamont> more to the point, I figure we should fix it as soon as we snap the fixed version from sid...
<mdz> have none of you powerpc users noticed that pbbuttonsd doesn't have an lsb-ified init script?
<mdz> lamont: is that in your ball of patches?
<lamont> Kamion: it's a symptomatic issue for libraries: they build the .o's once, and then build .a and .so.  is royal pain to fix.
<lamont> mdz; checking
<lamont> 1580, btw
<lamont> and not in the list, but should be.
<Kamion> lamont: I can imagine. double-build, yay
<lamont> Kamion: exactly
<lamont> and the simple fix is to just make a -fPIC .a :-)
<mdz> lamont: mysql, squid, hpoj, tftpd-hpa, heartbeat, pbbuttonsd
<mdz> lamont: those are the ones on my list
<mdz> Kamion: fwiw, powerpc and amd64 live cd tests were successful
<lamont> mdz: will upload those tonight, assuming they don't make me run away screaming
<mdz> lamont: the only ugly error left on the live CD is "none busy - remounting read-only"
* Kamion tries archive-copier test #4, hopefully final one in the battery
<mdz> lamont: have I mentioned how it scares the shit out of me for that to happen a few days before the release candidate?
<lamont> mdz: yeah. hence they must be trivial.
<Kamion> English normal (no question), German normal (question, answered yes, l-s-* installed), German server (no question), German normal (question, will answer no, shouldn't install l-s-*)
<lamont> and mysql-server qualifies as more scary than I like
<bluefoxicy> the gnome devs are gonna be pissed at me; I edited MemoryReduction on the wiki like 6 times, and every time it e-mails like 10 people, who now have been spammed to hell.
<schweeb> bluefoxicy: isn't that a bit OT for #ubuntu-devel ?
<bluefoxicy> schweeb:  yes.  I just felt like saying it, because people will claim it's OT, then i'll shut up, and somebody might spend the next 5 days wondering wtf I'm smoking :)
<adobbie> schweeb: bluefoxicy doesn't know about on topic
<bluefoxicy> adobbie:  I'm learning!  . . . slowly. . .
<bluefoxicy> I rant off topic much less now than last year
<mdz> bluefoxicy: it's still too much
<bluefoxicy> mdz:  true.
<csj> hello, is any service will replace the /etc/X11/xorg.conf in liveCD?  since I remove too many packages and it wont replace it :(
<csj> eg: my video card is nvidia, but xorg.conf write "ati"
<csj> and I wont override it, but original liveCD will do it, naybe because I remove some package?
<mdz> csj: #ubuntu, please
<csj> mdz: thanks
<dross> mdz: you must be a police officer for #ubuntu-devel ;)
<Kamion> woo, test #4 passes
<mdz> dross: it feels that way some days
<Kamion> dross: somebody has to be
<lamont> mdz: of course, if you say 'no', I won't upload any of those...  but so far it looks like tftp-hpa is the first yes, mysql/squid are non-trivial, and hpoj is "RUN AWAY SCREAMING"
<mdz> lamont: let's forget about it; it's too late to touch that stuff
<mdz> it's just really unfortunate because most of those are user-contributed patches which have been sitting in bugzilla for months
<mdz> and I hate for them to feel like their contributions weren't welcome
<lamont> mdz: cool
<lamont> none of your list had patches in that bug
<lamont> and sadly, several of the submitted ones to 1580 had the same lack of understanding of -e as their predecessor
<mdz> bleah
<lamont> yeah - so you get 'ok' or ''
<lamont> actually '[ok] ', or ''
<lamont> how soon after hoary release will we have breezy, I wonder?
<mdz> the xinetd one looks reasonable
<lamont> for that matter, other than DC resources, couldn't we create that and start syncing it now?
<mdz> (not that I think we should change it, but it doesn't have set -e breakage)
<mdz> lamont: jbailey/doko want to wait, because we're going to do toolchain changes first
<Kamion> +msgid "Check /var/log/syslog or see virtual console 4 for the details."
<Kamion> +msgstr ""
<Kamion> +"Veuillez vrifier /var/log/messages ou consultez la console virtuelle 4 pour "
<lamont> several are reasonable, some assume that -e is not specified, and then you get to look and see which it is...
<Kamion> +"obtenir des prcisions."
* Kamion thwacks seb128 in absentia
<lamont> mdz: right
<mdz> Kamion: that's how they spell "syslog" in French ;-)
<Keybuk> though if we started it now, there's more time for lamont to remember to turn on the gcc flags this time ... :p
<lamont> mdz: btw, I made the fiat decision that universe packages that do not install/remove noninteractively get my full attention for a minute or 3. (e.g., exim)
<lamont> (and are build-deps of anything)
<lamont> Keybuk: that's not it,and you know it.
<lamont> it was turning them _off_ that was the grand warty mess...
<mdz> lamont: if they're blocking MOTU work, that's appropriate
<lamont> hrm.. would be interesting to know how much of hoary is virgin warty-release bits...
<lamont> mdz: yeah - more to the point, it was screwing with the hoary-test run, which in turn, was messing with MOTU
<Keybuk> lamont: surprisingly little
<lamont> Keybuk: good.
<lamont> because warty/ppc binares are at least partially thpetial
<Kamion> lamont: how come?
<lamont> -O2 was force
<lamont> d
<Kamion> ah
<lamont> yeah.  'ah'.
<Kamion> rather than allowing -O3, you mean?
<lamont> no, rather than allowing -O0 or -O1
<lamont> they were all -O2, -O3, or -Osize?
<Kamion> oh, I thought gcc-opt clobbered -O0 and -O1 in general
<adobbie> -O0 makes terrible code 
<lamont> -O2,-Os,-O3
<lamont> Kamion: prior to oxford, all 3 archs were using opt: 2..3. after that they werent.
<lamont> they use 0 3
<Kamion> mkay, I'm obviously remembering stuff from Oxford
<Kamion> and powerpc didn't get blown away in the grand rebuild?
<lamont> oh, and in the 'prior' camp, if you didn't say -O<something> you got -O2
<lamont> nope
<lamont> only i386 got blown away at oxford
<lamont> amd64 got toasted later for other reasons
<lamont> and after amd64, we were pretty good at knowing what we had to do to reburn the archive.....  Another lost art. :-)
<Kamion> ah, much healthier translation stats when I include new choose-mirror
<Kamion> fr: 915 translated messages, 32 fuzzy translations, 52 untranslated messages.
<Kamion> (that's the best one)
<lamont> woot
<Kamion> lamont: #1: remind lamont to upload glibc? :-)
* lamont ponders taht one
* Kamion remembers the OH MY GOD THE WHOLE ARCHIVE IS UNINSTALLABLE morning
<lamont> it's more a question of what to nuke in what order, don't forget proxies (if any), cache flushing, etc,etc,etc.
<lamont> ah, yeah.  that was pre-DC signing
<lamont> I'm so glad to not have my house be critical infrastructure any more
<Kamion> $ msgfmt --statistics -o /dev/null ~/public_html/installer-po/template.pot
<Kamion> 0 translated messages, 999 untranslated messages.
<Kamion> aww, just one short
<Kamion> lamont: fabbione's ADSL surprised me by turning out to be critical infrastructure at one point
<lamont> yeah
<lamont> Kamion: and if you add one more, it'll be way over 1000...
<lamont> Kamion: I think we all knew that my house was crit infra though
<Kamion> actually, that's not including new archive-copier, which adds two strings
<schweeb> 22:03 < Ozymandias> GAH
<schweeb> 22:04 < Ozymandias> "yeah, i'm identified"
<schweeb> 22:04 < Ozymandias> turns out he doesn't even have his nick registered
<schweeb> urgh
<schweeb> sorry
* schweeb hangs head in shame
<lamont> schweeb: you're supposed to wait until _AFTER_ you become a member/motu to do things like that... :-)
<schweeb> lamont: heh. the problem is my piece of shyte Dell 8200... the trackpad goes wonky once in a while, and middle click pastes for no reason... even if I'm not touching it
<lamont> lol
<Keybuk> sure, blame the Dell ;)
<schweeb> hopefully I get a new laptop in the near future...
<lamont> mdz: tomorrow is holiday, yes?  (not that it really makes much diff)
<mdz> lamont: hell if I know
<lamont> schweeb: btw, did ethereal finally get in a state where you're happy?
<lamont> mdz: some dead guy
<schweeb> lamont: yea, it's all built now
<schweeb> all arches
<lamont> sorry - fast times at ridgemont high reference
<Keybuk> lamont: yeah, you know the one; Jesus gets nailed and killed on Friday, but is back for tea on Sunday
<schweeb> lamont: although the i386 debs haven't made it to archive yet, dunno what the holdup is
<lamont> Keybuk: that'd be the 'canonical dead dude holiday' then?
<lamont> schweeb: uh, yeah.  I do
<lamont> they'll make it as soon as the other machine builds it.  - was too lazy to deal with that right now.
<Keybuk> dunno, hollow chocolate eggs come into it somewhere as well
<lamont> rothera is not a happy camper.
<schweeb> ahh
<schweeb> okay then :)
<Keybuk> not really sure what they have to do with a dead dude; maybe he over-ate
* lamont hates it when perl says 'Out of memory!'
<schweeb> lamont: laziness I can understand
<lamont> actually, I hate it when perl says anything
<lamont> Keybuk: seen fast times?
<Keybuk> "fast times" ? nope
<lamont> "so what you're telling me, Mr Spicoli, is that Napoleon was a short, fat, dead dude?"  "yeah."
<Kamion> lamont: wasn't that Bill and Ted?
<lamont> you see, all our holidays are about dead dudes.
<lamont> Kamion: damn.  I think you're right
<schweeb> Kamion is correct
<lamont> spicoli is much cooler than ted, though
<Kamion> mdz: don't expect me around much tomorrow, certainly; not feeling very well and my hours have been way too long this week anyway
<lamont> so, s/fast times at ridgemont high/bill&ted/g
<mdz> Kamion: yep
<Kamion> I'm not going to pass up a holiday while it's there ;)
* lamont will be around, but probably hacking on personal stuff more than not.   Other than staring really hard at the buildd's to make sure they stay happy, and doing what they should
<Kamion> anyhow, archive-copier's in, base-config changes for hoary-updates made locally but I'll wait until I'm more awake to test them
<mdz> lamont: http://www.fxstreet.com/nou/bank/bankholidays.asp
<lamont> mdz: is the canonical(sic) list?
<mdz> lamont: it's the one I use
<lamont> works for me
<lamont> what's all those 'u's doing in words like labor - obviously not an american site...
<lamont> hrm.. good friday isn't listed for the US... must call bank in morning. :-)
<Keybuk> it's UK holidays are wrong too
<Keybuk> New Year's Day was 3/1 this year and Christmas will be 27/12
<mdz> Keybuk: you get _two_ new year's days in 2005
<mdz> (got)
<Keybuk> heh, yeah, and that
* lamont prefers http://www.bondmarkets.com/holiday/
<mdz> I liked the other list because it had many countries on it
<mdz> oddly enough, that one has two new year's days too
<dredg> here, at least, good friday is a bank holiday and not a public holiday
<dredg> that said, nobody really works good friday. everyone just takes it as a holiday anyway
<mdz> Christians, anyway
<dredg> it's not that long ago that catholocism had a special place in our constitution.
<dredg> still does in many respects
<dredg> all pubs and off licences must close on good friday here. it's insane.
<dredg> a nationwide day off, with a long weekend and you can't get a drink. in ireland.
<dredg> incredible.
<lamont> mdz: Out of memory!
* lamont screams
<Lathiat> dredg: haha
<mdz> lamont: ECONTEXT
<schweeb> lamont: it's better having perl say that than the kernel ;)
<lamont> vmstat
<lamont> procs -----------memory---------- ---swap-- -----io---- --system-- ----cpu----
<lamont>  r  b   swpd   free   buff  cache   si   so    bi    bo   in    cs us sy id wa
<lamont>  0  0      0 2869692 567184  11316    0    0   127    61  261   183  3  1 93  3
<lamont> mdz: this mornings fun
<mdz> oh, that
<lamont> yeah.
<mdz> elmo and I dug up a patch which ought to fix that
<lamont> terranova joins rothera in its unhappiness
<lamont> terranova is running 2.6.10
<mdz> err
<lamont> yeah
<mdz> that patch was incorporated in 2.6.9
<mdz> since when are we running 2.6.10 in production?
<lamont> since today when elmo upgraded 2/3 machines to that
* dredg beds
<lamont> interestingly, the 2 i386 machines that are bitching now are the ones running 2.6.10
<dredg> night
<lamont> Kamion: so you wanted archive-copier/i386 to make it into the archive, yes?
* lamont wishes he were in the DC right now so he could put his fist into something...
<Kamion> lamont: ideally, yeah
<Kamion> lamont: before next daily CD build would be good I think
<lamont> oh, sure.  put a time limit on it.
<Kamion> but I suspect that may not be happening ;)
<lamont> Kamion: don't worry - it's not alone... plenty of company
<lamont> DOH
* lamont grabs libc and looks for something to beat with it
<lamont> mdz: can I pretty please change glibc?
* schweeb chuckles
<lamont> --- debian/local/usr_sbin/tzconfig      2005-03-24 20:43:59.541655099 -0700
<lamont> +if [ ! -t 0 ] ; then
<lamont> +       echo "Non-interactive:  quitting."
<lamont> +       exit 1
<lamont> +fi
<lamont> +
<lamont> perl really doesn't like it when you tell it to read 1.1GB of looping tzconfig crap into memory
<lamont> mdz: thoughts?
<lamont> hrm... and no jbailey either
<lamont> Kamion: your upload processed, btw
<lamont> or rather, the binaries from your upl.oad
<Kamion> lamont: cool, ta
* lamont curses kde, hal, and dbus-1
<lamont> mdz: thoughts on stubbing out start-stop-daemon in the buildd chroots?
* lamont notes that all the buildds are currently running, with correct cronjobs, and no abnormalities currently visible, goes to bed for a few hours.
<sabmoc> hello all
<sabmoc> jbailey, ping re:wiki
<Keybuk> 71G     /home/scott
<Keybuk> aww, not as bad as I thought
<Lathiat> heh
<daniels> lamont: what's dbus-1 done?
<daniels> lamont: and my understanding was that policy-rc.d or whatever was just stubbed to return 101 in buildd chroots so services didn't get started on postinst
<fabbione> morning
<jdub> mdz: there was never any relationship between the timing of our RC and timing of the first gnome point release
<jbailey> lamont: hein?  Que-ce qui ce passe?
<jbailey> sabmoc: 'sup?
<schweeb> jdub: gsf-sharp should be goin in soon, it got all the reviews it needs :)
<opi> morning
<sabmoc> jbailey, its in the email
<jdub> schweeb: rock!
<jdub> schweeb: only problem... we need a fixed up mono (or a micro upgrade) for beagle 0.0.8 :-)
<Lathiat> whats gsf stand for?
<jbailey> sabmoc: Thanks.  I'll look at it a bit more in the morning.
<sabmoc> jbailey, np, hows it going out there?
<jbailey> sabmoc: Good, tired.
<fabbione> hey jbailey 
<fabbione> jbailey: did you have any time to check at mpeg2dec?
<jbailey> Heya Fabio
<jbailey> fabbione: YEah, turns out the fix was right bogus anyway.  It seems it relied on a post gcc-3.3 quirk to disable all altivec for ppc, fixing the bug.  That package is going to have issues post-hoary.
<fabbione> jbailey: ah i see.. that might be the same reason why mplayer fails on altivec code on ppc with gcc-3.3
<jbailey> fabbione: Still, it has the advantage of working rather than segfaulting, so I'll probably mark it gcc-3.2 for everyone but PPC to fix it for you.
<jbailey> fabbione: Either that or I can hack out the inline.
<fabbione> you mean gcc-3.3
<jbailey> Err, yeah.
<fabbione> eheh ok :-)
<fabbione> eitherway i don't mind :-)
<fabbione> probably in the short term the hack is better
<fabbione> and we can take time to fix it for breezy
<jbailey> Yeah.  I'll be getting a sparc station soonish again, so I'll try to fix it right for breezy.
<fabbione> jbailey: sparc should be installable again pretty soon
<jbailey> Without this, totem-gstreamer just sucks, though.
<jbailey> (on ppc)
<fabbione> jbailey: elmo had to stop the rsync mirror towards sparc.u.c for some reasons, so debootstrap will fail due to missing packages
<jbailey> Ugh.
<jbailey> Well, it'll be nice if we can provide a solid sparc arch.
<fabbione> elmo sais that it will be fixed in a few days
<fabbione> it is a server load problem mainly, and he needs to move the mirror
<jbailey> Cool.
<fabbione> so nothing really impossible :-)
<fabbione> just time consuming
<jbailey> I also have to make sure that I'm using machines that are OK'd for Ubuntu.  I've got clearance for most of them now.
<jbailey> (Since they were donated to me for debian glibc work, I'm checking to make sure I don't trip across politics)
<fabbione> right.. sounds reasonable
<fabbione> and fair
<fabbione> but you can always dualboot them :)
<jbailey> Well.....
<jbailey> I'm avoiding putting Ubuntu on the boxes until I'm sure.  The last thing anyone needs is an angry sponsor.
<fabbione> right
<jbailey> So far getting permission hasn't been hard at all.
<fabbione> nice
<jbailey> fabbione: Did you see my note in -kernel about 1440, btw?
<jbailey> It looked like it got assigned to you almost randomly, and I don't understand why.
<fabbione> not yet :-)
<jbailey> But I'd like to reassign it to me and close it if you don't have anything special on it.  It's that SATA / ata-piix bug.
<fabbione> jbailey: why did you reopen it?
<jbailey> Had a report of a recurrance.
<jbailey> It's caused me a number of up-in-the-middle-of-the-nighit troubleshooting sessions this week.
<jbailey> I'm not young enough to flip timezones like that easily anymore.  I should start prepping for UDU now ;)
<fabbione> ehhe i have the same problem here :-)
<fabbione> ok reassinged
<jbailey> fabbione: Luvly, thanks.  I'm heading off for the night.  If I don't see you online I hope you have a lovely weekend.
<fabbione> jbailey: thanks and have fun. Say hello to your wife from me
<jbailey>  Ohh..  Really?  Say hi back to him for me.  I miss him.  I want to see him in Helsinki, so he better damned be there.  Oh yeah and congratulations! 
<sabmoc> jdub, I am under the impression that plante.ubuntulinux.org is a developer only forum, do you have a position on that?
<jdub> it's for ubuntu members
<sabmoc> jdub, whats the definition of a member?
<jdub> http://www.ubuntulinux.org/community/processes/newmember
<sabmoc> jdub, the reason I ask is because we are planning to start a canadian-users-blog, ok, let me read that link
<fabbione> jbailey: eheheh
<fabbione> jbailey: i am not sure i will be there, but you are welcome to pass by copenhagen on the way back and spend a few days here :-)
<jbailey> fabbione: You living in Denmark these days?
<fabbione> jbailey: yes.. like for the last 4 and half years :)
<sabmoc> jdub, member == ubuntu_developer
<jbailey> fabbione: Ah, cool.  No idea what are plans are for around then.  I'm running the talks this year for debconf again, so I have to attend that, but aside from that we're hoping to hang out with some friends who've moved to Sweden from Canada.  But maybe we can swing by and say hi. =)
<fabbione> jbailey: that would be awesome
<crimsun> sabmoc: to be pedantic, a ubuntu member has made a substantial contribution and has signed explicitly the CoC
<sabmoc> crimsun, so then member == ubuntu_developer++
<sabmoc> uber developer
<crimsun> sabmoc: well, I'm a universe maintainer (which implies membership), but I'm not a Ubuntu developer
<crimsun> sabmoc: I'm not sure if that helps clarify the distinction; do you have additional questions?
<sabmoc> crimsun, maybe I have an different definition of developer. I consider any person who is actively trying to improve the quality of the distrobution to be a developer, no matter if its art, bug reports, maintainership, or downright development. Of course the person has to be extreamly dedicated to truely be considered a "developer", at least in my book.
<sabmoc> crimsun, nope :)
<crimsun> sabmoc: ah, yes, in that sense, yes, a "developer"
<jdub> sabmoc: an ubuntu member is not necessarily a developer
<sabmoc> haha
<sabmoc> bah
<sabmoc> fine
<jdub> committer & maintainer are different levels of membership, for technical reasons
<jdub> someone who's contributed to ubuntu in completely different ways is as much a member as a developer
<sabmoc> jdub, ah, well I did not know there was "levels" of membership, now I see it differently. 
<sabmoc> jdub, is there something like a membership tree then?
<sabmoc> or is it more of a ladder
<jdub> it's described on that page
<sabmoc> jdub, sorry, I only skimed it the first time.
<jdub> hey
<jdub> someone run yelp
<jdub> let me know if the front page actually has category link son it
<kagou> hi
<sabmoc> mine says "help topics: desktop, applications, other documentation, man pages"
<jdub> ok, that's good
<jdub> something is wrong locally then
<sabmoc> does anyone know who is involved in art for ubuntu?
<sabmoc> it would be nice if we had an ArtTeam
<crimsun> hey, jdub would know :>
<sabmoc> someone said to talk to volvoguy, but he is neveronline
<jdub> ah, there will be a cool surprise soon after the hoary release related to that :-)
<sabmoc> I think there must be an art team already because otherwise where does all the art come from
<dholbach> gooood morning
<sabmoc> jdub, want me to add you to the CA mailing list?
<jdub> no thanks, i'm not in canada
<froud> where is the bugzilla for kubuntu done?
<_d4vid> hi all
<Mirv> is anyone able to say straight away where this is done: after detecting two "sound cards"/mixers (tv-card's and sound card's), the "real" sound card is selected as the primary device? this didn't work in warty, but now it works.
<Mirv> and in debian it doesn't work...
<Mirv> alsa-base or sth?
<bob2> that sounds like luck
<mvo> ping seb128
<crimsun> Mirv: cat /proc/asound/modules
<mdke> jdub, ping
<zyga> hmm I'm trying to build capplets 
<zyga> but configure failed to indicate missing libxrandr
<zyga> should I file a bug?
<Lathiat> yeh
<zyga> again... libxinerama
<Lathiat> might be worth double checking its not just something buggered on your system
<zyga> Lathiat: like?
<Lathiat> check the configure script to see if it does check for them
<zyga> Lathiat: good idea
<crimsun> zyga: you need libxrandr-dev and libxinerama-dev
<zyga> crimsun: yeah I know (got them already)
<crimsun> zyga: ->#ubuntu
<Lathiat> :q
<mdz> jdub: there so was!
* lamont curses udev
<mdz> lamont: wtf are you doing awake?
<lamont> cursing, obviouslyu
<Lathiat> bah 3:37am is nothign to worry about :)
<lamont> woke up, figured I'd check on the buildd's
<Lathiat> its when 830am clocks around and work is about to start you need to get worried :)
<lamont> Lathiat: my alarm is set for 0600
<mdke> that is serious dedication to the job lamont 
<Lathiat> well, whatever time work si fo ryou :)
<lamont> mdke: nah - is called 'critical path'
<mdke> some people wake up in the middle of the night and go to the toilet, lamont checks the build
<Lathiat> haha
<mdke> lamont, its when you're dreaming about the builds that you should get worried tho :)
<Lathiat> heheh
<lamont> mdke: if I wasn't fairly convinced it would probably have _something_ wrong, I wouldn't have bothered...
<mdke> heh
<lamont> mdz: so thoughts on nuking start-stop-daemon in the build chroots?  (no, it's not an automatic part of a chroot, regardless of what daniels said..)
<mdz> lamont: motivation?
<lamont> -rw-r--r--  1 root root   14 Mar 25 10:41 build-hoary/chroot-hoary/dev/null
<lamont> *%&()^&_%&$^ udev
* lamont takes a few minutes to go beat 4 more buildd chroots back into static /dev's
<bob2> haha
<Lathiat> poor lamont :)
<mdke> lets hope he's asleep again now
<lamont> nah - just finished
* mdke hands lamont sleeping pills
<lamont> both the cleanup, and the glass of water
<mdke> heh
<lamont> mdz: I'm not sure the cure wouldn't be worse than the original problem.  But 'tis very annoying
<jdub> mdz: i'm missing scrollback for context
* lamont goes back to bed
<dholbach> lamont: good night
<dholbach> hi seb128 
<ogra> jdub, will the mono microchange need a recompile for gsf-sharp ? else i'd upload schweebs package today
<ogra> s/for/of
<ogra> morining btw
<dholbach> hey ogra 
<ogra> hi dholbach 
<mdke> hi you guys
<Amaranth> omgwtfhax, recent dist-upgrade made my crossover menu appear again
<Amaranth> must have been gnome-menus 2.10.1
<Amaranth> looks like the fd.o folks finally decided on what to do if an entry doesn't have an icon set
<Amaranth> looks like i'm talking to myself
<jdub> ogra: no, doubt it
<jdub> Amaranth: that's an ubuntu change
<Amaranth> which?
<jdub> default icons
<Amaranth> ah
<ogra> Amaranth, ask koke about it ;)
<Amaranth> oh yeah, i read it on ubuntu-devel and someone said if you find a solution let the fd.o guys know
<seb128> Amaranth: that's not a fd change but a gnome-panel one
<Amaranth> yeah
<Mitario> hi everyone
<Treenaks> hi
* ogra wraps gaim in barbed wire and rolls it around a bit
<haggai> elmo: any chance of installing screen on novo?
<haggai> ogra: who cares, kubuntu has kopete ;)
* haggai hides
<bob2> irssi 4 lyf
* ogra throws the gaim ball at haggai
* haggai grabs a kshield and stands firm
<ogra> lol
<seb128> haggai: because you think than GNOME people like gaim ? :p
<dholbach> what are you guys playing, go fix https://www.ubuntulinux.org/wiki/UniverseDoesNotBuild :-)
<ogra> haggai, gaim is our nasty pet, every DE needs one ;)
<bob2> haha
<Treenaks> ready, gaim, fire?
* haggai gets a stick and starts teasing the gaimball with it
<bob2> go fix mono, you slackers
<Treenaks> bob2: go scratch you own itch
<Treenaks> :P
<bob2> hah, I wish
<jdub> anyone got a really wide screen?
<toresbe> I do
<bob2> jblack does
<jdub> res?
<toresbe> 42" 16:9 8somethingx6something
<jordi> Kamion, mvo: just before I leave: nano 1.3.6 in incoming/Debian experiemntal
<jordi> see you next week
<ogra> jdub, yep
<jdub> toresbe: ah, currently connected to your ubuntu box?
<jdub> ogra: res?
<toresbe> jdub: actually Debian
<ogra> 1280x800
<jdub> ok
<jdub> can you grab the following tarball
<jdub> unpack it into /usr/share/gdm/themes/Human
<jdub> (just files in the tarball, no basedir)
<jdub> and test it full screen?
<ogra> yup
<jdub> should just require New Login from system tools menu
<ogra> ok
<jdub> http://people.ubuntu.com/~jdub/random/gdm-theme.tar.gz
* jdub has crippling mail overload, isn't going to touch it until tomorrow (maybe)
<ogra> jdub, COOL
<ogra> and yes, it looks ok 
<jdub> fontsize is fine?
<ogra> hmm, hard to tell since my fontsize with nv is a bit to small anyway, but its the same size as the norma one has
<jdub> weird request -> if you have a digital camera, could you pop up a shot? :)
<ogra> jdub, sure
<bob2> hah
<dholbach> could someone have a look at  http://moz.gotdns.org/ubuntu/multisync.build  and tell me what could be wrong?
<jdub> anyone else downloaded and have comments?
<dholbach> (and yes, i updated the pbuilder :-))
<Treenaks> dholbach: ask seb?
<dholbach> Treenaks: i wanted to pester a wieder audience
<dholbach> wider
<Kamion> dholbach: out-of-date mirror?
<Treenaks> hi luis
<jdub> btw, latest yelp update gives us elite front page love :)
<dholbach> Kamion: i did both apt-get update and pbuilder update
<luis> morning, Treenaks
<Treenaks> jdub: "elite front page love"?
<Kamion> dholbach: that's why I said "mirror"
<dholbach> jdub: should only be 5.04 instead of 5.4
<dholbach> Kamion: erm
<jdub> dholbach: yeah, i know, doc bug
<jdub> Treenaks: run yelp
<ogra> jdub, www.grawert.net/gdm1.jpg www.grawert.net/gdm2.jpg
<jdub> ogra: thanks!
<ogra> jdub, but my font size is not a good example
<Treenaks> jdub: uh, I'm running SuSE now (office policy..)
<ogra> its to small anyway, with nvidia its 1pt bigger 
<jdub> ogra: that looks pretty reasonable though, even so
<jdub> ogra: want to make a small change and tell me how it looks?
<ogra> jdub, your work ?
<ogra> yup
<jdub> change line 14 to read:
<jdub>     <pos x="50%" y="33%" width="scale" height="15%" anchor="c"/>
<jdub> same as warty, with suggested changes from cliff
<ogra> ah
<ogra> jdub, i like the bigger logo (in opposition to others i heard here)
<jdub> another shot with that? :)
<ogra> okie
<jdub> hrm
<jdub> one thing i really miss in gimp
<jdub> sshots without window decorations
<bob2> dholbach: can you install it if you jump into the pbuilder chroot? (pbuilder login)
<Treenaks> jdub: what's why people invented xwd | xwdtopng :)
<dholbach> bob2: yeah
<bob2> that's weird
<ogra> jdub, www.grawert.net/gdm3.jpg
<dholbach> bob2: i'll re-create it
<jdub> ogra: ah, nice
<jdub> ogra: thanks heaps!
<ogra> youre welcome :)
<jdub> does it make you randy? :)
<ogra> YEAH
<jdub> rock :)
<zul> hey
<ogra> amu, tritium told me you reviewed kreciepes, could you please comment it on MOTUNewPackages, so we can upload it after the next review
<jdub> argh
* jdub growls at stupid firewall
<ogra> hey mako
<magnon> jdub: don't growl at it, it seems avengeful :)
<mako> ogra: hey there
<luis> morning, mako
<tritium> mako, remind me if we ever sign keys not to hold your passport ;)
<ogra> hehe
<ogra> tritium, i already held it in mataro, still washing my hands :)
<tritium> haha :)
<mako> it was *years* ago
<mako> :)
<mako> luis: morning!
<ogra> mako, tell that to my GF, i'm not allowed to touch her anymore *gg*
<Treenaks> omg.. I'm lucky I didn't touch it then :P
<ogra> heh
<Robot101> robot101@alpha:/data/isos/linux$ ls -la hoary-install-i386.iso
<Robot101> -rw-r--r--  1 robot101 robot101 613246976 2005-03-24 02:02 hoary-install-i386.iso
<Robot101> robot101@alpha:/data/isos/linux$ rsync -P rsync://releases.ubuntu.com/releases/hoary/hoary-preview-install-i386.iso hoary-install-i386.iso
<Robot101> skipping non-regular file "hoary-install-i386.iso"
<Robot101> lstat64("hoary-install-i386.iso", {st_mode=S_IFREG|0644, st_size=613246976, ...}) = 0
<Robot101> fstat64(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 2), ...}) = 0
<Robot101> what the hell?
<jdub> obviously needs more fibre
<Robot101> 0620 character device
<Robot101> not bloody likely
<Robot101> a mylex PCI raid controller no less
<Treenaks> nice
<trulux> howI'm having trouble with cdbs, is there any way to make it *not* overriding my CFLAGS?
<Robot101> hrm
<jbailey> trulux: Not noticably, no.  Your best bet is to set it to what you want it to be in the end.
<Robot101> the latter is statting the console, which is a char dev :D
<Treenaks> why does the back of my Palm Tungsten have the word "Culus" on it?
<trulux> jbailey: how can I make it, at least, appending CFLAGS of the Makefile before compiling?
<trulux> jbailey: it's overriding -fPIC so, libssp gets compiled as non-PIC ...
<adobbie> trulux: looks like you will just have to stop using CFLAGS for your fPIC
<trulux> adobbie: hah
<jbailey> trulux: Oy, I'm guessing that this is a Makefile based package without using autoconf/automake?
<trulux> jbailey: right
<jbailey> Lemme test something, hold a sec.
<jbailey> trulux: Override DEB_MAKE_INVOKE
<jbailey> The idea that I thought of won't work, so..
<jbailey> I would just do something like:
<Kamion> seb128: this rescue-check translation of yours looks wrong:
<Kamion>  msgid "Ubuntu Installer rescue mode"
<Kamion> -msgstr "Entrer dans le mode de rcupration"
<Kamion> +msgstr "Entrer dans le mode de rcupration de l'outil d'installation d'Ubuntu"
<Kamion> seb128: it's not "enter rescue mode", it's a heading displayed in the top left corner of the screen indicating that you're in rescue mode
<jbailey> trulux: Actually hmm..
<jbailey> trulux: Is your package ismple enough that just typing 'make' works when building by hand?
<jbailey> trulux: And is it a tarball build?
<Kamion> seb128: http://people.ubuntu.com/~cjwatson/installer-po/ updated, also base-config-po and shadow-po existing now because merging them caused too many weird fuzzies
<trulux> jbailey: yes
<jbailey> trulux: The complete version of what you want is '$(DEB_MAKE_ENVVARS) make -C $(DEB_BUILDDIR)', but if you're not in a tarball build or whatnot, you could get away with just defining it to make and be done with it.
<trulux> jbailey: it's http://pearls.tuxedo-es.org/libssp/ (tarball)
<trulux> jbailey: just that making shlibs not doing PIC code is an asspain
<jbailey> trulux: I don't really want to download the package now if I can avoid it.  Did defining DEB_MAKE_INVOKE work for you?
<trulux> jbailey: I'm trying another way
<trulux> avoiding cdbs
<ogra> trulux, btw, are you guys in #ubuntu-hardened aware of our universe NEW policy ? please make sure your universe packages apply to it if they dont do already... https://www.ubuntulinux.org/wiki/MOTUNewPackagesPolicy
<jbailey> trulux: Does that mean it didn't work, or did you not try it at all?
<trulux> ogra: oh, ok, thanks
<trulux> jbailey: just I saw my old package, that needs some fixes but among that, it works and shouldn't be hard to fix
<ogra> trulux, its just a bit QA and help for DDs that want to adopt packages from us :)
<ogra> trulux, but i guess you are working with pitti anyways for the QA...
<trulux> ogra: yeah, Martin rocks
<trulux> :D
<ogra> yup
<Mitario> lo everyone
<Robot101> lstat64("hoary-install-i386.iso", {st_mode=S_IFREG|0644, st_size=613246976, ...}) = 0
<Robot101>         if (!S_ISREG(file->mode)) {
<Robot101>                 rprintf(FINFO, "skipping non-regular file \"%s\"\n",
<Robot101>                         safe_fname(fname));
<Robot101>                 return;
<Robot101>         }
<Robot101> write(1, "skipping non-regular file \"hoary"..., 51skipping non-regular file "hoary-install-i386.iso"
<Robot101> why why why
<Robot101> NOOO
<Kamion> maybe mode is not the same sort of thing as (struct stat).st_mode
<Robot101> Kamion: hmm, good point
<trulux> are there any thoughts on upgrading sysvinit?
<adobbie> upgrading?
<zyga> bsdinit?
<adobbie> it works, don't touch it
<adobbie> that's what I say
<trulux> adobbie: and fuck the selinux kid who is porting patches
<trulux> ;)
<adobbie> that too ;)
<dholbach> re
<trulux> hey dholbach 
<dholbach> :-)
<jdub> so dudes
<jdub> a bunch of artwork updates
<jdub> let me know what you think -> jeff.waugh@ubuntu.com
<jdub> enjoy!
* jdub goes to bed.
<ogra> yeah
<dholbach> bye jdub 
<ogra> night jdub 
<Robot101> Kamion: it was the remote file that was a symlink, not the local file... feh
<kagou> hi
<zyga> how to teach autotools to extract N_ from .py.in files?
* lamont bbl
<Kamion> Robot101: heh
<Robot101> good error message *scowl*
<Robot101> the real file was in ../.pool/hoary-install-i386.iso, but you probably know that :)
<Kamion> for hoary-preview-install-i386.iso, yeah
<mvo> zyga: it dosn't do it alreay? is it in the POTFILES already?
<zyga> mov: I need N_
<zyga> mvo: BTW: I've got a patch for you 
<zyga> mvo: sending now
<mvo> zyga: thanks
<mvo> zyga: for the N_, have you tried "N_ = gettext.dummy" in the python source? it should be extracted then by autotools
<zyga> mvo: I've defined N_(foo) = foo
<zyga> mvo: see the patch, it's clumbsy but I'm python newbie 
<mvo> zyga: thanks for the patch :)
<mvo> zyga: I'll merge it later
<zyga> mvo: thanks :)
<seb128> Kamion: k for the translations, thanks
<fabbione> schweeb: ping?
<seb128> jdub: around ?
<ogra> seb128, aslee
<ogra> p
<seb128> he broke my gtk theme
<ogra> clearlooks ?
<seb128> yep, it looks like the default GNOME one now
* ogra hasnt logged out yet
<seb128> me neither
<ogra> again ?
<seb128> just started some new apps
<seb128> they are ugly
<ogra> mine look ok....
<seb128> after restarting the panel that's fine for it
<seb128> looks like a runtime b0rkage
<ogra> ah, wait update-manager is inthe background, not closed yet
<ogra> no change, looks ok
<ogra> seb128, killed the panel for a test, still looks ok....
<ogra> must be your system...
<seb128> hum
<ogra> heh, but gaim crashed ...
<seb128> blaming my system is easy
<seb128> I'll try that next time you open a bug :p
<ogra> heh
<ogra> normally i dont kill my panel, so i'm fine as it is.....
<seb128> after restarting apps that's fine again
<opi> Kamion, ping
<ogra> probably gnome-settings-daemon has a delay or something
<seb128> ogra: no, restarting g-s-d doesn't change the look of apps, that's weird
<ogra> oh
<opi> hi guys
<opi> Kamion, shadow-po and base-po are ready for .pl, the installer po files where posted to ubuntu-pl, we'll see if someone will help me with that
<opi> hi sven
<mdz> wolsisc
<mdz> morning
<Treenaks> wolsisc? :)
<mvo> morning mdz 
<zul> hey mdz 
<Kamion> opi: ok, will take submissions by e-mail as I said
<mdz> Treenaks: that's "morning" shifted right one key position on a dvorak layout
<mdz> on the right hand
<Treenaks> mdz: ah :)
<mdz> with the left hand in proper position
<Treenaks> I think we should adopt it :)
<opi> Kamion, my part was allready sent
<Kamion> opi: um
<Kamion> opi: $ msgfmt --statistics -o /dev/null pl.po
<Kamion> 24 translated messages, 2 fuzzy translations, 2 untranslated messages.
<Kamion> (shadow)
<Kamion> opi: I don't see how there can be only one fix :)
<opi> Kamion, hum.. :)
<opi> I'll look again
<Kamion> likewise I suspect base-config has some more
<Kamion> 98 translated messages, 16 fuzzy translations, 12 untranslated messages.
<Kamion> (that's before your changes)
<opi> Kamion, I would be *so* happy if your tool could tell me witch one of them are untranslated ;)
<opi> Kaloz, I'm looking at shadow now
<Kamion> opi: my tool?
<opi> msgfmt
<Kamion> I have never written any translation-handling tools
<Treenaks> opi: msgfmt is part of gettext, afaik
<Kamion> however there are many of them out there
<opi> Kaloz, I'll restate it, a tool you're using :)
<Kamion> I am not Kaloz
<Kamion> opi: msgattrib can tell you that
<dholbach> mvo: ETA? :-p
<Kamion> so 'msgattrib --untranslated pl.po', 'msgattrib --only-fuzzy pl.po'
<opi> Kamion, ok, got a shadow.po
<Kamion> also, gtranslator is in Ubuntu
<opi> Kamion, would you be so kind (I don't want to disturb you from work) a +/- difference between my submission to base-config and number of untranslated msgs?
<opi> Kamion, I'm at my gf parents house, and I've a Slackware laptop only ;)
<Kamion> slackware doesn't have gettext? surprising
<Kamion> opi: if you sent a full .po file as an attachment, that would be easier to do; as it is I will have to mess around a lot with merge tools :)
<Kamion> opi: "Hoary Headehog", really? :)
<Kamion> opi: you're still missing "A user account will be created [...] " and "Empty root password entered; using sudo." from shadow
<opi> Kamion, oh :o
<Kamion> those are fuzzy, i.e. gettext has made a guess at a similar translation, but it needs to be manually checked and in some cases retranslated
<zyga> Kamion: which pl.po is that?
<Kamion> zyga: shadow
<opi> zyga, yeah, the translation is missing: uywam sudo ;)
<opi> zyga, it's Fenio translation, empty password at Debian won't use sudo
<zyga> opi: :-)
<Kamion> that is not quite accurate
<Kamion> the translation is of "Empty password was entered."; the new msgid is "Empty root password entered; [...] "
<Kamion> sigh, translators are not reading translation comments either
<Kamion> #. However, translators are required to keep "Choose language"
<Kamion> #. as an alternative separated by the "/" character
<Kamion> #. Example (french): Choisir la langue/Choose language
<Kamion> -msgstr "Sprache whlen/Choose language"
<Kamion> +msgstr "Locale whlen"
<Kamion> ah, no, I take it back, that comment is for a different msgid
<opi> Kamion, .pl has /choose part
<opi> Kamion, shadow update has been sent
<Kamion> opi: it'll be fuzzy in the translation of "Choose a locale:"
<opi> Kamion, I hope you can throw rocks for that distance :-)
<Kamion> opi: thanks, will look in a bit
<mroth> if I have a bugzilla on gnome-theme-manager, should I file that under gnome-themes, or g-system-tools?
<mroth> on the theme manager itself, not the included theme files
<zyga> hey new artwork rocks
<zyga> who's doing that?
<zyga> :)
<opi> Kamion, I'm going for hunt on #fuzzy in base
<zyga> opi: need a hand?
<seb128> Mitario: are you sure than #166185 is a nautilus bug ?
<Mitario> seb128, seems like it to me
<Mitario> seb128, because trashapplet just moves or deletes the files using gnome_vfs
<seb128> k, your call
<seb128> this bug will probably stay here for months so :/
<seb128> but that works fine with the nautilus trash
<Mitario> seb128, yeah true, but.. i can't seem to fix it with trashapplet :-(
<seb128> have you tried to look on it ?
<seb128> nautilus is bug flooded
<seb128> it'll stay in the middle of the pile of bugs, that's why I've opened it on the applet
<Mitario> ah, well, i can think of no way how I can fix this in trashapplet
<Mitario> trashapplet just moves/deletes the files, nautilus should worry about displaying them
<Mitario> otherwise i would have gladly fixed it
<seb128> if you move a file from the command line that works
<seb128> I don't get why it would not work with the applet
<Mitario> me neither, maybe it's some error in gnome_vfs?
<seb128> I think that's due to the applet
<Mitario> hmm
<Mitario> ok well i'll try to investigate further, maybe some nautilus guy will correct me and tell me what i'm doing wrong ;-)
<mroth> seb128: filed a mostly cosmetic bug with g-t-m/capplets as #8199 , low priority IMHO
<dholbach> alright... have a nice day/evening/morning pals... i'm off - must run to get the train
<Mitario> cya dholbach 
<Lathiat> is inotify not in 2.6.10-5 ?
<Lathiat> ahh i see
<opi> zyga, are you on ubuntu-pl?
<zyga> opi: no
<zyga> opi: # or ml?
<opi> zyga, ml
<zyga> opi: developer or user ml?
<opi> zyga, ubuntu-pl :)
<opi> zyga, users
<zyga> opi: argh ;] 
<zyga> opi: no should I?
<opi> zyga, if you like, I've posted a translation request there
<opi> zyga, there's nice bunch of Ubuntu guys there
<zyga> opi: any archive?
<opi> sure
<zyga> opi: or request page?
<opi> http://lists.ubuntu.com
<opi> http://wiki.ubuntulinux.org/ListaDyskusyjna
* mvo leave to go to town
<zyga> opi: could you post an url to your translation request?
<opi> zyga, I'll cut & paste it on query
<opi> but I'll be off in a second
<opi> bbl :)
<zyga> opi: ?
<zyga> opi: ok
<kain> hi there, some recent upgrades broken Human icon theme
<crimsun> clearlooks 0.5, probably.
<kain> there were four folders under /usr/share/icons/Human/scalable
<kain> yes, I believe so
<kain> I see clearlooks were upgraded
<kain> but if I use human icons, most files doesn't show an icon
<kain> only folders
* netjoined: irc.freenode.net -> zelazny.freenode.net
<crimsun> it was discussed in here about 2 hours ago; have you restarted your applications, perhaps logged out and back in?
<kain> crimsun, yes, I've done everything, from reinstalling ubuntu-artwork and some packages to create a new user and log in
<kain> icons are missing
<crimsun> hum, I don't know off the top of my head
<ogra> kain, looks youre right, i just restarted nautilus and have the same effect with human
<kain> root@striker:/usr/share/icons/Human/scalable # ls -lh
<kain> totale 12K
<kain> drwxr-xr-x  2 root root 4,0K 2005-03-25 19:52 apps
<kain> drwxr-xr-x  2 root root 4,0K 2005-03-25 19:52 devices
<kain> drwxr-xr-x  2 root root 4,0K 2005-03-25 19:52 filesystems
<kain> there are three folders
<kain> and some icons are missing
<kain> I remember that were fours folders of icons
<kain> well
<kain> btw human icons looks great ;P
<kain> clearlooks window borders now seems similar to nvidia themes
<kain> some sort of 3d effect
<kain> I preferred the flat colro titlebar
<kain> :)
<kain> color*
<kain> hope a fixed package hits repositories soon
<ogra> kain, as soon as .au will wake up again someone will work on it ;)
<kain> ehe ok
<lamont-away> mdz: arouhnd?
<lamont> mdz: is woody->hoary upgrade path supported?
* lamont is looking at 2797, and if no, then that's NOTWARTY.  If yes, then it may be
<lamont> of course, the other question is, why didn't this affect woody->warty?
<mdz> lamont: yes I'm around, and no woody->hoary
<lamont> cool
* lamont marks the bug as such
<lamont> mdz: although 2797 probably applies to woody->warty, given the context
<lamont> mdz: 5379 may want a sync - but I'll let you make that call.
<mdz> lamont: fine with me
<lamont> ok - I'll request the sync then
* lamont wanders off for a bit, after playing with some  bugs
<Kamion> ok, now I'm really confused
<lamont> Kamion: that scares me
<Kamion> I thought if you had a base-0 cacherev on a baz branch, you didn't have to register the archive you branched from
<lamont> you might for merging?
<Kamion> i.e. colin.watson@canonical.com--2004/cdimage--mainline--0 -> colin.watson@canonical.com--2005/cdimage--mainline--0
<Kamion> screw merging, all I want to do is get
<lamont> (to branches where the common ancestor is on the branch-source, that is_)
<Kamion> and tla does it too
<lamont> you should be able to baz-get --2005
<Kamion> if I register the colin.watson@canonical.com--2005 archive and 'baz get colin.watson@canonical.com--2005/cdimage--mainline--0', it says "archive colin.watson@canonical.com--2004 is not registered"
<mdz> ew
<Kamion> tla is similar but even less helpful
<lamont> Kamion: and there's a cached rev for base-0?
<Kamion> lamont: yes
<lamont> beat on #arch, it sounds like
<Kamion> and patch-4, just to make sure
<Kamion> the idea of #arch scares me
<lamont> ??
<Kamion> a channel full of revision-control-heads ...
<lamont> oh, yeah.
<lamont> that.
<lamont> but it's a helpful bunch of revision-control-heads
* lamont looks at his watch, decides maybe it's time to wander down to the bandwidth-house to fetch today's isos and absent-bits for his mirror
<Kamion> oh, I bet I know
<lamont> ??
<Kamion> silly archive-mirror thought it would be fun not to mirror the cacherevs
<lamont> cache-revs are local to the mirror, I bet
<Kamion> they bloody well ought not to be
<lamont> that is, the revision cache is not part of the copy...
<Kamion> they get mirrored if you hit the thing harder (i.e. remove mirror, rebuild)
<lamont> heh
<lamont> file a bug against bazaar in bz, sounds like.
* lamont adds a canonical mapping on his mail server to change @ubunut.com into @ubuntu.com.
<lamont> it's that, or learn to type.
<zyga> lamont: hehe :-)
<lamont> zyga: done it one time too many.. :-)
<zyga> lamont: I've been working on a program called fcqp
<zyga> I only recently added rules that checked for fcpq
<lamont> lol
<zyga> the result was .... a bit of shame
<lamont> anyway, off to sit on the neighbor's porch.
<Kamion> lamont: filed in malone; https://launchpad.ubuntu.com/malone/bugs/264
* lamont-away should get a malone login
<lamont-away> or figure out what he has
<Kamion> I think it's the same as your wiki login
<Burgundavia> it is
<opi> and thanks gods for that
<opi> I should count once how much passwords I have ;)
<Kamion>   CHECKSUM FILE(S) DISAGREE WITH
<Kamion>   DIRECTORY LISTING ABOUT WHAT
<Kamion>   FILES SHOULD BE PRESENT IN
<Kamion>   REVISION DIR OF ARCHIVE
<Kamion> go baz
<schweeb> fabbione: yo
<trulux|working> are there any thoughts on upgrading Linux-PAM on Breezy?
<zyga> btw....
<zyga> is breezy the official name?
<lamont_r> breezy badger
<trulux|working> just finishing the work on SELinux
<trulux|working> at least on userland packages support
* lamont_r ponders how a 7MB .deb can be considered '"quickstart" :-)
<trulux|working> http://pearls.tuxedo-es.org/selinux/ubuntu/
<ogra> lamont_r, we live in a time where a 80GB HD is the standard onlaptops ;)
<zyga> ogra: IS NOT ;] 
* zyga speaking on p200, 4GB laptop
<zyga> 128MB really hurts on modern linux desktop
<ogra> zyga, when did you buy that one ?
<zyga> the only thing that works smoothly is gnome-terminal ;] 
<zyga> ogra: long time ago
<maswan> zyga: well, you should do alright as long as you don't try to use a graphical browser or something like that. :)
<zyga> ogra: but most new laptops have 40GB not 80
<ogra> zyga, i'm talking about current ones ;)
<zyga> maswan: actually links is a graphical browser but I tend to run it it text mode ;] 
<ogra> mine has 80, its 2 months old
<ogra> and no, it wasnt expensive....
<zyga> ogra: the cheapest laptops usually have 40 gigs
<zyga> ogra: where do you live?
<ogra> 1250 is mid class i would say
<ogra> zyga, .de
<adobbie> 512MB is pretty much minimum for a desktop or laptop these days
<zyga> adobbie: unfortunatly :/
<adobbie> my roomate needs more ram and he already has 1GB
<trulux|working> ogra: what the f*ck! in Spain you get an ibook for much less than that
<zyga> I'm going to buy an ibook 
<trulux|working> zyga: connected minds :)
<zyga> but I'm scared that 128/256 will be hell :/
<trulux|working> adobbie: hentai shouldn't cost that amount of ram
<zyga> powerbooks are way too pricy for me
<adobbie> zyga: it will be, I know from first hand experience
<trulux|working> adobbie: :)
<zyga> ogra: .pl 
<adobbie> zyga: if you don't plan to use openoffice or firefox you can probably survive
<zyga> ....
<zyga> firefox...
<zyga> that's a must :/
<zyga> anyways I'll try to upgrade the ram
<ogra> trulux|working, i wanted to own an ALPHA all my life since i had my first one in my hands ;) so i bought the successor, appledoesnt provide amd64 :)
<zyga> ogra: apple has g5's
<zyga> ogra: I've got amd64 too :-)
<ogra> zyga, for 1250 ??
<zyga> ogra: they're really sweet
<ogra> (g5 that is)
<zyga> ogra: no ;] 
<ogra> heh
<zyga> ogra: what's that funny utf-8 like char after 1250?
<adobbie> I want an Itanium :)
<adobbie> zyga: euro
<ogra> zyga, do you use xchat ?
<zyga> adobbie: itanium has great registers and calling conventions
<zyga> ogra: no
<ogra>  /charset utf-8
<ogra> ah, ok
<zyga> ogra: for 1250 euros you can get a pretty decent powerbook
<zyga> ogra: but they don't come with g5 :/
<ogra> with 80GIG hd and 512 MB ? 
<adobbie> zyga: I would expect that Itanium is all that is good about Intel minus the garbage that remains from backwards compatibility
<zyga> ogra: yes
<zyga> adobbie: and as popular as that garbage....
* ogra thinks he should buy his next laptop in poland :-P
<zyga> adobbie: win... oh you don't run well on itanium, sorry ;] 
<adobbie> zyga: damn, how could I survive without Windows...
<zyga> ogra: edu discounts from apple are nice, still they have way overpriced stuff
<zyga> ogra: I'm going to try though cause my last laptop (gericom, really shitty) falls apart
<ogra> heh
<zyga> ogra: for 1250 euros you can get amd64 in a laptop 17' box
<zyga> ogra: no warranty though ;] 
<ogra> zyga, thats what i have (apart from having a 15,4" display, since i want it transportable)
<zyga> ogra: (really serious and worth the money) [as long as you don't think where it came from] 
<zyga> ogra: I'm getting 12' 
<zyga> 15 is waaay to big unless you need to watch movies (i guess that'll make me more productive)
<ogra> zyga, i wanted a desktop replacement....
<zyga> ogra: me too at first
<ogra> so this was the compromise
<zyga> ogra: but then I realized that with lots of ram and remote storage I don't need hudge screens  ;] 
<zyga> ogra: and working in bed is great :>
<ogra> yup
<trulux|working> checking path to cracklib dictionary... configure: error: none found
<trulux|working> hah
<trulux|working> still dying there and I have now the dicts intalled
<zyga> trulux|working: anything you need?
<trulux|working> zyga: need to know why I'm getting "checking path to cracklib dictionary... configure: error: none found" with the dicts installed properly
<zyga> trulux|working: check the source and see where it tries to find your cracklib
<zyga> where is it on your system
<trulux|working> in the standard patch where Ubuntu installs it :)
<trulux|working> I'm building with debuild and getting that
<trulux|working> zyga: no idea?
<trulux|working> it's stopping me for doing my work
<crimsun> trulux|working: what package are you compiling?
<trulux|working> crimsun: a new PAM upgraded to 0.78, also going to apply some Fedora patches and fixes, among the SELinux support
<trulux|working> for Breezy
<crimsun> trulux|working: did you sudo apt-get build-dep pam?
<trulux|working> sure
<trulux|working> crimsun: *every* build dependency installed
<zyga> trulux|working: locate libcrack
<zyga> trulux|working: sudo updatedb # if you need
<trulux|working> /usr/lib/libcrack.so.2.7
<trulux|working>  /devel/hoary/usr/lib/libcrack.so.2.7
<trulux|working> everything *ok*
<trulux|working> no dicts, that's the fscking error
<crimsun> hum
<trulux|working> jezz, wasted 10 minutes with it and still not solved
<zyga> trulux|working: hmm
<zyga> trulux|working: can you locate the part of configure that tries to find your library?
<trulux|working> 2541:echo $ac_n "checking path to cracklib dictionary""... $ac_c" 1>&6
<trulux|working> 2542:echo "configure:2543: checking path to cracklib dictionary" >&5
<trulux|working> 2545:DICT_FILE_CANDIDATES="pw_dict cracklib_dict"
<trulux|working> I think I found it
<zyga> hmm
<trulux|working> it's always good to relax
<zyga> :)
<zyga> true true
<trulux|working> it's not my best day, just a mix of some bad conditions
<bluefoxicy> is shipit an ubuntu-devel or ubuntu-user topic?
<bluefoxicy> I want to be able to order just livecds, or bundles of boxes (30 to a box right?) with liveCDs and installCDs, individually boxed.
<bluefoxicy> I just don't like handing newbies install CDs
<bluefoxicy> because they'll erase their hard drives, seriously.
<bluefoxicy> they'll be like "Sweet this is cool, I'm gonna install it!  wtf why doesn't windows boot?!  Where'd unreal go?!"
<adobbie> bluefoxicy: unreal runs on Linux
<bluefoxicy> unreal doesn't come on ubuntu hoary main :)
<schweeb> bluefoxicy: ...
<schweeb> bluefoxicy: pretty sure that the livecd can install as well
<bluefoxicy> o.o;
<bluefoxicy> mine can't
<adobbie> bluefoxicy: users who don't read warning messages on the screen deserve to learn the hard way
<bluefoxicy> adobbie:  I want to convince my employer to distribute livecds
<bluefoxicy> so I can make more money
<bluefoxicy> by immediately becoming valuable when people suddenly want linux support.
<bluefoxicy> I made $239 (after taxes) on my first check :o  33 hours
<bluefoxicy> (very high values I have huh?)
<adobbie> not quite at the $100/hour level yet
<schweeb> (OT)
<bluefoxicy> adobbie:  10.5
<bluefoxicy> schweeb:  and since when do live cds do real install/upgrade
<schweeb> knoppix does it
<bluefoxicy> yeah, by copying the fs to the hard drive
<bluefoxicy> schweeb:  I meant more like  https://www.ubuntulinux.org/wiki/StaticMediaAccompanyingDebs (which was rejected on the list months ago btw, so won't happen)
<bluefoxicy> "This would hopefully facilitate a single Live/Install/NetInstall?/Rescue CD in the space of an 80 minute CD-R."  <-- should have said Live/Install/NetInstall/Upgrade/Rescue
#ubuntu-devel 2005-04-06
<low> hi there
<zul> high low
<low> :)
<zul> hah
<low> there's a little bug in lilo.conf when you use xfs (hoary-preview, amd64)
<low> kernel is /vmlinuz instead of /boot/vmlinuz
<schweeb> links should be made to vmlinuz in /
<schweeb> (they are on my system)
<low> at least lilo complains and returns with an error code during install, doing it by hand makes it complaining too, until i put in /target/etc/lilo.conf /boot/vmlinuz
<low> hmmm how to use install cd as rescue so i can solve last problems with lilo without reinstalling ?
<schweeb> you can also manually install grub to the mbr... the scripts won't work, but you can use the grub shell to embed it yourself
* schweeb did this on his laptop
<low> schweeb: grub does work on amd64 ?
<schweeb> I dunno, I would assume so
<low> schweeb: i'm coming for a source distro and i'm working a bit on amd64, and we were unable to make it work
<schweeb> yes, it works on amd64
<low> great :)
<low> i'll have to check how you did it
<schweeb> google for "grub embed"
<schweeb> I think it's in the manual as well
<low> hmmm looks like lilo borked my first sector of / (xfs)
<ogra> low, why did you use lilo ?
<ogra> (i am on amd64 ... with the default, which is grub)
<low> ogra: errr it was what it proposed to me
<Kamion> ogra: grub can't handle all situations; the installer switches to lilo sometimes
<ogra> thats why i put your name in front of the sentence, yes :)
<Kamion> ogra: xfs is one of those cases
<ogra> Kamion, oh, didnt know that
<ogra> Kamion, it wasnt the case on warty ....
<Kamion> low: if you're using the hoary install CD, type 'rescue' at the boot prompt
<Kamion> ogra: yes, warty just broke with XFS :P
<low> Kamion: thx.
<Kamion> (randomly, for some people, not everyone)
<ogra> Kamion, nope, worked fine for me
<ogra> heh
<Kamion> ogra: it's a race condition
<Kamion> thus "works for me" isn't enough, sadly
<lamont__r> Kamion: any new daily builds since this am?
<low> Kamion: i've already run grub with xfs as / without problem
<ogra> Kamion, i know, i saw the redhat fix of running grub twice :)
<Kamion> low: for some people, it's fine. for others, it breaks.
<low> Kamion: damn :( maybe sis+sata is the cursed couple ;)
<Kamion> *shrug* I have a cheapo laptop where it fails
<low> well, anyway, i'm off to bed, need to wake up in 5 hours
<low> thx for tips and help
<low> see ya
<lamont__r> % acpi
<lamont__r> %
<lamont__r> hrm... something's fishy....
<lamont__r> mjg59: you around?
<schweeb> Kamion: I've found using the grub shell and manually installing grub gets it to work... grub-install almost always fails
<schweeb> (w/ XFS>
<schweeb> s/>/)/
<schweeb> although that's more work than most people should have to do...
<zul> why dont you create a small boot partiion with someting like ext3 and then the rest xfs?
<ogra> zul, he is gone already
<zul> heh im so on holiday today ;)
<lamont__r> seb128: you around?
* lamont__r heads home
<mjg59> lamont-away: ?
<kain> hmm.. ubuntu-artwork 0.2.20-2 on hoary doesn't fix the human icon issue
<schweeb> mjg59: he just left for home
<mjg59> Ah
<zul> mjg59: hell be back soon
<lamont> mjg59: wondering why acpi isn't happy on my vaio....  what does pcc_acpi do, and should it be loaded as well as sony_acpi?
<lamont> hrm.. was it something I said? :-)
<zul> yes...yes it was
<trulux|working> hey zul 
<zul> hey Treenaks 
<zul> er..trulux
<zul> how is it going?
<lamont> evening zul
<zul> evening lamont how goes the battle?
<lamont> rather relaxing day
<zul> same here
<ogra> is it a public holiday in the us too ?
* lamont checks and finds only 2 udev-screwed chroots.
<lamont> sigh
<zul> canada as well
<lamont> ogra: not entirely 100% sure, but I've been making it a slow day
<ogra> ah, yeah
<lamont> like fetching isos, and such
<lamont> speaking of which, time to burn some
<tritium> not a public holiday, but many people take off for Good Friday
<tritium> zyga, what have you heard about powerbook g5?
<tritium> ogra, here's more goodness: Mar 25 13:21:34 localhost kernel: EXT3-fs warning (device hda1): ext3_unlink: Deleting nonexistent file (1130787), 0
<adobbie> no school today :)
<zul> i feel old now
<tseng> mako: ping
<adobbie> zul: grey haired?
<zul> adobbie: a bit
<adobbie> zul: ok, you probably are old then :)
<ogra> zul, you shouldnt say that while lamont and me are here ;)
<zul> adobbie, only 29
<mako> tseng: hey ddue
<ogra> heh, young guy
<tseng> mako: manoj signed my key!
* ogra doas the tseng dance
<mako> tseng: killer! 
<tseng> mako: do i need to resend you my coc, or you still have it
<ogra> finally
<adobbie> zul: that makes you 7 years old than I am
<zul> bleah
<ogra> and six younger then me :)
<zul> ogra: old foggie
<ogra> yeah, my beard is already graying out
<mako> ogra: dude.. unix beard time
<mako> i can't wait to pull off a unix beard
<ogra> hehe, you mean like maddog ?
<mako> totally
<mako> even rms now is greying out
<mako> maddog has a real unix beard
<ogra> ah, i think i'll wait 10 years for that
<ogra> yeah
<mako> http://www.urbandictionary.com/define.php?term=Unix+beard
<zul> heh i have a beard it just needs to be grey
<adobbie> I shaved this morning :)
<mdz> mako: I have not heard that term in general circulation, but it should be
<mako> mdz: dude, several years ago at LCA, there was a unix beard BOF (!!)
<tseng> mako: coc?
<mako> mdz: to discuss beard care, etc, i guess
<mako> once, three people with unix beards told me that i "didn't really have a beard"
<ogra> mako, ever had a beard ?
<mako> ogra: dude! i have a beard
<mako> ogra: you met me!
<ogra> mako, ah, come on, i mean a beard with some more expertise ;)
<ogra> mako, its itching like hell....
<mako> mdz: there must be some serious unix beards at nanog
<lamont> mako: and that's just the women. :-)
<lamont> hrm.. forget I said that.
<zul> you know that cheers episode where they have that beard competition?
<mdz> mako: there are _seas_ of them
<Kamion> mdz: please merge colin.watson@canonical.com--2005/casper--translations--0 again, up to patch-6
<mdz> Kamion: done, uploaded
<Kamion> Not sure how I ended up in the kind of position Christian Perrier fills in Debian ;)
<Keybuk> Kamion: maybe we should recruit him
<kain> any news on fixing ubuntu-artwork in hoary? I really like human icons but they're broken
<tseng> they work for me.. are you tracking this on bugzilla?
<kain> no, not yet, since I saw the new package, but it doesn't fix the problem
<kain> ogra also confirmed this problem
<ogra> tseng, are you up to date ? and did restart nautilus since he update ?
<ogra> the even
<tseng> i killed nautilus
<tseng> it still works.
<jdub> kain: what's broken?
<ogra> jdub, there is only the default icon
<kain> jdub, ubuntu human icon theme, there's something missing in package
<ogra> morning btw
<Kamion> Keybuk: he's certainly a competent installer / localisation guy
<lamont> hrm.. current world likes my vaio.  acpi happiness.
<ogra> jdub, mime types that is
<jdub> ah, i must've broken failover
<jdub> s/failover/fallback/
<kain> also,as said, I remember four directories under /usr/share/icons/Human/scalable
<kain> now they're three
<jdub> yeah, not really related
<kain> ok
<Keybuk> Kamion: yeah, he does l10n for dpkg and apt as well
* lamont pesters Kamion about the installers
<lamont> dhcp client
<lamont> where is that?
<Kamion> lamont: dhcp-client-udeb
* lamont prepares a patch
<lamont> dhcp2???
<Kamion> dhcp3 so didn't even remotely start to fit
<lamont> ah, yes.
<lamont> well.
* lamont makes dhcp2 also ask for interface-mtu
<lamont>         # install the udeb binary (no need to install dhclient-script
<lamont>         # since it is provided by another udeb package. See #249373)
<lamont> hrm.
<Kamion> netcfg has its own dhclient-script
<lamont> yeah
<Kamion> note I have a pending netcfg upload
<lamont> might be that the fix actually goes in dhcp-client-udeb...
<lamont> netcfg doesn't deliver dhclient.conf, yes?
<Kamion> lamont: it writes it itself
<Kamion> at run-time
<lamont> ah.
<Kamion>             fprintf(dc, "send host-name \"%s\";\n", dhostname);
<lamont> can you add 'request interface-mtu' in there somewhere?
<lamont> that is, add ",interface-mtu" to the request line?
<Kamion> definitely in "please send a patch" territory here :)
<Kamion> I don't feel confident munging that myself
<lamont> source name for netcfg?
<Kamion> netcfg
<lamont> oh. sure. who would think of that???
<lamont> :-)
<Kamion> testing it's a pig, though
<lamont> is that in the ramdisk?
<lamont> initrd
<Kamion> transferring an updated binary over on a USB stick is one option
<Kamion> lamont: it's in the netboot initrd, not the cdrom initrd
<Kamion> so you could bung a .deb on a CD
<lamont> kewlness.
* lamont has that technology.
<Kamion> can you rebuild him, though?
<lamont>             fprintf(dc, "send host-name \"%s\";\n", dhostname);
<lamont>             fprintf(dc, "request subnet-mask, broadcast-address, time-offset, routers,\n");
<lamont>             fprintf(dc, "       domain-name, domain-name-servers, host-name, interface-mtu;\n")
<lamont> I _think_ that's the defaults + mtu...
<lamont> does d-i care at all about time-offset?
<lamont> you have plans to test a new netcfg?
<lamont> and an in-house dhcp server?
<Kamion> well, so far mine's just YA translation upload, but sure, can do
<Kamion> and yes, have DHCP server
<Kamion> time-offset> no idea
<lamont> dhcp3 or something else?
<Kamion> whatever woody has, I guess
<Kamion> ii  dhcp           2.0pl5-11woody DHCP server for automatic IP address assignm
* lamont double checks syntax
<Kamion> won't you need to do something with interface-mtu, too?
<Kamion> and I guess s/       /\t/ for neatness :)
<lamont> uh, yes. But I think mtu was in dhclient-script in the system
<Kamion> oh yes
<lamont> $new_interface_mtu
<lamont> so it may just work
<lamont> in the subnet declaration in question, add 'option interface-mtu 1496;'
<lamont> then verify that the network is configured as such
<lamont> meanwhile, I'll root around in the server code some more and see if I can find the 'always send this option' option
<Kamion> is 1496 generally safe? other people are using this network
<lamont> well, it should really match across the entire network...
<kain> default here is 1492
<lamont> so you may want to create a bootp entry for the MAC in question
<kain> If i remember correctly
<Kamion> this is kind of not what I want to be doing at 1:30am :)
<lamont> Kamion: so if your lease time is long enough, and no one asks during the test...  
<lamont> change it back to 1500 and all is magically suddenly good.
<adobbie> I use 1492 for my MTU
<lamont> and you only lockup when you try to send a large packet from the 1500-machine to the 1496 machine.
* lamont will test
<Kamion> I could set 1500 and set -x / otherwise trace the dhclient-script
<lamont> Kamion: how soon you plan on netcfg upload?
<lamont> Kamion: that'd work
<Kamion> lamont: have a few others to do first and some base-config stuff to test
<Kamion> lamont: so no vast hurry
<Kamion> ok, will give it a go in a bit
<lamont> Kamion: btw, ia64 server install fails trying to install elilo on the disk...  you remember what the fix was for that?
<Kamion> lamont: all the fixes I remember, I've applied ...
<Kamion> /var/log/syslog and/or /var/log/messages ought to be enlightening
* jdub growls at mipsel
<jdub> i can't do big uploads through my firewall
<jdub> big being, like 4M (ubuntu-artwork)
<jdub> luckily there are lots of APs around ;)
<lamont> elilo: unrecognized option /dev/sda2 :-(
* lamont rolls it back to the top of the hill to manually partition
<dilinger> i'll never be a unix expert, i can't deal w/ the beard :/
<Kamion> lamont: erm - any idea where that might be coming from?
<Kamion> chroot /target /usr/sbin/elilo --autoconf --boot $bootpart \
<Kamion>       --root $rootfs --efiboot
<Kamion> oh, gar
<Kamion> I bet I know
<Kamion> lamont: could you stick 'set -x' near the top of /var/lib/dpkg/info/elilo-installer.postinst?
<Kamion> lamont: and make sure you only have one EFI partition (which I'm betting is your current state)
<lamont> uh, when I get back there...
<lamont> yep.  fdisk print just showed 1 partition
<Kamion> lamont: elmo complained about being asked a question with only one choice, so I lowered the priority in that case; only I suspect now that cdebconf doesn't set a sane default if that happens
<lamont> lol
<lamont> there are 2 drives on the machine, not sure what drive 2 looks like
<lamont> sda2 is the rootfs
<lamont> 1 = efi, 2=ext3, 3=swap
* Kamion compares with yaboot-installer
<lamont> elilo-installer instrumented, base install proceeding (again)(
<Kamion> patch written in the event it goes how I expect
<Kamion> namely, if you see 'bootpart=' in there
<Kamion> with no value
<lamont> cool.. I want to get my new mirror machine into production, you see...
<lamont> hrm.. it picked itanium-smp to install... that could be bad, can't remember
<Kamion> IIRC we talked about that and agreed
<lamont> ok
<Kamion> but hmm
* lamont was more introducer and/or conduit in that discussion
<Kamion> that is actually kind of odd
<Kamion> /var/log/syslog and /proc/cpuinfo would be useful to me
<lamont> machine is 2-way mckinley
<Kamion> then indeed I think it should have picked linux-mckinley-smp
<lamont> is there an ssh-client and/or netcat on the install disk?
<Kamion> openssh-client-udeb
<Kamion> nc is in busybox
<lamont> nc works
* lamont grumbles at archive-copier, watches it churn
* lamont remembers to fix the mtu before he does anything else
<Kamion> lamont: what, in a server install?
<lamont> yeagh
<Kamion> is b0rken then
<lamont> this AM's ia64 install, fwiw
<Kamion> lamont: oh. er. so how exactly are you doing this server install?
<lamont> vendor : GenuineIntel / arch : IA-64 / family : Itanium 2
<Kamion> 'cos elilo.conf kind of, er, doesn't have an entry for server
<lamont> at boot, adding 'server', otherwise picking the vga non-expert mode
<Kamion> lamont: that does precisely nothing ;)
<lamont> feh\
<lamont> what must one do?
<Kamion> are there some of these elilo.conf entries that I could sensibly trim?
<Kamion> one must boot with preseed/file=/cdrom/preseed/server.seed as kernel argument
<lamont> vga, serial clearly need to be there.  expert mode makes sense for both as well.
<lamont> ok
<Kamion> so I just have to double up all the entries?
<Kamion> I'm ambivalent about expert mode
<lamont> well, you could drop server-expert... :-)
<Kamion> people overuse it; I almost think we could drop it and tell people to boot with DEBCONF_PRIORITY=low if they care
<mdz> Kamion: I agree completely
<Kamion> I'm too cowardly to do that for !ia64 at this point, but I think I'll do it for ia64
<Kamion> hey, language-support-* is installable on ia64 now, so I can remove that hack ...
<Kamion> lamont: what do the 'processor' lines in /proc/cpuinfo look like?
<lamont> Kamion: http://ia.mmjgroup.com/~lamont/ia64/cpuinfo
<lamont> Mar 25 19:02:46 main-menu[5770] : (process:28216): bootpart=
<Kamion> lamont: bingo; willfix
<lamont> should be /dev/sda1 for me>
<lamont> ?
<Kamion> I guess, whatever your EFI partition is anyway
<lamont> cute part is that after the failure, it prompts you to answer the question... :-)
<Kamion> lamont: yeah, your priority will get dropped - and then it should work
<lamont> well, not 100% sure -- I edited the script and hardcoded /dev/sda1 :0-
<Kamion> hah
<Kamion> lamont: /var/log/syslog should have some wittering from base-installer about what it was thinking when selecting the kernel
<lamont> ROTFL
<lamont> Mar 25 18:55:05 base-installer: info: Found kernels 'linux-itanium-smp,linux-mckinley-smp,linux-image-itanium-smp,linux-image-mckinley-smp,linux-image-2.6.10-5-mckinley-smp,linux-image-2.6.10-5-itanium-smp'
<lamont> Mar 25 18:55:05 base-installer: info: arch_kernel: linux-mckinley (absent)
<lamont> Mar 25 18:55:05 base-installer: info: Using kernel 'linux-itanium-smp'
<lamont> btw, syslog in the same directory
* lamont copied all of /var/log
<Kamion> oh, your cpuinfo is only reporting one processor
<Kamion> what's the Right Way to find out the number of processors?
<lamont> hrm... maybe I am UP...
<lamont> checking
<Kamion> it should be running an SMP kernel, even
* lamont grumbles.  is uniprocessor machine. :-(
<lamont> gonna have to pester the nice men
<Kamion> lamont: elilo-installer fix uploading
<lamont> and yeah, mckinley-UP should pick mckinley-SMP (since no UP on CD)
* lamont really does a server install this time..  and will verify the question thing from elilo-installer
<Kamion> lamont: ok. I can only think of one way to fix that without rather more serious upstream churn in base-installer, and it's a grievous hack
<Kamion> basically
<Kamion> -         chroot /target apt-cache search ^linux- | grep '^linux-\(amd64\|386\|686\|k7\|power\|itanium\|mckinley\|sparc\|hppa\)';
<Kamion> +         chroot /target apt-cache search ^linux- | grep '^linux-mckinley';
<lamont> oh, that's vile.
<Kamion> +         chroot /target apt-cache search ^linux- | grep '^linux-\(amd64\|386\|686\|k7\|power\|itanium\|sparc\|hppa\)';
<Kamion> or something along those lines
<lamont> is that to get the order correct/
<Kamion> I think that makes me just too ill though
<lamont> ?
<lamont> yeah -not worth doing
<lamont> since really, you're going to want to load a tuned kernel next anyway, ...
<Kamion> lamont: it's more because it's damned hard to detect which ones are the metapackages
<lamont> the other solution would be to include a linux-mckinley (not smp) kernel
<Kamion> without just hardcoding a stupid list like the above
<Kamion> that'd suck a lot of CD space
<lamont> Kamion: not true.  anything with a size less than 2MB is a meta package. :-)
* lamont vomits
<Kamion> haha
<lamont> well.... 'tis truth, it is... :-)
<Kamion> you know, that's actually the least bad option I've heard, horrible though it is
<Kamion> but I think it should be in the "dirty hacks and how we can purge them" BOF at UDU
<lamont> yes
<lamont> I prefer to think of it as an elegant solution, not a gross hack. :-()
<aj> why don't you just tag the metapackages in the Packages file?
<lamont> aj: was just going to suggest adding something to the packages file..
<lamont> Task: linux-meta
<Kamion> I think we thought about that, but apt-cache search wouldn't show them up, and we don't have many cleverer tools at that point
<aj> i mean, apt-ftparchive does extraoverrides these days
<lamont> or even kernel-meta
<aj> you could have "Meta: yes" easily enough
<Kamion> also we only seem to remember to look at this issue ten days or so before release ;) it was the same last time round, it was a last-minute thing ...
<aj> Kamion: eh?
<Kamion> aj: can you search on random headers with apt-cache?
<lamont> Kamion: yep. question works, even without modifying the script. ;-)
<Kamion> lamont: with new elilo-installer? that was quick
<lamont> no
<lamont> old elilo-installer, hit return a couple times after the failure
<lamont> (prompted, and then it works0
<lamont> Kamion: you know, given the state of ia64/desktop, and the direction everyone is going with ia64, you could just make server the default... :)
<Kamion> hm, I suppose I could use apt-cache search --full and then clever, er, something
<Kamion> lamont: it is tempting
<lamont> Kamion: I bet mdz would be OK with it. :-)
<aj> Kamion: pipe --full through grep-dctrl?
<Kamion> aj: don't have it there; we've only just installed the base system
<aj> Kamion: what're you trying to do?
<Kamion> aj: this is base-installer's logic to select the right kernel to install
<aj> Kamion: well, awk'll suffice anyway
<Kamion> no awk
<Kamion> oh, I do
<Kamion> I could chroot
<aj> i thought you installed the base system?
<Kamion> yeah, was in automatic "no awk in busybox" mode
<aj> oh, hrm
<aj> i was going to add something fairly similar to debootstrap's little C helper
<Kamion> have chroot /target perl, even
<Kamion> C is OK, just typically more effort and larger; but base-installer already has a bit of C code in it to interact with debootstrap
<Kamion> and b-i doesn't really have to be ultra-small
<aj> well, it was more going to be "pkgdetails list Base: yes /target/var/lib/apt/lists/debootstrap_Packages" or so
<Kamion> archive-copier has something very similar
<aj> but that's waiting on some apt-ftparchive changes i haven't gotten around to cleaning up for mdz yet
<Kamion> Ubuntu CDs have Task: ubuntu-base now, if that'd be helpful for testing debootstrap stuff
<Kamion> although it probably includes kernel packages and bootloaders and such that aren't appropriate in debootstrap, so blah
<aj> nah, the apt-ftparchive stuff just needs to be the per-arch-extraoverrides
<aj> then it's just moving debootstrap's idea of base into the packages file
<aj> not much testing required
<Kamion> hah, yeah, half the reason I have Task: ubuntu-base on the CD is that I needed to hack around the lack of per-arch extraoverrides
<Kamion> Task: ubuntu-desktop needed to be different on different architectures, in some cases
<Kamion> and the rest fell out in the wash
<lamont> hrmpf.  could have sworn I uploaded the new dhcp3 yesterday
<lamont> daniels around?
<Kamion> lamont: so, what should I do about netcfg?
<Kamion> I could just upload what I've got here to get the translation stats right, and then you can fix up what you need ...
<Kamion> I think I'm too tired to do sensible testing myself
<LeeJunFan> are debian-cd utils the best way to go to make a DVD/RW or 2 with main,universe? I have a local mirror with debmirror.
<bluefoxicy> Is Ubuntu gonna use a dynamic theme when cairo comes into gtk+ main for ubuntu?  :)
<mjg59> lamont: pcc_acpi is for Panasonics - it'll often end up loaded even when it's not strictly necessary (acpi has no infrastructure for hotplug yet)
<dilinger> luminosity as the default wm for bendy/breezy.  that's what i'm gonna push for ;)
<Kamion> LeeJunFan: haven't quite finished exporting my debian-cd branch to the world; it's nearly there but not quite
<Kamion> LeeJunFan: come back in a few days and I should have it sorted :)
* mjg59 heads to bed
<LeeJunFan> Kamion: thanks. I have a load of friends who are gonna want to install ubuntu/kubuntu that have dial-up :)
<Kamion> LeeJunFan: we already produce a DVD of all the supported packages
<Kamion> if they're utterly and unredeemably desperate for something from universe, we'd like to know so that we can decide if it should be supported ...
<Kamion> lamont: I've gone ahead and uploaded netcfg 1.08ubuntu5 with just the translation fixes, since I need to sleep soon
<Kamion> lamont: go ahead and do whatever you need to do to its DHCP code if you've had a chance to test it
<LeeJunFan> Kamion: no, mostly newbies - they don't know what they want yet. But I know a few of them want kde default, and the DVD's currently seem to be ubuntu flavored only.
<LeeJunFan> granted they could apt kde, but...
<Kamion> LeeJunFan: there's a Kubuntu DVD too
<Kamion> separate
<Kamion> http://cdimage.ubuntu.com/kubuntu/dvd/
* Kamion -> bed
<zul> dilinger: why?
<lamont> Kamion: will do
<lamont> why isn't openssh-server in ship seed???
<Kamion> ship: * ssh
<Kamion> lamont: ssh dep openssh-server
* Kamion -> really bed this time :)
<lamont> Kamion: hrm... it's not on the CD...
* lamont notes idly that mvo made the process of building bastardized CD's far more complicated.
* lamont isn't sure whether he likes or hates that more.
<lu|away> ?
<lamont> archive is signed and checked by the install process.
<lamont> so, you first have to hack over the ubuntu-keyring package.  Then, having hacked over everything you care about, you have to build and sign valid Release files.
<lamont> well, an alternative to the first would be to break the archive signing key, but that would be bad, as well as computationally intensive.
<Lathiat> heh
<Lathiat> fun
<lamont> Lathiat: something like that
<lamont> would be more fun if it actually had worked
<lamont> grumble
* lamont sleeps
<fabbione> morning everyone
<tritium> good morning, fabbione :)
<schweeb> fabbione: you wanted something earlier?
<fabbione> schweeb: yes :-)
<fabbione> i am working on xen kernel side atm...
<schweeb> cool
<fabbione> and i am trying to integrate it directly into the standard kernel
<schweeb> oh really?
<fabbione> what is the status for userland?
<fabbione> schweeb: try != it will be there
<schweeb> heh
<fabbione> the build part of it is a bit complex
<schweeb> well, you said the userspace only works properly with python 2.3?
<fabbione> or better...
<fabbione> schweeb: yes.
<fabbione> so you need to Build-Dep and patch to use python2.3
<fabbione> or talk with upstream about 2.4
<schweeb> patch to use 2.3? it doesn't work oob w/ 2.3?
<fabbione> also.. did you see the xen packages in debian?
<schweeb> yea
<schweeb> doogie's
<fabbione> yes
<schweeb> they're kinda messy IMO, so I started my own
<fabbione> there are a bunch ofpatches you might want to steal
<schweeb> done :)
<schweeb> about 5 patches, 3 of which were truly necessary
<fabbione> i think they are pretty clean, excluding the kernel part that we might not need at all
<schweeb> the rules file was goofy... manually moving files and stuff
* schweeb likes using the debhelper tools for everything
<fabbione> schweeb: moving file manually has nothing to do with being a clean package :-)
<fabbione> it's the resulting deb that it is important
<schweeb> heh
<fabbione> but clearly a clean debian/rules helps maintaing the package
<schweeb> yea, I like clean debian/rules
<fabbione> so do i
<schweeb> using cdbs
<Amaranth> cdbs > *
<schweeb> one of my MAIN problems with his package is that he was using some goofy new patch management system he came up with
<schweeb> the patches are pre-applied...
<Amaranth> i had a hackish rules file that i couldn't even understand, cdbs makes it 4 lines
<schweeb> I don't like that much
<schweeb> dpatch is <3
<schweeb> fabbione: you think you'll have a kernel ready for release? do you want to try for the userspace in universe?
<schweeb> I could do it, but it'd take a bit of massaging
<fabbione> schweeb: it's all written in README.build (about the new patch management system)
<schweeb> yea, I think it's goofy :)
<fabbione> schweeb: i might get a kernel, but clearly not inside the archive for hoary
<fabbione> schweeb: this is for breezy
<schweeb> okay
<schweeb> well, I'll focus on some other universe packages for the next week or so (I'm going for MOTU), and then I'll start back on my packages
<fabbione> schweeb: sure. make sence
<aalam> hi all,
<aalam>  i want to start Punjabi Language for Ubuntu, can anybody help me??
<schweeb> I think you want to look into Rosetta
<schweeb> although, I'm not sure the status of Rosetta translation yet...
<aalam> yes
<myles3> sabmoc are you here
<schweeb> http://www.ubuntulinux.org/wiki/TranslationTeam
<sabmoc> myles3: ues
<schweeb> and https://launchpad.ubuntulinux.org/rosetta
<schweeb> er
<schweeb> https://launchpad.ubuntu.com/rosetta
<aalam> i check first two
<sabmoc> myles3: If you can set it up then go for it
<myles3> sabmoc: cool i can also setup the forum
<myles3> sabmoc: i have php and mysql
<sabmoc> myles3: alright
<sabmoc> myles3: Im actually excited :)
<sabmoc> myles3: let us know when its ready, im looking forward to it
<aalam> sabmoc, thanks
<sabmoc> ryan and me will get the pybloxsom site up as soon as I get a hold of him
<sabmoc> aalam: ?
<myles3> sabmoc: do you wnat me to setup a forum to?
<sabmoc> myles3: dont worry about that for now, if you want to set it up so its ready go ahead but I dont think we'll use it much for a while yet
<sabmoc> eventually yes, but not right now
<myles3> do you want ftp accuse
<sabmoc> myles3: no need
<myles3> okay but what about the domain
<sabmoc> we will have to talk to smurfix, but I think he is sleeping
<smurfix> sabmoc: not any more ;-)
<sabmoc> hehe
<sabmoc> smurfix: so pybloxsom is no problem
<aalam> sabmoc, sorry, i want to say to schweeb :)
<sabmoc> aalam: np 
<fabbione> for i in 386-xen0 386 386-xenu 686 686-xen0 686-smp 686-xenu k7 k7-xen0 k7-smp k7-xenu; do \
<fabbione> schweeb: ^
<sabmoc> smurfix: I am just waiting for ryan, I will help him with the ssh signing and whatever
<schweeb> fabbione: you're making all of those? damn
<smurfix> sabmoc: OK, installed. Can y'all take this to ubuntu-ca? It's somewhat offtopic here.
<sabmoc> yep
<fabbione> schweeb: we need the xen0 and xenU per flavour :(
<schweeb> yea :-/
<schweeb> so what's going on? you're gonna try to merge the Xen patches into the ubuntu patched kernels?
<fabbione> schweeb: kinda
<fabbione> yes
<schweeb> it'd be really nice if Xen would get accepted into kernel main, eh ;)
<schweeb> sparse tree is kinda annoying
<fabbione> schweeb: i agree, and the generic part of the patch is not really intrusive
<schweeb> are you actually employed by Canonical? /me has a hard time keeping track of who is and who isn't
<fabbione> schweeb: yes, but that shouldn't really make any difference :-)
<schweeb> just curious, heh
<schweeb> it's nice to know who's who 
<fabbione> schweeb: well you can consider me as your god, i have kernel privileges on all your ubuntu machines
<fabbione> :)
<schweeb> lol
<schweeb> ubuntu is the only distro where I  haven't felt the need to compile my own from vanilla so far
<fabbione> :)
<Lathiat> haha yeh
<Lathiat> theyre nice, helps having the restricted modules package too
<schweeb> I'm not afraid to compile the nvidia drivers :)
<Lathiat> oh i run binary nvidia drivers anyway
<Lathiat> cus my suspend works with the latest ones
<Lathiat> but having ipw2200 by default is a bonus
<schweeb> I just got lazy with kernels
<Lathiat> and i need a faster ninternet connection
<Lathiat> 54K/s just isnt fast enough
<schweeb> back when 2.5.x was around, I was always running the latest ck patches and shit
<Lathiat> haha
<Lathiat> i never ran 2.5 much
<Lathiat> i followed early 2.6 pretty close tho
<Lathiat> usually with the mm patchset
<schweeb> it was rather thrilling
<schweeb> yea, up until 2.6.7 or so I always ran mm patchsets
<Lathiat> i just run ubuntu stock now, these days when i try to make my own kernel its all pain :)
<Lathiat> usually cus im tryign to get swsusp2 going with an initrd but meh
<Lathiat> new gtk/metacity/etc themes are rocking, not too fond of the gnome splash tho
<pitti> Hi everybody
<fabbione> hey pitti
<pitti> fabbione: the bluetooth bug we talked about is public
<pitti> fabbione: so I guess we fix this immediately after RC?
<fabbione> pitti: ok, can you send me the usual stuff via email?
<fabbione> pitti: or now..
<fabbione> mdz: ?
<pitti> fabbione: sent
<fabbione> pitti: thanks
<geneo93> would anyone be interested in a file sharing app that uses qt and a muscled server
<Roey> hi
<Roey> oh
<Roey> great, this place exists.
<Roey> this is a devel question I think, because a kernel module package is refusing to compile under the ubuntu kernel it was produced for
<Roey> http://rafb.net/paste/results/vH9gKH96.html
<Mowa> hey google :)  http://www.playzero.com
<Roey> hey google/?
<mdz> fabbione: ?
<pitti> mdz: he's already away for family stuff
<pitti> mdz: the bluetooth vuln we talked about is public now
<Roey> fabbione:  nevermind, I fixed it.  The problem was that I was installing modules for the ubuntu kernel yet /boot/vmlinuz and /usr/src/linux were symlinked to my custom kernel (2.6.11.5, which you see in the error text I posted)
<Roey> please disregard, then
<pitti> mdz: the patch itself is trivial, but nevertheless you might want it fixed after RC?
<pitti> mdz: gotta go, too now
<pitti> happy Easter everybody!
<dholbach> goooood morning! how are you all?
<kain> hi
<kain> today I downloaded the new fix and upstream release for ubuntu-artwork in hoary, now the icons using the human icon theme shows up, but they're from the Gnome theme, not from the human theme. human icon theme is missing /usr/share/icons/Human/mimetypes again
<zyga> hello
<zyga> dhdpc had a bug in latest update
<zyga> comma was missing in /etc/dhcp3/dhclient.conf
<dholbach> could you post the diff in a bugreport on bugzilla?
<Mitario> hi everyone
<mantiena> amu: hi, do you need live-installer sources ?
<claude> enrico, you speek french ?
<enrico> claude: bien sur!
<claude> ah... j'ai plus de facilit  crire le franais quand mme :)
<claude> c'est au sujet des traductions de la doc
<enrico> claude: oui, mais ceci c'est  un canal en anglais
<claude> ok so let's try in english :P
<claude> did you think about my mail ?
<claude> what solution could we imagine to facilitate the translation of ubuntu-doc
<enrico> claude: I have no idea
<enrico> that's why I asked the translators
<enrico> :)
<claude> i think the core team should think about it
<claude> it's very important that official Ubuntu doc be available in other languages
<enrico> It sure is important
<claude> maybe you could open a svn rep for each language ?
<claude> but the difficulty is to keep in synch different languages
<enrico> Those repos would be unused if the translators don't need them
<claude> what about rosetta ?
<enrico> claude: ask carlos :)
<claude> hi carlos
<claude> we're talking about ubuntu doc translation
* carlos hides
<carlos> what? what?
<carlos> :-D
<carlos> morning
<claude> lol
<carlos> claude: what do you want to know?
<claude> you told in a mail that Rosetta team would soon start looking into documentation translation
<claude> would it be possible that ubuntu doc pot files be available in Rosetta soon ?
<claude> btw, there is problems in Rosetta just now
<carlos> claude: we don't have a concrete date for it, our main goal is getting all Hoary .pot/.po imported into Rosetta
<carlos> but, I think it's easy to reuse
<carlos> our current system to import also the documentation
<carlos> claude: yeah, I know :-(
<claude> enrico just send us pot file for about-ubuntu
<claude> could it be inserted in Rosetta for testing ?
<carlos> so, perhaps (please, don't take it as a compromise, our main goal are normal translations), at the end of this week we could look into a way to import the documentation as .pot files if you supply us a specific tarball format with the .pot and any existing .po file
<enrico> carlos: so, About Ubuntu and Release Notes will be untranslated when Hoary releases?
<carlos> the idea is that this Tuesday, Rosetta let you translate Hoary's .pot files
<zyga> dholbach: I'll try
<zyga> dholbach: I've observed this on my parent's box
<zyga> dholbach: I'm doing an upgrade here now 
<carlos> enrico: as I said, we could try to import them into Rosetta automatically but only if the normal import works and it's ready in time
<claude> carlos: can we imagine that translations be added into Hoary updates after the official release ? 
<carlos> claude: that's exactly the point behind the language packs
<zyga> dholbach: It's already filed
<zyga> https://bugzilla.ubuntu.com/show_bug.cgi?id=8213
<zyga> that's a really nasty bug
<carlos> claude: I'm going to paste some info at #ubuntu-doc about the way to import the documentation into rosetta
<zyga> withoug human intevention people loose net access :/
<zyga> lamont: ping?
<mantiena> Kamion: hi, could you tell me how to make partman and other standart ubuntu-installer modules start after casper module (I added install-mode parameter to casper and in install mode casper doesn't start init from filesystem.cloop) ?
<trulux> heya pitti 
<trulux> pitti: wooka!
<trulux> :)
<dholbach> hey pitti
<trulux> pitti: libssp 1.3.1-1 finished, we're ready to go forward to the toolchain mods
<adobbie> trulux: source is at same URL as before?
<trulux> adobbie: right
<trulux> adobbie: http://pearls.tuxedo-es.org/libssp/
<adobbie> I'm up at 6am on a saturday so I think I have some time to look at it :)
<trulux> adobbie: great, the package will leave Lintian pleasing ;)
<adobbie> objdump: debian/libssp1/usr/lib/libssp.so: File format not recognized
<trulux> oops
<adobbie> still see that though
<trulux> adobbie: hah, NP, libssp.so on /usr/lib/ is an ld-script
<trulux> adobbie: it's ASCII
<trulux> btw
<trulux> anyone knows how to import pages on MediaWiki =>1.4rc1?
<trulux> it's frustrating me
<adobbie> yes, I know :)
<adobbie> I wrote the original one
<adobbie> more of a cut and paste from something else though
<trulux> hehe
<trulux> maybe the Ulrich Drepper DSO howto had something to do with it ;D
<adobbie> apparently PaX has issues with my perl
<adobbie> I think there must be another bug
<trulux> what happens?
<adobbie> perl locks into some kind of infinite loop
<adobbie> 100% CPU
<adobbie> but only under high system load
<Kamion> zyga: fixed
<adobbie> that's why my defoma was running indefinitely yesterday
<zyga> Kamion: thanks
<zyga> How to force update-po to get both of ngettext's arguments?
<zyga> I'm hacking update-manager again
<zyga> and just cant understand how python's update-po works 
<zyga> (or - update-po for python source code)
<zyga> in C it "just worked" (tm)
<zyga> pitti: hi :-)
<ggi> Is the ubuntu-artwork version of the clearlooks theme (Human) kept in sync with the current version of gtk2-engines-clearlooks? I've noticed that a bug which was fixed in the 0.5 release of clearlooks is still present in the Human theme (and not present in the current version of gtk2-engines-clearlooks).
<zyga> ggi: you could try to mail the maintainer
<zyga> [of the ubuntu package] 
<_d4vid> hi all
<mantiena> mdz: hi, are you online ?
<mantiena> I wonder where it would be better to mount hard disk partitions, which are in user's hard drive(s), for example windows C and D disks or linux partition from other distributions... According to FHS 2.3 /mnt should be never used for permanent mounts, so, maybe in /media ?
<zyga> mantiena: maybe /windows or /media/windows
<Micksa> why would hoary's apt ignore some archives? does it require stuff to be signed?...
<Micksa> ah....
<dholbach> bbl
<mantiena> zyga: /windows (directly from / ) isn't good choice, because in general there could be a lot of different partitions in user's hard drive(s), not only windows partitions, but also partitions from other Linux or *bsd, distributions, dos partitions or some special partitions created for user's needs, for example I have portable 80 Gb hard drive (which is connected throught IDE interface) with ext3 filesystem for my digital video.
<zyga> mantiena: true, then maybe /media/partitions/*
<zyga> mantiena: then you could have all bsd,fat and cherry-on-top if you like
<mantiena> zyga: ;)
<Mithrandir> pmount mounts them in /media/$partitionname by default
<Kamion> zyga: er, you might as well call it /media/media/* :P
<Kamion> I see no reason for a subdirectory of /media
<Mithrandir> Kamion: /media/media/media! :P
<Kamion> what's wrong with just /media/$devicename, like pmount?
<mantiena> Mithrandir: pmount works only with removable storage, but I'm talking about IDE and SCSI hard disks
<Kamion> mantiena: that doesn't mean you can't put static mounts in the same place
<mantiena> Kamion: I think it's fine /media/$devicename
<Mithrandir> mantiena: why would you want a different scheme for static stuff?
<mantiena> Mithrandir: I don't want different ;)
<Mithrandir> ook :)
<zyga> Kamion: well it gives a distinction from /media/cdrom so /media/hard-disks/foo is better then having /media cluttered
<mantiena> I think /media is the best ;)
<Kamion> zyga: strongly disagree - it's /media/cdrom because it's /dev/cdrom
<Kamion> predictability and consistency is important
<zyga> Kamion: and if you have 20 partitions it's /media/hd[a-z] [0-9]  ? 
<mantiena> but I don't want to be uncompatible with ubuntu (at least from users view), so I'm asking ubuntu developers opinion ;)
<Mithrandir> zyga: /media won't be cluttered much, if you have more than ten hard drives connected to a computer, you're fairly exceptional and can probably deal with it
<Kamion> zyga: yep. that's fine.
<Mithrandir> zyga: 20 partitions?  Use labels and you'll have /media/random-windows-foo, /media/music and so on.
<mantiena> zyga: in any case, if user has zillion partitions, then it's users problem, not us ;)
<zyga> hehe, maybe so ;-)
<zyga> Kamion: I like when usb sticks get their labels right
<zyga> so it's /media/foo-usb-stick 
<zyga> and at the same time /media/bar-usb-stick
<Kamion> gar, I hate the bugzilla-spam "let's leave the same comment in three different bugs all assigned to the same person" approach
<mantiena> in windows user gets a lot of logical drives (c,d,e,f,g, etc) if he has zillion partitions, so it seems he don't wouldn't want to have too many partitions ;)
<mantiena> s/don't//
<mantiena> Kamion: I wanna put draft specification of partition-finder component at http://www.ubuntulinux.org/wiki/InstallerTeam
<mantiena> is this correct place ?
<Mithrandir> mantiena: you would probably make a new page
<mantiena> Mithrandir: yes, but at which place ?
<zyga> mantiena: hmm BTW how do I extract windows partition name?
<Kamion> mantiena: I don't really care as long as you don't dump it inline into the InstallerTeam page :)
<Mithrandir> mantiena: just name it PartitionFinder or something.
<mantiena> Kamion: previously you told me, that name "partition-finder" is not good for such component, maybe you could suggest better name ?
<zyga> Who writes changelog.Debian files?
<Kamion> well, you're clearly not finding partitions, but looking inside them; partition-prober might be a better name
<Kamion> zyga: each individual developer
<Kamion> mantiena: might also be worth pondering how much of your code would be shared with os-prober, and how to cope with that
<Kamion> you could conceivably change the os-prober source package to have it spit out a second binary package, so that you don't have to clone-and-hack the code
<mantiena> Kamion: so, you suggest to make 2 binary packages (os-prober and partition-finder) from single os-prober source packages ?
<oly> hi, Seveans told me to ask if the nforce onboard network card is stil supported 
<oly> since the update this morning, it has been broken 
<oly> i know there was a bug in the packages 
<oly> and have the newer ones now, but the nforce card still does not work 
<oly> but another card does
<oly> mii-diag eth0 returns SIOCGMIIPHY on eth0 failed: Operation not supported
<Kamion> mantiena: os-prober and partition-prober unless you insist on the misleading partition-finder name; but yeah, that's just one suggestion off the top of my head, don't take it as holy word or anything
<restrex> hi guyz... when I enable inotify at the /boot/grub/menu.lst, the gnome session paralize when it's booting, when I disable inotify the gnome session starts normally, How can I fix it?? thanks
<oly> the card worked perfectly this morning though,
<Kamion> mantiena: and I only said "look at it and see how much code you're sharing"; the answer will depend on that
<Kamion> restrex: inotify's known broken on some systems which is why it's switched off by default
<oly> also are there any kernel modules that are needed for the nforce network card ?
<Kamion> oly: dhcp3 broke this morning
<oly> yeah, i know it was fixed at 12
<zyga> Kamion: where can I read about the format of changelog.Debian files/
<Kamion> oly: look at /etc/dhcp3/dhclient.conf, there's probably a missing comma before "interface-mtu"
<oly> i installed the fixed ones
<Kamion> zyga: the Debian Policy Manual
<restrex> Kamion cool, tnx btw
<oly> okay, Kamion will look at that file
<Seveas> Kamion, he installed the fixed dhcp-client packages, but mii-diag gives errors when probing
<Kamion> no idea then, the kernel hasn't changed that recently
<oly> also my last update before that was yesterday
<oly> so its something recent, 
<Kamion> last kernel changes were on Thursday and don't look like they should have affected anything to do with network cards
<Kamion> you sure there isn't just a screwed dhclient process lying around somewhere?
<Seveas> no, we've killall-ed them
<Kamion> I hate to ask, but have you rebooted since?
<Seveas> and it already goes wring with mii-diag
<oly> i have rebooted a few time 
<Seveas> ao it's not dhclient related
<oly> it all started with a reboot though 
<Kamion> and had you rebooted since the last kernel upgrade?
<oly> i upgraded this morning and rebooted,
<oly> i have also rebooted since applyig the patch
<Kamion> I mean before today
<oly> oh, possibly not
<oly> i leave the computer on for long periods at a time
<Kamion> could be way back, then; please file a bug on the 'linux' component
<mantiena> Kamion: you told me "you're clearly not finding partitions, but looking inside them", I don't understand what I should look inside them :( I think I just should find all partitions, which are mountable (contains filesystem, which can be mounted with linux) and not belongs to being installed system (are not mounted as /, /home, /tmp, /var, etc) and this is all
<Kamion> mantiena: so you're probing the filesystem
<Kamion> and thus avoiding mounting random stuff like Apple driver partitions
<oly> okay, does that mean file the bug for i2c-nforce2 ?
<Kamion> oly: whatever's broken :)
<oly> i take it thats the component in question ? 
<Kamion> oly: please include 'lspci' and 'lspci -n'
<oly> no idea, the network card is broke lol 
<Kamion> oly: as I said, "on the 'linux' component"
<oly> i can sort the lspci stuff no prob, not sure what component it is though
<Kamion> what do you mean by "component"?
<oly> oly: as I said, "on the 'linux' component"  
<Kamion> in bugzilla
<oly> oh right not used bugzilla yet 
<Kamion> it asks you for an Ubuntu component to file the bug against
<oly> just looking now
<mantiena> Kamion: there are no way to discover filesystem without probing (for example by looking in /proc/some_file ) ?
<Kamion> mantiena: no
<Kamion> mantiena: the standard way in the installer is to use parted or libparted
* Kamion goes to do something a bit more weekendy
<mantiena> Kamion: thanks for info, AFAIK (lib)parted probes for partitions (sometime not correctly ;) ), so component name will be partition-prober (at least for now ) ;)
<oly> um, any idea what the package would be ?
<mantiena> oly: ?
<oly> just got to the ubuntu bugzilla page 
<oly> its asking for a package as required
<oly> no idea what package broke my network card :p
<Kamion> oly: oh, it's called package now, I thought it used to be component. the package is 'linux'
<Kamion> i.e. the kernel
<oly> oh right 
<mantiena> Kamion: btw, it seems http://www.ubuntulinux.org/wiki/InstallerTeam is outdated (for example some Goals for Hoary are different from reality), can I update this page to match current situation ?
<oly> okay, where do i put my lspci logs ? 
<oly> paste them in the description ?
<Lathiat> yeh
<oly> okay
<Kamion> mantiena: I'd rather do that myself; will go and bump some of them to breezy now
<mantiena> ;)
<Kamion> and only the graphical installer got deferred (well, and floppy installs, but that turned out not to be possible)
<Kamion> mantiena: done
<mantiena> Kamion: thanks
<oly> okay, got it submitted now finally :p
<oly> thxs for the help / info :)
<zyga> when is breezy going to appear in archive.ubuntulinux.org?
<Kamion> zyga: in the case of hoary, we only brought it up after warty released
<Kamion> zyga: dunno if we'll be doing the same again this time
<Kamion> it certainly won't be worth paying any attention to until after hoary releases
<Kamion> oly: so after I said 'linux' three times, you filed it against kernel-package instead? ;)
* Kamion reassigns to somewhere the kernel team will actually see
<davyd> Moin!
<Mitario> hi davyd ;-)
<davyd> so, who wants to put some icing on the cake with regards to iPod handling in GNOME ?
<tseng> davyd: hm?
<davyd> tseng: well, just now, I docked my iPod, and it appeared on my desktop, which is COOL++
<tseng> yep.
<davyd> it appears as a firewire disk
<davyd> which is fair enough
<davyd> the context menu offers me "Unmount" to remove the disk
<tseng> yes..
<davyd> however, with iPods, if you send them SCSI-Eject (ie, use the eject command)
<davyd> they display the "Ok to Disconnect" screen
<zyga> davyd: BTW what can I do so that usb sticks appear on my destkop?
<davyd> zyga: display volumes on the desktop, perhaps?
<zyga> davyd: a folder gets opened - true but if I close it then It's a venture down /media (far too many clicks)
<tseng> zyga: uh, are you using inotify?
<tseng> zyga: or too-old gamin
<davyd> tseng: basically, it would be really rad if it was detected as an iPod, used the iPod icon, and instead of Unmount perhaps said "Disconnect"
<zyga> tseng: checking...
<tseng> davyd: meh.
<zyga> tseng: gamin
<davyd> where Disconnect would send the eject sequence (I assume via the same mechanism as ejecting CD-ROMs)
<tseng> that touches alot of areas, not sure which one its actually in
<davyd> tseng: probably gnome-vfs mostly
<tseng> iirc pitti had some kind of "fix" for this at one point
<davyd> I haven't hacked in that area for ages though
<lamont> zyga: ack
<tseng> to call eject
<tseng> zyga: i meant, what version
<davyd> tseng: it would be the rad icing on the cake, and I thought someone here might just know how to do it
<davyd> to save me rooting around in there for days
<zyga> lamont: fixed already, hup :-)
<lamont> cool
<tseng> > Concerning https://bugzilla.ubuntulinux.org/show_bug.cgi?id=2134, I
<tseng> > put up a (still) unofficial new gnome-vfs2 package which should
<tseng> > (finally) handle the unmounting of iPods correctly. It also plays
<tseng> > better with USB sticks, they are actually powered off now.
<zyga> tseng: 0.0.26-0ubuntu1
* davyd fears Ubuntu bugzilla and its certificate that's not
<davyd> (the man owned Thwarte for cryin' out loud)
<zyga> davyd: you mentioned 'display volumes on the desktop', where is that?
<davyd> zyga: I think it's only exposed through gconf-editor
<davyd> zyga: it's actually something I added ;)
<zyga> davyd: argh... GUI, kingdom for a GUI ;] 
<Kamion> davyd: and I think his standard reply to that observation is "I've dealt with far too many certificates in my time", or similar :)
<Kamion> after all, if there's anyone you'd expect to know that SSL certificates are snake oil ... ;)
<zyga> davyd: you could patch gnome-volume-properties
<davyd> Kamion: it's one of my constant sources of amusement
<davyd> Kamion: however, I am easily amused ;)
<davyd> zyga: to do?
<zyga> davyd: include a checkbox  'show mounted stuff on my desktop'
<davyd> zyga: interesting idea
<davyd> zyga: of course, it assumes the person is running nautilus
<tseng> uh, thats not exactly part of the same use case
<tseng> or at least it crosses components in a bad way
<zyga> davyd: hmmm true but It's better to support the majority than to support no-one and be 'correct' about it ;] 
<davyd> tseng: yeah
<davyd> zyga: it was never exposed, because at the time everyone had volumes turned on
<zyga> davyd: if someone uses something different he might just patch it again
<davyd> I wanted to turn them off because I had almost no screen space
<davyd> I have them on on my big monitor'ed machine now
<zyga> davyd: I saw fedora a moment ago and it works the way you described it, but on hoary it doesn't 
<zyga> davyd: gconf key must be turned off then... checking :)
<davyd> zyga: I think it is on Hoary
<davyd> tseng: so no chance of seeing a fix for this then?
<davyd> tseng: I see from the bug that there were issues
<tseng> yes.
<davyd> but it's not clear if they were resolved
<tseng> there is a "link" to another bug
<zyga> davyd: which key is that?
<davyd> tseng: I don't see it...
<tseng> 1891
<davyd> zyga: /apps/nautilus/desktop/volumes_visible or something?
<zyga> davyd: hmm it was checked
<zyga> davyd: but plugging in usb stick did not show anything
<davyd> tseng: hmm, ok
<davyd> tseng: it looks much deeper then I originally suspected
* davyd figures it'll be fixed when it's fixed
<zyga> davyd: just checked that again, doesn't work
<zyga> davyd: should an icon appear in "my computer" too?
<tseng> zyga: yes
<tseng> zyga: do you have a /dev/inotify?
<zyga> tseng: no
<zyga> tseng: what should I install?
<tseng> you should not have that
<zyga> tseng: so, now what?
<tseng> so, i dont know why you arent seeing your /media stuff updating on desktop/computer
* zyga reinstalls nautilus
* davyd positively replicates the iPod eject problem
* zyga needs an ipod ;] 
<torkel> is gnome-volume-manager running?
* zyga still has the same problem, folder (open folder) appears but no icon on desktop
<zyga> tseng: yes
<davyd> hmm, this creates an interesting issue with the charging of said iPod now I can reproduce this
<zyga> zyga      8533  0.0  1.3  16772  6820 ?        Ss   11:31   0:01 gnome-volume-manager --sm-client-id default5
<davyd> before it worked, I just docked it and it never mounted
<davyd> now that it works, docking it mounts it
<davyd> and ejecting breaks it
<davyd> hmm
* davyd considers patching gnome-volume-manager to ask him if he wants to mount his iPod or if he was just chargin'
<oly> oops, sorry kamion kernel did not pop up in the list of packages
<oly> i tried a few variations that seemed like the closest one :p
<oly> cani change it to something else ?
<Kamion> oly: that's why I said 'linux' clearly; we call it by its upstream name rather than 'kernel'. I've already reassigned it.
<oly> okay, thxs i was a bit confused that linux was not in the list :p 
<HiddenWolf> Is the latest daily safe?
<Kamion> oly: it is in the list
<Kamion> HiddenWolf: the one I just built this afternoon should be
<herve> hi
<herve> elmo, ping
<HiddenWolf> Kamion: I can't seem to find a decent awnser: are there any major pros/cons to running x86-64 on the desktop atm?
<Mithrandir> HiddenWolf: they're a bit faster, depending on the application.
<oly> i'm just blind then lol
<HiddenWolf> Mithrandir: is it possible to have java/flash in firefox, do all the things you'd expect on a desktop?
<zyga> HiddenWolf: flash - not easily (you'd need 32bit firefox) - macromedia didn't make 64bit flash plugin
<Mithrandir> HiddenWolf: flash, no, java, yes.
<HiddenWolf> Sorry for going off-topic, but how easy/hard is it to run a 32b app once the system is 64?
<mdz> HiddenWolf: please take this conversation to #ubuntu; you know it's off-topic here
<zul> hey
<sivang> hey all
<Kamion> hi
<Kamion> sivang: did you see my call for translations?
<sivang> Kamion: nope, sorry, was detached mot of the week, what do you need?
<Kamion> sivang: installer translations - apparently Rosetta isn't quite ready for them yet so I'm doing them by steam - http://lists.ubuntu.com/archives/ubuntu-devel/2005-March/006121.html
<sivang> Kamion: eh I see, ok, that's fine I'll read over. What about {live|install}cd localization howto? Have you managed to get to them?
<Kamion> there's already a live remastering howto; install, no :-(
<Kamion> I think at this rate it might be a post-release thing, unless there's a lull after release candidate (which I doubt)
<sivang> Kamion: yes I know, But I don't think it contains insts. for localization or does it?
<Kamion> oh I see; well, pretty much likewise
<Kamion> there's stuff in the installation manual though
<sivang> Kamion: true, I need to get to it and stop bothering you :)
<Kamion> documents preseed/locale= and such
<sivang> Kamion: btw, just some maybe an installer usability qustions, is there a way to make d-i offer partitionning scheme on the free space left on a drive? (leaving the other fs intact)
<Kamion> sivang: yes, that was removed in warty but I thought I'd restored that in partman-auto 38ubuntu1
<Kamion> I can check
<sivang> Kamion: that'd be nice, this was a ctually a major down side while offering people the warty install cds, most of them were left some free space on the drive but the regular st,d partitionin scheme had been all or nothing and people didn't want to tinker more with it, so they just gave up the installation altogether.
<Kamion> warty certainly didn't have that
<Kamion> the partitioning changes for warty were kind of hurried
<Kamion> sivang: just tested, works fine for me
<Kamion> although it should really reuse existing swap partitions rather than creating a new one, but shrug
<sivang> Kamion: ok, great :)
<zyga> Kamion: I can help with polish translations for base and installer 
<zyga> Kamion: and shadow if that's something important
<Kamion> zyga: Polish is sorted now thanks to opi, I think; but thanks
<zyga> Kamion: right
<lamont> hrm.. serving size on girl scout cookies (samoas) is 2 cookies.  Who eats just 2?
<schweeb> lamont: are they made out of real girl scouts? </adams family>
<lamont> schweeb: no.  nor real samoans
* lamont notes that "vegitarian" meals aren't made with real vegitarians either...
<lamont> beef sausage pizza, OTOH, is made with real vegitarians
* davyd laughs
<schweeb> *cough* vegetarians 
<lamont> cows are too vegitarians
<schweeb> herbivorous :)
<lamont> yeah. same thing
* ogra looks if infinity is around....
<zyga> lamont: whaaat?
<lamont> zyga: huh?
<zyga> lamont: beef sausage pizza....
<ogra> zyga, whats wrong with that ? lamont is right...
<zyga> ogra: it may be perfectly fine - I just don't get it ;] 
<ogra> zyga, most vegetarian food isnt made of vegitarians, but most non vegetarian food (meat) is...
* zyga nods in silence
<zyga> ;-)
<ogra> zyga, its a joke (a _very_ good on, i laughed a lot, kudos lamont)
<ogra> s/on/one
* zyga thinks about hacking python code 
<zyga> python is nice but I'm worried about putting too much stuff dependant on py code
<zyga> especially system stuff
<ogra> zyga, wait until we rewrote the kernel in py ;)
<zyga> ogra: you did hear about perl live cd where everything except the kernel was written in perl?
<herve> ogra, I think a project is doing so
<ogra> oh, no i didnt
<zyga> ogra: but the real issue is that - when python breaks lot's of independent programs break
<ogra> herve, yeah, there are weird people around ;)
<zyga> some time ago I was doing an upgrade from warty to hoary
<herve> hmm... as does the libc or any runtime
<zyga> and (my fault) I broke python
<zyga> I was really dissapointed when I noticed how much stuff stopped working
<zyga> do you think it would be sane to keep /usr/sys-local/python around?
<zyga> and tweak various system tools to try either one ?
<zyga> think of it as 'static' binaries kept just in case
<_d4vid> hi all
<trulux|working> anyone has a sparc machine to give me access to? I need to work on libssp portability
<zyga> trulux|working: I've got access to a sparc box but it doesn't have linux on it
<LeeJunFan> what would be dd'ing /proc/kmsg to /var/run/kmsg when I insert a DVD that's causing my CPU to max for long periods of time because it can't read the blank DVD?
<zyga> trulux|working: It's at my university (available after passing thru a bunch of other boxes)
<trulux|working> zyga: what OS is running on it?
<doko> trulux|working: ask fabbione
<trulux|working> doko: oh, ok, thanks
<trulux|working> doko: the gcc-*-hardened packages will be wrappers or profiles, I'm designing the stuff to make you feeling proud
<trulux|working> doko: instead of overheading maintenance for us
<trulux|working> with gcc-3.4-ssp and the other goodies
<trulux|working> doko: just doing a digram of it
<trulux|working> diagram
<zyga> trulux|working: I'll check - some ancient solaris
<doko> trulux|working: sounds fine, and what about the upstream integration work? ;-)
<trulux|working> doko: ported most of the SSP to 4.0
<trulux|working> doko: http://pearls.tuxedo-es.org/patches/gcc-4.0/
<trulux|working> ;)
<zyga> trulux|working: on it now ;] 
<trulux|working> zyga: solaris... hah :)
<zyga> hmm
<zyga> w8 something is wrong ... not yet on 
<trulux|working> zyga: Welcome to SunOS 6.1.3 - If you are still not 0wned, then it's not SunOS
<zyga> trulux|working: damn the box is down - still checking thoug
<zyga> I've got a bunch of alphas if you'd like ;] 
<zyga> damn something must have struck the computer room
<zyga> out of a dozen boxes only few are up
<zyga> hehe
<zyga> but sr2201 (16 cpu risc) *is* up
* zyga wonders if recent gcc have high performace vector stuff like that native compiler has 
<zyga> trulux|working: I'll keep bashing sun for a while - I'll let you know if it's up
<zyga> trulux|working: if you'd like I can get you some old sparc boxes for a few bucks
<zyga> trulux|working: or you can buy one yourself ;] 
<zyga> trulux|working: I'll bet there are plenty in some warehouses / ebay
<trulux|working> zyga: in Spain, sparc's are not that common, even in hospitals
<ogra> infinity, ping
<zyga> trulux|working: cheepest one I've found was for something like 160 PLN (4.12 PLN = 1 Euro)
<zyga> trulux|working: no hdd, 128MB, net, graphics card
<zyga> trulux|working: 300Mhz sparc 
<zyga> trulux|working: besides crappy ram It's pretty good IMHO ;] 
<zyga> (for testing and such of course)
<trulux|working> zyga: the shipping costs many
<zyga> trulux|working: for 190 you'll get 4GB scsi hdd
<zyga> trulux|working: hmm well spain is far away from poland ;-] 
<trulux|working> ;)
<zyga> trulux|working: but you should check any local ebay of yours 
<trulux|working> btw, I might take a look on php5 packages, just for fun
<zyga> trulux|working: in poland it's called 'allegro'
<trulux|working> I will
<zyga> http://www.allegro.pl/show_item.php?item=46255389
<zyga> if you need that crappy sun anyway ;] 
<mdke> ping jdub
<ogra> mdke, i guess .au is asleep
<zyga> ogra: different time zones are annoying aren't they ;] 
<ogra> zyga, you get used to the delay in conversations ;) backlog is a wonderful thing :)
<zyga> ogra: backlog?
<mdke> ogra, ok
<mdke> hi
* mdke looks at jdubs idle time
<mdke> perhaps he is travelling or something
<zyga> trulux|working: with home delivery I can get sun box for 50 euro
<ogra> zyga, yeah, you can adjust your irc clinet to log a certain amount of lines to have a long scrollback, then you can get the info what was said during the last few hours...
<zyga> ogra: ah... now I get it
<zyga> hmm
<zyga> things you can learn each day
<zyga> from man df on hp-ux
<zyga>      -k   Causes the numbers to be reported in kilobytes.  By
<zyga>           default, all reported numbers are in 1024-byte blocks.
<zyga> That's sure different ;] 
<zyga> hehe
<froud-away> Mitario: new updates done for update-manager. More coming in the morning.
<zyga> froud-away: what updates are those?
<opi> Kamion, just a note: sorry, the last part will be in your mailbox in a morning
<opi> Kamion, I was to busy, playing soccer to do it on time :-)
<zyga> mvo: ping?
<opi> Kamion, OK, I'm going to bed now 
<dholbach> zyga: he's not here
<opi> zyga, hi and bye :)
<zyga> opi: hi and good night :)
<trulux|working> done: http://pearls.tuxedo-es.org/misc/ubuntu-hardened-schema.png
<zyga> trulux|working: mama mia, that's a spicy graph ;] 
<trulux|working> zyga: ;)
<trulux|working> zyga: added legend, reload
<zyga> trulux|working: just a note: the colors you've chose are a poor combination for laptop displays 
<zyga> trulux|working: if I look hard enough they differ - but at a glance they look the same
<zyga> trulux|working: that's a really nice graph for people that know what it means :)
<trulux|working> zyga: :(, I didn't do it on my laptop
<trulux|working> I'm now on the dumb fast box
<trulux|working> ;)
<trulux|working> I need to have *many* things working at same time ;)
<zyga> trulux|working: post svg, people will manage ;] 
<trulux|working> the svg? sure
<zyga> trulux|working: as do I, ssh is great here ;] 
<trulux|working> zyga: http://pearls.tuxedo-es.org/misc/ubuntu-hardened-schema.svg
<zyga> got it
<zyga> those big blue texts are needed or is it just inkscape playing dumb?
<trulux|working> hey, what gcc will be used in breezy? gcc-3.4, or gcc-4.0?
<zyga> trulux|working: AFAIK 4.0 but I may be wrong
<trulux|working> it's just that I have around more than the half done for porting SSP/ProPolice to 4.0
<trulux|working> and I want to know how much time I have to finnish it
<zyga> trulux|working: for breezy? a lot ;] 
<zyga> trulux|working: why are you afraid you can run out of time?
<trulux|working> zyga: my holidays finnish in 2 days
<trulux|working> zyga: It means, no more trulux on steroids
<trulux|working> zyga: no more trulux "the larry work mule"
<trulux|working> etc
<zyga> trulux|working: breezy won't be released for a while since hoary isn't released yet ...
<zyga> trulux|working: or are you targetting hoary?
<adobbie> holidays in March?
<zyga> adobbie: yup
<zyga> adobbie: wielkanoc 
<trulux|working> zyga: breezy
<trulux|working> zyga: but my work is also available for hoary
<zyga> trulux|working: then you've got nothing to worry about IMHO - but ask someone with more ubuntu background
#ubuntu-devel 2005-04-07
<trulux|working> hehe
* trulux|working working on targeted policy
* zyga spending my time in the idle loop
<zyga> :] 
<trulux|working> zyga: that's good for watching porn :P
<zyga> trulux|working: idle loop sounds better in log files ;] 
<zyga> trulux|working: actually I'm learning python 
<zyga> trulux|working: I'm a hard C fan and python is what I do on holidays 
<adobbie> C can be a pain in the ass sometimes
<zyga> adobbie: and all the 'nice' features can be an equal pain if sometimes you need to circumvent them 
<ogra> hmm, wondering what Kamion will say if thes gets sucked in by the big apt-get.org inclusion http://kitenet.net/~joey/debian/unstable/
<ogra> s/thes/this
<ogra> lots of installer stuff...
<herve> it's Joey Hess' personal repository
<ogra> yop
<ogra> on apt-get.org
<herve> I know :-)
<adobbie> zyga: if some language is restricting me then I might use C code for the trouble spot
<adobbie> otherwise I get things done faster with higher level stuff
<adobbie> ironically I've been doing assembly only for the past 3 months :)
<zyga> adobbie: I fully agree ;] 
<zyga> adobbie: then it's the moment you realize that anything but C seems tho be restricting you ;] 
<trulux|working> zyga: just kidding on porn, anyways, I don't care if it gets logged, we all know I'm a suspect of doing perverse actions
* trulux|working grins like a pyscho
<trulux|working> psycho
<adobbie> I find doing sockets in C more painful than Java
<trulux|working> :)
<trulux|working> adobbie: really?
<herve> no kidding :-)
<zyga> adobbie: java is way too verbose and now that I had to learn java bytecode way more ugly ;] 
<zyga> adobbie: (not that I mentioned sockets)
<zyga> adobbie: I C anything is equally pain in the ass as long as you are reinventing the wheel - try to write regular expression pattern matcher i perl from scratch ;-)
<adobbie> if you are making something complicated it's often faster to work at more abstract level
<zyga> adobbie: true, but that doesn't have to be another language
<adobbie> but I hate UML and CASE :)
<zyga> adobbie: and besides if you are doing some real world non-oss work most stuff (with java as a notable exception) can be ignored cause 'we have to keep the source code to ourselvs' approach is still there :P
<zyga> and that sucks alot
<adobbie> if you tow RMS' line on working on software you'll never work on such stuff :)
<adobbie> better to be unemployed than write non-free software
<zyga> adobbie: fortunatly I've just downloaded MS FreeWill ver 1.0
<zyga> hehe
<zyga> Once you agree to an EULA you can do WhateverYouWhish (tm)
<adobbie> hahah
<adobbie> I've got loads of non-free "evil" software on my system that I like
<adobbie> Adobe Acrobat 7, Matlab, and Java, to name a few
* dholbach can't stop asking himself how much of this is #u-d related...
<zyga> I've got ati's crappy drivers and valid-in-eu mp3 support
<adobbie> not to mention codecs...
<zyga> oh and win32-codecs and libcss ;] 
<ogra> yeah, looks _very_ offtopic here
<adobbie> codecs which you need for a desktop which are difficult to distribute
<zyga> adobbie: codecs really suck... 
<adobbie> which comes back to Ubuntu, is it easy to add non-free codecs to Ubuntu?
<adobbie> for newbie users I mean
<dholbach> there's a wiki page
<zyga> adobbie: what will we do in 10 years if microsoft will be still 32bit?
<adobbie> zyga: Windows XP 64bit is in a semi-usable state now
<mdke> is anyone running an ubuntu system willing to do me a quick favour?
<ogra> and this belongs to #ubuntu, please keep it there
<dholbach> mdke: fire away
<mdke> hi daniel
<mdke> thanks
<ogra> mdke, go on
<mdke> i'll go to PM
<zyga> adobbie: oh that's different from 32bit version how ;-) ?
<ogra> zyga, is this development related anyhow ?
<zyga> ogra: right -> #ubuntu
<dholbach> zyga: thanks
<ogra> thanks
<ogra> (you culd also open #ubuntu-philosophical *g*)
<herve> #ubuntu-bar :-)
<ogra> yeah
<adobbie> ogra: how about #ubuntu-legal? ;)
<schweeb> #not-ubuntu-devel
<mdke> lol
<ogra> adobbie, open it :)
<zyga> @ubuntu-devel-coffebreak
<zyga> s/@/#/
<ogra> adobbie, and get some lawyers involved....we could really need them
<adobbie> ogra: I don't need another channel simply to have a place to disagree with people, I've too many of those already
<mdke> i like the idea of ubuntu-legal
<ogra> adobbie, but disagreement is the profession of lawyers, isnt it ?
<adobbie> mdke: debian-devel list makes me shake my head in disgust enough as it is
<herve> adobbie, s/devel/legal ?
<adobbie> errr
<adobbie> legal
<adobbie> herve: guess I'm done for today :)
<mdke> does ubuntu have a legal team?
<mdke> perhaps not
<trulux|working> hey tritium 
<trulux|working> ajmitch: there?
<tritium> hi trulux|working 
<trulux|working> Standards-Version: 3.5.2 <- isn't it a bit outdated?
<herve> quite yes
<adobbie> "Write error: Success opening remote file"
<ogra> yeah, success is always great
<adobbie> indeed
<adobbie> I thought it was rather simple to check if you have errno 0 before you did anything like perror()
<mdke> dholbach, ping
<dholbach> mdke: pong
<mdke> brilliant
<dholbach> mdke: are you testing reply times or what? ;-)
<mdke> you wouldn't let me know the version of libatm1 in hoary? i'm trying to get a user to download the right ones manually
<mdke> dholbach, yeah that too, keep by your computer at all times
<dholbach> mdke: Version: 2.4.1-16
<mdke> genius thanks
<dholbach> de rien
<mdke> dholbach, ping *looks at watch*
<mdke> also speedtouch?
<mdke> sorrrrrry
<dholbach> mdke: pong
<dholbach> mdke: whatsup?
<dholbach> mdke: 1.3.1-1
<mdke> wicked thanks
<mdke> sorry to disturb, that's the last time
<dholbach> mdke: http://higgs.djpig.de/ubuntu/www/hoary/net/speedtouch
<dholbach> ;-)
<mdke> omg
<mdke> youre a genius
<dholbach> mdke: hey, it's 1) not my page, 2) not the package i packaged 3) not the software i wrote :-)
<trulux|working> dholbach: I haven't got such message even doing the SELinux I've been doing the past two days, so, just take it and don't say it's not yours ;D
<mdke> lol
<mdke> genius to have given me that url
<trulux|working> herve: what standards version should I use?
<dholbach> trulux|working: hrm?
<dholbach> trulux|working: dpkg -l debian-policy
<herve> trulux|working, 3.6.1 is the standard
<herve> but make sure the package conforms to it :-D
<adobbie> 3.6.1.1 is what Debian sarge has
<dholbach> adobbie: the last .1 is just for spelling mistakes and isn't checked
<adobbie> I burned myself with boiling water again and it really hurts this time
<herve> you're supposed to pour it in a glass or a mug, not your skin :-)
<adobbie> this time it was a mispour
<adobbie> two weeks ago I put my finger right into it
<adobbie> broke my teapot
<adobbie> that's going to reduce my productivity
<dholbach> good night
<mdke> night :)
<mdke> thanks again
<dholbach> it was my pleasure :-)
<blueyed> Hi. Does anybody know the password of the Live CD "ubuntu" user? I had to reboot, because I've tried "Lock screen" without changing the password at first.
<blueyed> I think it should default to "ubuntu".
<ogra> blueyed, there is no password, it is a known bug we still have to solve...
<blueyed> ah ogra, the bug then is that it says "entering password" canceled when you try it with an empty one.
<ogra> (likely by removing the lock unctionallity)
<blueyed> I'm glad you know about it already. I'm fascinated by your work! Thank you.
<ogra> :) youre welcome
* mdke looks at ogra, then at watch
<mdke> 4 am...
<mdke> ;)
<ogra> yeah, time for bed :)
<mdke> heh
<mdke> i can't sleep when south park is on tv
* ogra has his last cigarette
<ogra> mdke, battlestar galactica here, but i wont survive it...
<mdke> lol
<mdke> only 3 am here i have that advantage
<tseng> ogra: mmm, battlestar
<ogra> tseng, yeah, a movie of my childhood
<tseng> ogra: new or old?
<ogra> old
<tseng> ah.
<tseng> if you didnt watch the new series, its very good
<ogra> i didtnt even know there is a new one
<tseng> yep. it was on skyone in england and now in the us on scifi channel
<ogra> ah, so germany will get it probably next year
<tseng> it was actually filmed in canada for scifi, not sure how it made it to the uk
<ogra> but anyways, i'm off to bed, GF is waiting...
<tseng> rock!
<tseng> have a good one.
<mdke> at 4 am?
<mdke> she's asleep...
<ogra> she went to bed 10mins ago
<mdke> whoa
<mdke> is she a linux developer too?
<ogra> nah, just a little crazy webdesigner
<ogra> night all :)
<Mitario> hi everyone
<fabbione> morning
<fabbione> mjg59: thanks for the patch but that will be for breezy
<fabbione> no more patch for hoary
<fabbione> ECHAN
<zenwhen> grabbed todays daily and updated
<zenwhen> everything looks good here
<zenwhen> wait, I lied
<zenwhen> I tried to add a panel item and all of my panel items on all panels were deleted
<Burgundavia> jdub: ping
<Burgundavia> jdub: never mind
<dholbach> gooood morning
<froud> African Greetings
<dholbach> greetings to south africa *wave*
* froud waves back
<froud> Mitario: ping
<kagou> hi
<jessica_> My girlfriends computer is plagued by an instable Ubuntu. It looks like I'm having kernel Oopses (hoary, 2.6.10-5-386). On mailinglist I heard i needed to give output of dmesg, but the system doesn't respond after crashing. Does anyone have a minute? What info should I give? I do have a kernel.log.0 which seems to be the one of crashtime...
<crimsun> jessica_: please ask in #ubuntu, thanks.  :)
<jessica_> well, this looks like a bug... but I'll try
<Lathiat> jessica_: #ubuntu is still the right place :)
<jessica_> ok, thanks
<Lathiat> jessica_: this is more for discussion between developers and stuff like that
<davyd> Lathiat: so why are you here? ;)
<jessica_> ok, no problem. I asked it there once, but it was not really seen because everybody was screaming there was no msn(tm) on Ubuntu
<davyd> or me?
* davyd wonders why he is here
<davyd> why are we here, are we unique, or are with an example of something that is common in the universe?
<Amaranth> yay, python-xdg ignores user created menus!
<crimsun> awesome.
<crimsun> completely ignores?  Is there a method of "refreshing?"
<Amaranth> not that i'm aware of
<Lathiat> davyd: to observe those that are far cooler than i :)
<Amaranth> it shows up fine in the gnome menu
<apokryphos> Just as a note: the Wiki FrontPage is down. Unless it's down for maintenance, someone has deleted it.
<kain> ic
<dexem> Hi! I'm having troubles with nautilus 2.10 (hoary). I have some nautilus scripts, but environment variables are not correctly set up by nautilus. NAUTILUS_SCRIPT_SELECTED_URIS is correctly set, but NAUTILUS_SCRIPT_SELECTED_FILE_PATHS is blank.... any idea about what could be happening? maybe a package compilation problem? I haven't found any reference...
<dholbach> see you later
<Chand> hi
<opi> Kamion, hope you got the .diff
<zul> hey
<sjmorgan> hi
<zyga> hey everyone
<tseng> hm why does libdbus-cil depend on libc6-dev
<blueyed> Is the bug with Synaptic known where an added custom repository does not appear until you start the packet manager dialog again?
<OpaH> I have a Toshiba Tecra 780DVD with an S3Virge Video Card - unfortunately, it only runs on 'vesa' UseFBDev
<Chand> hi
<Chand> did latest hoary kernel fixe ibook g4 resume issue ?
<OpaH> If I have no known way of telling the HW-Detect to stay off the S3Virge code, it goes into psychedelic mode, ans looses both the X as well as the Character-consoles
<zul> Chand: it should i think
<zul> Chand: i dont do ppc though
<Chand> this bug can be closed https://bugzilla.ubuntu.com/show_bug.cgi?id=7464
<OpaH> This wouldn't bother me much - IF I had sshd up and running at the time - so that I could go & fix xorg.conf
<Chand> and this https://bugzilla.ubuntu.com/show_bug.cgi?id=6977 is the same
<abelli> happy easter everybody
<abelli> hey ppl why does gnome-menus depends on kdelibs-data?
<zyga> abelli: as far as I can see they REPLACE them
<amu> amu@ppc:~ $ apt-cache rdepends gnome-menus
<amu> gnome-menus
<amu> Reverse Depends:
<amu>   ubuntu-desktop
<amu>   gnome-panel
<abelli> amu: right, i was dist-upgrading with aptitude and i noticed it was trying to install kdebase-data and kdelibs-data ... i don't know why i turned (ahhh right i was speaking with opi) to synaptic, then under "dependecies" it says that gnome-menus  depends on kdelibs-data
<amu> abelli: you mean kdelibs-data depends on gnome-menu? 
<amu> abelli: it's because of the "menu" kde uses the same package as gnome uses
<abelli> mmm so why is my system trying to install kdelibs-data and kdebase?
<abelli> no qt in here.
<zenwhen> <-- theres one qt in here
<zenwhen> ;)
<abelli> zenwhen: dehiho ... doh.
<zenwhen> bringing home a freshly downloaded daily install disk and updating every week is like a weekly birthday present
<amu> abelli: good question, what happens if you remove them ?
<abelli> they get removed rightly (or at least i think so), but then if i try to dist-upgrade .. here they come again.
<sid77> hi
<trulux> mdz: ping
<fabbione> elmo: ping?
<zul> hey fabbione 
<srbaker> anyone know what the status of eclipse packages for hoary is?
<Seveas> srbaker, check the wiki on java
<srbaker> cool
<srbaker> thanks
<Lathiat> bugzilla defiantely needs some way to attach more than one file at once
<Lathiat> so you dont spam people with 4 emails when attaching a few files and then another one for the realtive comment
<zul> Lathiat: put your things in a tarball or something
<Lathiat> point
<Lathiat> didnt think about that
<Lathiat> makes it harder to view as part of a bug tho
<Lathiat> for like screenshots and stuff
* Lathiat swears at gamin
<seb128> Lathiat: does that work fine if you killall gam_server nautilus ?
<Lathiat> yeh
<Lathiat> does actually
<seb128> that's a dup of some open bugs
<Lathiat> ah ok
<Lathiat> sorry for spamming your inbox :)
<seb128> https://bugzilla.ubuntu.com/show_bug.cgi?id=7078
<seb128> that's the bug for the gamin issues
<seb128> np for the spam :p
<seb128> I'm closing it as a dup if that's fine with you
<Lathiat> yeh sure
<Lathiat> seb128: any idea what the decision about re-enabling new inotiy was?
<seb128> not for hoary
<Lathiat> rightio
<Lathiat> i tried booting with inotify yesterday
<dholbach> hey
<Lathiat> lots of scary kernel backtraces :(
<seb128> works fine ?
<Lathiat> wanted to get beagle to work heh
<seb128> so not using it for hoary is a good idea :p
<Lathiat> yeh
<zul> you dont need inotify for beagule apparently
<seb128> hi dholbach 
<Lathiat> i also lost about 90GB of data shortly after
<Lathiat> i hope to god that wasnt inotifys fault :P
<dholbach> hey seb128! :-)
<seb128> works better with inotify probably though
<Lathiat> but just my firewire being dodgy and offlining my disk sfar too much
<Lathiat> yeh it does
<Lathiat> half the stuff doesnt work without it
<Lathiat> all its indexing atm are my RSS feeds and email
<Lathiat> no gaim logs etc
* Lathiat wonders as to the progress of moving dbus apps to the new apis, like hal etc
<Lathiat> bit of a sticker atm :\
<Lathiat> seb128: ping
<seb128> pong
<Lathiat> seb128: what did you think about disabling detachable toolbars by default?
<zul> bbl
<seb128> Lathiat: why ?
<Lathiat> well since theyre broken, unless its fixed ?
<seb128> good idea, just drop whatever is broken instead of fixing bugs
<Lathiat> heh
<ogra> wow, yeah, then our job gets really easy
<Lathiat> point taken :>
<Lathiat> i was just thinking more hoary release wise
<ogra> the system will be a bit spartan after a while though....
<seb128> we have one bug in month about that, I don't think that's an issue for a lot of users
<Lathiat> im digging around trying to figure out the problem atm, but i havent looked at any of this code before so its not going so well, heh
<seb128> that's a libbonoboui apparently, good luck :p
<Lathiat> haha yeh
<Lathiat> wow its 5am
<Lathiat> where did the night go
<zyga> Lathiat: here, it's 11pm
<Lathiat> hehe
<Lathiat> on sunday night or monday night?
<Lathiat> actually has to be sunday
<Lathiat> cus im GMT+8 so any further ahead is 4 hours so max time it could be anywhere is like midday monday, i think
<Lathiat> 8:30 probably
<zenwhen> Hey Devs
<zyga> Lathiat: sunday 
<zenwhen> How well do you think Ubuntu will respond to switching from an i865 based board to an i875P based board without a reinstall?
<zenwhen> The chipsets and related hardware are quite close to one another, but I think the i865 board I am using now is on the fritz. I apologize if I am taking advantage of the vast bae of knowledge in here when I should be posing this in #ubuntu.
<Lathiat> hmm theres some nasty looking comments in these files :P
<Mitario> hello everyone
#ubuntu-devel 2005-04-08
<Slant> Does anyone know where I can read about how to put together my own Ubuntu installer CD?
<Slant> I would like to have a couple other packages and a different kernel set in the installer.
<dholbach> Slant: there's something on the wiki about it
<Slant> I was looking, but I couldn't find anything.
<Slant> Do yo uhave any pointer links?
<dholbach> search "live cd"
<dholbach> http://www.ubuntulinux.org/wiki/LiveCDCustomizationHowTo
<Slant> Isn't the Live CD a bit different than the installer?
<dholbach> oh sorryyyyy
<dholbach> i misread
<dholbach> *blush*
<dholbach> about the installer cd i dunno... sorry
<amu> only a bit different, same system 
<amu> Slant: if you take the d-i sources you'll find under /doc some infos about it 
<Slant> Thanks.
<Slant> Where are the Ubuntu fork of d-i respository?
<amu> archive.ubuntu.com ?
<Slant> It's not in the package list... :-\
<Slant> Or, it is.
<Slant> But not in the apt-cache search.
<Slant> D'oh.
<amu> Slant: look with you browser ;)
<Slant> Already done. :-p
<tritium> amu, if you don't mind, could you please post your review of my krecipes package on http://www.ubuntulinux.org/wiki/MOTUNewPackages ?
<Slant> Well, I read custom-kernel.txt. It's pretty clear about how to replace the kernel in d-i. However, does that replace the installed kernel too?
<Slant> I don't think so. So I suppose I would need to manually install the source kernel-image via chroot too...
<Slant> :-\
<Slant> Ugh.
<amu> tritium: yep ogra told ask before
<amu> Slant: no those are different ( packages )  
<tritium> amu, thank you
<amu> the one for d-i is a udeb the installed a full kernel.deb 
<amu> tritium: sorry for the delay
<tritium> amu, no need to apologize.  I appreciate your review.  :)
<Slant> amu: Ok.
<Slant> So I need to replace the udeb, and then post-install I need to manually install my kernel package from the boot CD.
<Slant> So that upon reboot I'll have access to my modules.
<Slant> Fair enough. Time to get on it then.
<dholbach> good night everyone
<amu> Slant: manally ? just look for the menu-id where the kernel will be install and replace it with your packages, i'm not sure about md5's 
<amu> n8 dholbach 
<dholbach> bye amu
<mdke> night dholbach 
<Slant> amu: Essentially, I'm trying to get around bug #7759. Is there an easier way than recreating an install CD?
<Slant> Where is the smp patches for ubuntu kernels?
<Slant> are rather?
<mirak> is there a way to make gnome use asynchrone mode for mounting of the removable devices ?
<Slant> mirak: I think you need to be looking at pmount?
<mirak> I guess yes, but where ?
<mirak> Slant: in fact that's the opposite, I want it synchrone
<Slant> It is sync.
<Slant> man pmount:
<Slant>        The    device    will    be   mounted   with   the   following   flags:
<Slant>        sync,atime,nodev,exec,noauto,nosuid,user,rw
<mirak> yep I have seen that
<mirak> but since gnome calls pmount
<Slant> gnome-volume-manager, I believe.
<mirak> yes
<tseng> i believe if you make an fstab entry with async pmount will honor it
<tseng> try that and then cat /etc/mtab
<mirak> that's not pretty
<tseng> uh, sorry.
<mirak> in fact I want it to be alway sync
<mirak> because it's to unsafe for removable devices
<mirak> at least rw devices
<Slant> mirak: The point is I believe they already are being mounted sync.
<mirak> especially when they use crap32
<mirak> they are not
<mirak> my recoder is
<|QuaD-> tseng: hoary is going to be released soon, do you know if beagle is going to make it in?
<mirak> but my mp3 jukebox is not
<tseng> |QuaD-: no, i dont know anything for sure
<|QuaD-> tseng: ok
<tseng> if not it will be easy to install
<|QuaD-> tseng: easier than now?
<tseng> as easy as dpkg -i
<tseng> or even apt-get if i decide to be generous
<ogra> heh
<|QuaD-> tseng: haha, its not hard to do now, i jsut want official packages
<Slant> /usr/bin/pmount-hal %h -e
<Slant> That's what gnome-volume-manager runs.
<tseng> |QuaD-: ill make sure they are gpg signed so you get a warm fuzzie then
<Slant> thus you should be checking the HAL settings for the device.
<|QuaD-> tseng: lol
<ogra> anybody using dualhead in here ? 
<eruin> where's the repo with gnomebaker in it?
<ogra> eruin, it should be in the archive soon, i uploaded it yesterday, it waits for elmos approval
<eruin> :D
<eruin> great
<ogra> if you urgently need a burning app, take graveman, its already there
<tseng> there is a coaster deb on their site
<tseng> it works fine for me.
<tseng> graveman is meh
<ogra> tseng, :-P
<eruin> yeah, no, not urgent, just wondering how my favourite burning app was faring in ubuntu ;)
<Slant> ogra: I'm running dual head on NVIDIA.
<ogra> Slant, which arch ?
<Slant> ogra: i386.
<ogra> hmm..
<ogra> Slant, does your screensaver run on both displays or only on the first ?
<Slant> It's a single screen that has been xinerama'ed. But Ubuntu's version of xscreensaver doesn't support xinerama, so it only displays on the full first screen.
<Slant> So in my case, it displays stretched across both monitors.
<Slant> If I set them up as multiple screens, then it would appear only on the first monitor.
<kaza> hi
<ogra> and if you lock the screen, it shows the unlock dialog in the middle between both displays ?
<mjt> someone ban this idiot #ubuntu pls
<Slant> https://bugzilla.ubuntu.com/show_bug.cgi?id=7658
<ogra> Slant, yup, thats what i'm working on...
<mdz> ogra: hey
<mdz> ogra: what is the status of hwdb submissions to the server?
<ogra> hi mdz 
<ogra> mdz, still no elmo
<mdz> ogra: the deadline was 2005-03-09
<Slant> ogra: Yes, it shows it in the middle of both display.s
<ogra> i have no server yet...
<ogra> Slant, ok
<mdz> ogra: once the server is set up, everything else is ready?
<mdz> do you have it working with a local server?
<ogra> nearly...
<ogra> nope, but thats an aftrnoon....
<mdz> can you please do that while waiting for elmo?  the release candidate is in three days and there is no way that we will be able to test this properly
<ogra> i'll have it ready tomorrow evening 
<mdz> thank you
<ogra> your order ;)
<mdz> I don't want your work to go to waste because we don't get the data from our users
<ogra> mdz, i already have 110 submissions in my inbox....
<Slant> ?
<mdz> ogra: you know what I mean :-)
<ogra> mdz, yep :) dont worry
<mdz> "please email this file to oliver" is not a very solid submission mechanism :-)
<ogra> not at all
<mdz> I expect we should get hundreds of thousands of submissions from Hoary if we get this working well
<ogra> we will, the people seem to like it....at least thats what i get in the email caomments
<ogra> mdz, about the apt-get.org thing, do you think it would be possible to have an additional repo (universe, multiverse, apt-get.org) so we could exclude the stuff we cant do QA for ?
<ogra> there is a lot of stuff in apt-get.org where people wont be happy about, e.g. joey hess d-i stuff might be something i think Kamion should review...
<crimsun> I'm much less worried about DDs' personal repos than I am others'
<ogra> crimsun, sure, but even if its form DDs it may break stuff in universe....
<crimsun> ogra: true.  All that's going into multiverse, correct?
<ogra> crimsun, not sure about that....and there are things like indiana jones game ROMs there, we wouldnt even want in multivrse
<ogra> +e
<mdz> ogra: I have to talk to sabdfl about it
<ogra> mdz, ood, then i know its in good hands...
<ogra> good even...
<sabmoc> eesh.. ubuntu is having some security auth problems lately, I just went to the website and it said the certificate was not valid, then I checked something out from svn and that wasn't valid either.
<mdz> most of the certificates used for the websites are issued by the Canonical CA, not by any of the usual ones whose certificates are trusted by browsers.  It has always been this way.
<ogra> night all
<crimsun> night ogra 
<sabmoc> mdz, I dont understand how that makes it alright to have invalid certs
<crimsun> sabmoc: they're not invalid
<crimsun> sabmoc: that's your web browser :-)
<sabmoc> crimsun, Im not invalid, I have feelings you know..
<sabmoc> crimsun, ok
<sabmoc> crimsun, but I dont think the problem is my browser, I think the problem is that the cert was issued for is different than the site I am viewing.
<sabmoc> at least that is what the message seemed to say
<Keybuk> hmmm, udev upgrade just failed for me ...
<Keybuk> (warty -> hoary)
<mdz> Keybuk: more specifically?
<Keybuk> dunno, it scrolled off the top and I don't know how to make screen give me scrollback?
<Keybuk> hoping it'll do it again
<Keybuk> Preparing to replace udev 0.026-1ubuntu5 (using .../udev_0.050-3ubuntu6_i386.deb) ...
<Keybuk> udev requires a kernel >= 2.6.8, upgrade aborted.
<Keybuk> dpkg: error processing /var/cache/apt/archives/udev_0.050-3ubuntu6_i386.deb (--unpack):
<Keybuk>  subprocess pre-installation script returned error exit status 1
<Keybuk> linux-image isn't a depend of ubuntu-base in warty?  so wouldn't have been upgraded
<Keybuk> mdz: is that a udev bug?  or a release note do you think?
<mdz> Keybuk: warty has a 2.6.8.1 kernel
<mdz> and no, it isn't a dependency of ubuntu-base
<Keybuk> yeah, this was a pre-warty-release install, so the kernel never got automatically updated
<mdz> that was an upgrading-to-warty-final release note
<Keybuk> ok, I missed that one then
<mdz> we do have a bug open about it, but since we've never shipped anything < 2.6.8, it's not much of a priority
<Keybuk> *nods*
<Keybuk> interesting ... if you comment out the udev change, it just doesn't start in postinst
<Keybuk> and configures happily
<Keybuk> that preinst check is probably a bug in itself
<mdz> hmm
<mdz> I'm inclined to agree
<Keybuk> postinst does "if kernel < 2.6.8, don't start until reboot"
<mdz> can you add a note to #6932?
<Keybuk> Jenny NARGH! The Application "gnome-volume-manager" has quit unexpectedly.
<Keybuk> *giggle*
<Keybuk> so even the warty version does that <g>
<mdz> g-v
<mdz> g-v-m in warty doesn't like anything being upgraded out from under it
<mdz> the hoary version is better; not sure if it's perfect yet
<Keybuk> the hoary version doesn't seem to like it either :p
<Keybuk> it seems to affect everyone but pitti
<daniels> g-v-m is still segfaulty when hal/dbus disappear from under it
<mdz> lamont: around?
<mdz> daniels: what is left to be done before you upload xorg?
<daniels> mdz: add two new modelines and a two-line i810 fix; give it a last run around on the live cd
<daniels> i'm working my way through the keyboard bugs now, trying to get as many of those
<mdz> yeah, unfortunately that seems to be taking a long time to settle out
<daniels>   * Change default en_CA mapping to us (closes: Ubuntu#7448), default
<daniels>     sv_SE mapping to se (closes: Ubuntu#7779), default el* mapping to
<daniels>     us,el with an Alt+Shift toggle (closes: Ubuntu#7656), and br-abnt2--*
<daniels>     fallback to br/abnt2 (closes: Ubuntu#8264).
<daniels> this is what I'm running with unless I hear a definitive 'no' from someone who would know on any of those
<mdz> I wonder how many of the non-latin languages are going to share that can't-login problem
<mdz> smurfix: around?
<daniels> mdz: mmm
<mdz> there was at least one other report, I thought
<mdz> ah, #8202
<zenwhen> Is there any possiblity of getting cvs installed by default in Ubuntu?
<zenwhen> Is there a place i would make a request for that?
<wasabi_> Why?
<mdz> cvs is a development tool; we don't install a development environment as part of the default desktop or server
<crimsun> agreed.
<zenwhen> Well I have on multiple occasions had people with certain USB wireless devices using amtel chipsets ask me how to do net free setup of said cards.
<wasabi_> Sounds like a poor solution to that problem.
<daniels> zenwhen: surely the answer is to get the right driver into the kernel, not use cvs?
<daniels> mdz: ah, right
<mdz> zenwhen: what is the solution that you offer them which involves cvs?
<zenwhen> You need it to use the cvs snapshots
<zenwhen> Surely that is the answer, and surely it isnt happening. 
<mdz> if certain hardware is supported only by pre-release versions of the driver, I think "install cvs by default" is an awkward solution
<zenwhen> I agree.
<mdz> it might not be unreasonable to add cvs to the CD
<zenwhen> But this is the current situation.
<mdz> that would satisfy your use case more elegantly, I think
<zenwhen> And cvs is so small.
<zenwhen> :)
<wasabi_> then apt-get install it
<wasabi_> that's not exactly much harder than USING It
<zenwhen> net free was my limitation
<zenwhen> its no big deal
<zenwhen> it was just a request
<zenwhen> feel free to ignore it
<mdz> err
<mdz> cvs is already on the CD
<mdz> it has been for ages
<Keybuk> if we put CVS on, then we'd need to justify why we don't put (e.g.) bazaar and Subversion on
<mdz> so is bazaar
<fabbione> morning
<Keybuk> in Ship?
<mdz> zenwhen: your problem is already addressed in Hoary
<mdz> Keybuk: correct
<Keybuk> ahh, that's pretty reasonable then :)
<zenwhen> oh it is?
<mdz> zenwhen: cvs is on the CD, so no network access is required to install it
<fabbione> mdz: yo
<mdz> fabbione: morning
<mdz> fabbione: are you happy with the kernel for RC, or are you going to try to put mjg59's fix in?
<fabbione> mdz: regarding -32, there are 2 changes scheduled, the security updapte and the fix proposed by mjg59
<fabbione> mdz: i am happy with the kernel for RC
<fabbione> i will keep -32 for immediatly after
<fabbione> given that it is ok with you
<mdz> fine with me either way
<fabbione> ok, than we will stay with .31 for RC
<fabbione> and -32 after
<fabbione> mdz: can i make merge a cosmetic fix to debian/rules too? it is to make clean: really clean
<zenwhen> ok cool.
<mdz> fabbione: cosmetic = doesn't change behaviour?
<mdz> if so, that's certainly OK
<fabbione> mdz: it makes clean do its job properly, remove 2 lines, change 1
<fabbione> mdz: i forgot to remove the debian/abi/ dir on clean
<fabbione> it's nothing extremely important
<mdz> fine with me
<fabbione> ok
<mdz> we will be making many revisions of the kernel after release :-)
<schweeb> since you 2 are around, I have a question :)
<mdz> nice to have a good clean target
<fabbione> mdz: you can check the change in the experimental branch if you like :-)
<schweeb> I'm intending to fix the user-mode-linux package in universe
<mdz> fabbione: if you would like to mail me the diff, I will review it, but it sounds safe
<fabbione> mdz: ok but it is safe and tested deeply
<schweeb> since it fails to build from source... I know mdz was the maintainer, and fabbione manages kernels...
<mdz> that package is pretty much obsolete since UML was merged upstream and make-kpkg can build the packages
<schweeb> ah
<schweeb> okay
<schweeb> think I should morgue it?
<schweeb> or build off the kernel tree
<fabbione> -       rm -rf debian/patched $(DIFFDIR) $(MONODIR)
<fabbione> +       rm -rf debian/patched $(DIFFDIR) $(MONODIR) $(abidir)/$(release)-$(revision)/
<fabbione> -       mkdir -p $(abidir)/$(release)-$(revision)/${arch}
<fabbione> -       echo $(abinum) > $(abidir)/$(release)-$(revision)/abiname
<fabbione> -
<mdz> it needs a lot of work, to move to 2.6 etc.
<schweeb> yea
<fabbione> mdz: that's all
<schweeb> I wanna do that for breezy, not really prepared to put that amount of work into it before release
<fabbione> schweeb: hey.. xen kernels are almost ready btw :-)
<mdz> schweeb: if it builds, I see no reason to remove it, since we don't have a replacement yet
<schweeb> it doesn't build
<schweeb> no kernel-source-2.4.26
<schweeb> (which I mentioned in #u-k the other day)
<schweeb> no one was around though
<mdz> ah, ok
<mdz> yes, it should be removed
<mdz> it has known security vulnerabilities, etc.
<schweeb> alright, I'll put it on the proposed morgue list
<fabbione> Keybuk: how can i merge one single specific commit, from one branch to another in baz?
<mdz> mako: morning
<schweeb> this is the information I needed to know, cool :)
<mdz> fabbione: baz replay
<Keybuk> baz replay blah@blah/blah--blah--blah
<Keybuk> --patch-x
<fabbione> ok thanks
<fabbione> yup
<fabbione> neat
<fabbione> mdz: i also prepared a generic infrastructure to build xen and uml kernel images, of course it will wait for breezy, but at least we can be ready for UDU and see how to handle ti
<mdz> fabbione: yep
<fabbione> but the amount of images will bloat :/
<fabbione> badly
<mdz> we need fewer images
<fabbione> i agree.
<fabbione> but xen and uml are 2 arches on their own
<fabbione> with their own requirements
<fabbione> i dunno uml enough yet
<fabbione> but xen requires 2 images per flavour
<fabbione> xen0 and xenU
<schweeb> uml wants SKAS support
<fabbione> xen0 for the main host (the one you really boot)
<schweeb> but it isn't a strict requirement
<fabbione> and xenU for the internal hosts
<fabbione> so you get a bloat on that
<mdz> we need fewer flavours, I mean
<mdz> 2 images per flavour is not bad if there is only one flavour ;-)
<schweeb> fabbione: if I take some time off of work soon, I'll try to see if I can get the Xen userspace stuff running on python2.4... I'm guessing 2.3 support will be dropped on breezy?
<mdz> that's unclear
<mdz> the reason we have python2.3 is for zope
<mdz> if zope were updated to use 2.4, perhaps we could drop 2.3
<fabbione> schweeb: i am not sure about python, but it will be of course nice to get it working on 2.4
<schweeb> yea
<schweeb> I wish there was a central IRC channel for Xen... all the devel chat seems to happen on the ml's
<schweeb> there's one on oftc, but it's pretty low traffic
<mako> mdz: morning... :)
<schweeb> you've been pretty low profile lately, mako :)
<mako> schweeb: dude.. i've been swamped :)
<schweeb> understandable
<schweeb> your laptop incident made me chuckle ;)
<mako> me too.. sort of :)
<mako> i guess i have been pretty quiet.. i didn't even blog all last week
<mako> wow
<schweeb> whip said you've got some pretty interesting ideas about those houses in Detroit
* schweeb is a michigander too
<mako> schweeb: ah, you've heard my idea
<mako> can i add your name to the list?
<schweeb> I haven't heard the entire idea
<schweeb> explain :)
<schweeb> I just heard the term "open source neighborhood" tossed around
<schweeb> but if it's cool, I'm in :)
<mako> yeah dude
<mako> i'm trying to build critical mass
<fabbione> hey mako
<mako> so if anyone else here wants to move into FREE HOUSES in inner city detroit to create a rent-free free software commune, i'm the guy to talk to
<mako> fabbione: whats up dude :)
<schweeb> hehe commune
* schweeb chuckles
<schweeb> as long as it doesn't get me murdered, and I still work near Detroit, sure
<schweeb> get enough people and we could pool resources and get some hardcore bandwidth too :)
<fabbione> mako: not much really.. woke way too early this morning and my wife is already complaining that i am in front of a monitor :-)
<mako> isn't today a holiday in most of europe? :) 
<fabbione> mako: indeed
<mako> it's sure not here :(
<Slant> Ugh.
<Slant> Lame.
<mako> but i think i'm going to take half of tuesday off to go see the grokster v mgm supreme court case
<mako> if i can get everything i need to do done before
<Slant> I have to rebuild the kernel since d-i requires a flavor be specified.
<daniels> has jbailey been around lately?
<Mithrandir> six-ish hours ago, yes.
<daniels> cheers
* Mithrandir runs off to catch the train home
* daniels kicks off hopefully the last xorg 6.8.2-6 build, scurries off to get some food.
<infinity> daniels : Never announce anything as the last build, that's just inviting trouble.
<infinity> I find that the "last build" usually happens at the N+1 mark, where "N" is the number of builds after which I say "You know, I really should be using ccache".
<mako> alright.. i'm off for little bit this sleep thing
<mako> later all
<schweeb> night
<daniels> night mako
<daniels> infinity: monash?
<daniels> jbailey: hullo :)
<infinity> daniels : Hallway. :/
<infinity> daniels : The Monash library isn't open until Wednesday morning.
<daniels> infinity: agh
<daniels> infinity: hm, not open Tuesday?  bong
<infinity> Rather bong, yes.
<pitti> morning all
<infinity> Mornin', pitti.
<infinity> pitti : BTW, I just reviewed the PAM changelog more in-depth, and nothing else there seems like a security issue (well, some may argue that any bug in PAM is a "security issue", but I wouldn't go that far)
<infinity> pitti : I think we can close the Ubuntu bug and let hartmans deal with the wishlist bug in Debian on his own time.
<infinity> pitti : Sorry for being a day or two late.  I had no idea people here would take Easter so.. Seriously.
<kagou> hi
<pitti> infinity: thanks for you analysis
<pitti> infinity: well, at some point the family just claims its rights :-)
<pitti> Kamion: here?
<smurfix> mdz: still here?
<mdz> smurfix: yes
<smurfix> mdz: you rang?
<mdz> smurfix: wanted your input on these keymap bugs
<mdz> specifically the ones where people end up with a keymap that doesn't allow them to log in
<mdz> greek and russian suffered this problem so far
<mdz> in both cases the correct thing was apparently to use a "us,<foo>" layout
<mdz> at least for the users who reported the bugs
<smurfix> I've been CCd on the Greek one
<mdz> #8202 is the russian one
<mdz> I think
<smurfix> didn't say anything because the solution you arrived at looks sane and appears to be the one used by a Certain Other OS
<smurfix> let me look over that one
<daniels> it looks like we need to have a Latin keymap (or at least one that allows full Latin entr) as the default if we're only allowing Latin in the installer
<daniels> logging in being useful and all that
<smurfix> Yeah, no other good solution until we get a graphical installer, I think
<smurfix> and even then the user needs an ASCII username if they want to receive emails ...
<infinity> Non-ASCII usernames are just asking for trouble, imo.
<smurfix> infinity: Yeah, there are probably enough other problems with them. I never tried, not having any of those in my name.
<mdz> pitti: please don't add the gimp help to the language-support packs quite yet
<mdz> they're big
<daniels> ARGH ZWIKI
<pitti> mdz: you mean because of -en, which would land on the CD?
<pitti> mdz: 450 kB .deb
<trulux> pitti: heya
<pitti> Hi trulux 
<trulux> pitti: do you have a bit of time?
<pitti> what's up?
<trulux> pitti: I'm fine, you? I've sent you an email on the new libssp packages
<trulux> could it be in Universe?
<pitti> yeah, sorry, Easter holidays
<trulux> just also Sid package needs an upgrade
<trulux> NP
<trulux> I had them too :)
<pitti> if the MOTU crew is fine with it
<trulux> but I'm again ill :(
<trulux> pitti: I'll ask on -motu, is that OK?
<pitti> sure
<trulux> ok :)
<pitti> or just ask ogra or dholback
<pitti> dholbach, even
<trulux> ok, thanks
<ogra> morning
<daniels> mdz: ping
<daniels> mdz: casper-reconfigure -fpassthrough xserver-xorg fails; dpkg-reconfigure -phigh xserver-xorg, from a console, succeeds
<daniels> mdz: (the former leaves you with the old PCI ID; the latter gives you the proper PCI ID)
<daniels> mdz: i suspect db_reset semantics are possibly totally fucked?
<pitti> Hi ogra
<pitti> hi daniels 
<ogra> hey pitti
<ogra> did i whish you a happy easter already ?
<pitti> hmm, could be :-)
<ogra> heh
<pitti> however, happy easter! (just for the case) :-)
<ogra> yeah :)
<daniels> pitti: yo
<dholbach> hey!
<pitti> Hi dholbach 
<dholbach> hey pitti
<xuzo> hi, why powernowd is not stopped in laptop mode?
<pitti> why should it?
<xuzo> mmm, my laptop supports ffrom 600 to 1600 MHz, using powernowd puts cpu to max. speed opening a simple app
<pitti> Hi sabdfl 
<sabdfl> hiya
<dholbach> sabdfl: hi mark :-)
<trulux> pitti: too much work for the MOTU's, libssp1 can't be reviewed by now
<pitti> brb, testing a crasher...
<abelli> ciao ppl
<abelli> is there any planned for a "rootly nautilus" in gnome's menu?
<abelli> s/planned/plan
<abelli> ... happy easter to everyone ...
<Treenaks> abelli: I think it's not planned, becayse of the inherent potential for stupidity
<abelli> yeah but "gksudo nautilus" is not so far away
<sladen> abelli: the 'opposite' of spacial nautilus?
<Treenaks> nautilus should die when run as root, imho
<abelli> or maybe what about a control Something to administer all of this tasks with rootly powers needs.
<ogra> argh
<ogra> Treenaks, ++++++
<abelli> Treenaks: yeah but ppl keep on asking how to deal with etc file management.
<Treenaks> abelli: vimtutor<enter>
<Treenaks> abelli: or terminal + nano if they don't want to learn
<abelli> vimtutor? is it a virus?
<abelli> please rms forgive him .
<sladen> I suppose if you try to delete a file owned by somebody else, it could do with having a way of 'probing' the command, and then responding either with a dialogue ''this command requires superuser priviliges'', followed by either ''please enter your password to confirm'' or ''please contact a system administrator''
<abelli> sladen: perfect.
<abelli> sladen: exactly what i was thinking of .
<Treenaks> sladen: nautilus already knows: it shows little "lcok" icons
<Treenaks> lock, too
<sladen> abelli: could you search the net and see if anyone else has suggested similar, an.... ah
<abelli> what should i look for ? "nautilus ah na na"?
<sladen> Treenaks: I suppose it could be taught about the 'admin' group which is the default one for those with full sudo priviliges
<sladen> ideally it could do with understanding the full security model
<abelli> Treenaks: im not sure i can help you with your sickness ... will you come with me at LSM?
<Treenaks> abelli: LSM?
<sladen> abelli: can you write it up on the bugzilla as a 'wishlist' item?
<abelli> libre software something in Dijon (sorry i dont know how it's spelled")
<Treenaks> abelli: meeting probably :)
<abelli> sladen: yes, maybe why dont we think a little more about it?
<abelli> sladen: just to understand what we're talking about.
<abelli> or not?
<Treenaks> So Nautilus (or any gnome app..) should notice "I can't edit this file.", and then be able to sat "But I /could/ sudo to remedy that." or "Hm, I can't sudo, better call in a real sysadmin"
<ogra> using a filemanager as root is sooo wrong
<Treenaks> sat=say
<abelli> ogra: did you receive the sms?
<Treenaks> ogra: yes, but a filemanager starting an editor as root is less evil
<abelli> ogra: yeah. also smoking is ... but some ppl do it.
<ogra> abelli, oh, my battery is empty....wait...i'll charge it
<abelli> ogra: no probs.
<abelli> ogra: happy easter.
<ogra> abelli, same to you :)
<abelli> sladen ?
<abelli> ogra: what would you suggest?
<abelli> ogra: i mean i see your point . but there's always an approximated solution for quite everything.
<abelli> or at least when we are talking about GUI.
<sladen> want something like the OSX security services---nice central clearing house.
<Treenaks> sladen: there's the keyring stuff in gnoem
<Treenaks> gnome
<sladen> the ideal solution would be one-better than sudo.  Not to run the /editor/ as root, but to allow it read/write to file in the way that 'fakeroot' fakes such things
<sladen> Treenaks: nod.
<ogra> abelli, if someone doesnt know how to handle files on the commandline, he souldnt do it with a filemanager....the system should be designed to make this not necessary, that would be the right fix...
<Treenaks> ogra: that would mean writing a gnome config tool for EVERY file in /et
<Treenaks> c
<abelli> ogra: you've already got the cow, let's try to get as much milk as possible out of her.
<ogra> Treenaks, sudo gedit
* Treenaks needs something caffeineish
* trulux too
* trulux goes to kitchen
<ogra> Treenaks, open with....gksudo gedit should work too (untested)
<abelli> ogra yes, gksudo is better. 
<pitti> Kamion: ping
<abelli> because you're not wasting a terminal, but you still have something with rootly powers wandering around your CPU.
<ogra> abelli, but filemanagers as root are very very dangerous....imagine you accidentially move /usr/bin to tmp because of a flaky mouse and you dont recognize it.....
<abelli> you can hide it.
<ogra> hmm, so if i hide every sensitive dir, where is the point to have a filemanager as root then ?
<dholbach> it should be completely forbidden, if you need to change stuff in /etc, you should be 1) knowing what you do or 2) there should be a clickypointy interface for it
<ogra> s/sensitive/sensible
<ogra> dholbach, +++
<abelli> sladen idea is quite better .
<abelli> as i was saying before, we need to know what we are talking about (i mean ... problem) .
<sladen> the ideal delegation is not ''you may run this comand as root'', it is ''*you* may modify *this* file for a period of *5 minutes*
<abelli> there was an user that wanted to copy things under /opt
<sladen> anything that fails should hit the security service and be handled there (eg, with a password prompt)
<abelli> and why not using a pop up windows for moving files or directory?
<abelli> so you can't mistake as ogra was saying.
<dholbach> abelli: this may sound a bit geeky, but i think people struggling their way to grokking file permissions, unix tools, ... are less likely to fsck up their system
<sladen> this is also where the fine-grained LSM comes in, dpkg should have access to /var/lib/dpkg/* but not anything else
<sladen> this would also mean that you could edit a file, but not be prompted until you actually try and save it
<abelli> ogra: if we use a pop up windows, with say source files and destination, there will be less possibilities for a mistake? or not?
<Treenaks> yes
<ogra> abelli, that could be a way, yes
<ogra> abelli, but it still doesnt prevent you from making very bad errors that could render your system unusable
<abelli> yeah as OS automation is not the optimum, but it should do the trick until someone (like sladen) come up with a better idea
<ogra> abelli, for your example with /opt, the right fix in my eyes is to offer a rightclick item on tgz files to make them debian packages and a drag and drop function for synaptic to install this
<ogra> then you dont need to copy software around manually
<abelli> what about editing config files?
<ogra> open with... gksudo gedit
<abelli> this means that you, MOTUs, should review all the packages.
<ogra> abelli, what for ? if the user created the package himself....
<abelli> so you need to had an icon for "rootly gedit" ...
<abelli> mmm ... i wasnt talking about /opt anymore ...
<ogra> a right click option in the context menu
<abelli> arent we going to have a 3 screens long context menu?
<ogra> abelli, lets discuss thatafter release, there are only 3 days left until RC and we have a lot to do currently...
<abelli> maybe a sort of standardization in config files, for the future, could help.
<abelli> yep. sorry.
<ogra> abelli, there is one ;) its called /etc
<abelli> cmon you :))), i meant how files are parsed ... maybe using an ad-hoc xml-dialect (but its just an example)
<abelli> let's call it ... Esperanto .
<ogra> abelli, heh, convince debian to use that :-P
<abelli> ok im turning my self off
<ogra> i doubt you will get the several upstreams to use xml everywhere
<abelli> you're debian, revolution starts from the bottom.
<ogra> abelli, nope, im not a DD
<abelli> ogra: ok, just become one, and starts to spread the virus.
<abelli> :)
<ogra> (being a ubuntu only maintainer is smoething i'm very proud of....)
<abelli> and im with you in this ...
<abelli> even if im not, but i would .
<abelli> ok ill leave
<abelli> you to your work.
<ogra> MOTU can need every helping hand ;)
<sladen> dholbach: interesting email about apt-get stuff...
<dholbach> sladen: how do i have to interpret "interesting"? :-)
<ogra> sladen, please comment it with your thoughts
<abelli> ciao a tutti ppl, have a great day
<ogra> ciao abelli :)
<dholbach> abelli: you too
<SlackShrike> hi
<abelli> sorry im back but Treenaks is a kind of genius .
<Lathiat> Sorry, he's not for sale
<abelli> if  i pay someone of the motu, will a package like ubuntu-quotes be uploaded to universe? i mean after ubuntu-calendar, a database of quotes (taken from the ubuntu world) to sign our mail
<abelli> would be great.
<ogra> Lathiat, sure ?
<abelli> Lathiat: really? doh ...
<Lathiat> Sorry
* Lathiat ponders going into business
<dholbach> abelli: fortunes-ubuntu maybe?
<Lathiat> selling free software devleopers good be lucrative :)
<abelli> is it already there?
<ogra> abelli, we work for free ;)
<dholbach> no, not yet
<abelli> dholbach: dehiho ...
<abelli> because treenaks has called it the same way.
<dholbach> apt-cache show fortunes
<abelli> ahhh ok
<abelli> yeah ...
<abelli> ubuntu-pow
<dholbach> so it'd be another package of "fortune cookies" :-)
<abelli> pearls of wisdom
<abelli> with a special brand : ubuntu.
<trulux> pearls.tuxedo-es.org "the pearls of wisdom junk"
<dholbach> hey seb128 
<trulux> :)
<pitti> Hi seb128 
<abelli> seb128: ciao
<seb128> hi
<ogra> pitti, seen ubuntu-devel@ ?
<pitti> not very thoroughly today
<pitti> what in particular?
<ogra> apt-get.org
<pitti> yes, saw that
<seb128> this list is getting to much noise
<pitti> however, didn't reply yet
<seb128> s/to/too/
<pitti> ogra: dholbach is on crack, as I said :-)
<ogra> heh
<pitti> en-gross import of apt-get.org is utterly crazy
<dholbach> pitti: how about some mud wrestling at UDU? :-)
* pitti looks forward to that...
<dholbach> woohoo! :-)
<abelli> dholbach: mind that pitti's karate kid v2 ...
* dholbach doesnt mind
<dholbach> abelli: it's about fun, isnt it? :-)
<pitti> Tae Kwon Do...
<pitti> dholbach: I prefer Frozen Bubble :-)
<abelli> pitti: sorry .. but i didnt know a famous actor that uses twd
<dholbach> pitti: i just wanted to make sure everybody knew, it wasnt my idea in the first place  :-)
<pitti> dholbach: I know, just kidding
<dholbach> pitti: and if you encourage that rumour in any way, i'd have to frozen-bubble/mud-wrestle/xyz you :-)
<pitti> dholbach: okay, let's blame seb128 then :-)
<dholbach> oh no... not poor seb128... he took the panel blame already
<abelli> ok ciao a tutti - again and definitely ciao
<seb128> dholbach: which one ?
<dholbach> seb128: the "seb128 broke my panel" one?
<dholbach> :-)
<seb128> ah ah
<seb128> hum
* seb128 considers unsubscribing from u-d list
<seb128> that's turning to a bugzilla list
<dholbach> seb128: it's a PITA if you read u-u@, u-bugs@ and the wiki as well :-)
* daniels boots the new live CD, crosses his fingers.
<trulux> dholbach: crack is a drug, steroids are a feature enhancement
<trulux> :)
<dholbach> trulux: roses are red and violets are blue, ...
<dholbach> :-p
<trulux> dholbach: and this is a cup of tea!
* trulux hands a cup of tea to dholbach 
<trulux> and a cookie
<dholbach> yeah... thanks
<dholbach> i guess we now solved the most important matters
<daniels> HUZZAH!
<daniels> mdz: 6.8.2-6 is good with the live CD
<daniels> mdz: i mean, it doesn't work first off for me because of pci ids (https://bugs.freedesktop.org/show_bug.cgi?id=2827), but generates a correct config after having bullshit values seeded into xorg.conf and config.dat
<trulux> damn PCI ids...
<trulux> 1:3:3:7
<trulux> :)
<daniels> heh
<ogra> daniels, what about nvidia cards and broken widescreen panel detection, is this fixed already ?
<daniels> ogra: should be, yes
<ogra> yeah
<ogra> daniels, you ROCK ;)
<daniels> most of the widescreen stuff was just lacking adequate modelines
<daniels> i assume you mean https://bugzilla.ubuntu.com/show_bug.cgi?id=7181
<ogra> nearly...i'll pull down the liveCD today to test it here...(mine was always stuck at 1024x768 instead of 1280x800)
<ogra> which   waseasy to solve with a modeline....so sounds very much like that
<trulux> ogra: I was having problems with 1280x800 in my laptop
<ogra> trulux, stuck at 1024x786 ?
<ogra> 768...
<trulux> I needed many time to get the right modeline, among that the HP jerks didn't know the specs of their own product when I asked them on the monitor sync interval
<ogra> heh
<trulux> ogra: no, I'm on my desktop now, this box is dumb fast, great cooling
<ogra> i meant your laptop
<trulux> but this makes me thinking that I should turn on the laptop and emerge sync && emerge -u world
<ogra> heh
<trulux> on the laptop I have now 1280x800 but the glx totally sucks
<trulux> I see many lines around the screen when I try to get some glx working
<trulux> and accel does not work at all, no DRI
<daniels> ogra: yeah, I've added 1280x800 modelines
<ogra> yippie
<trulux> daniels: sounds good
<trulux> should I give a f*ck to my laptop Gentoo? :)
<daniels> and I'm really hoping that it fixes the last of the i8xx bugs as well
<daniels> we'll see
<ogra> trulux, the nvidia driver works just fine on mine, but since nvidia doesnt support suspend at all, i'm fine with nv
<trulux> ogra: my laptop has ati mobility radeon 9000 agp 4x
<ogra> trulux, ubuntu everywhere ;)
<ogra> go on :)
<trulux> ogra: right, except under my pants
<ogra> sure ?
<trulux> lemme check
<trulux> sure
<ogra> heh
<trulux> oops, set_one_prio may need a new LSM hook :)
* trulux again messing with kernel stuff
<Mitario> hey everyone
<ogra> guys please, please, please comment dholbachs apt-get.org mail, its important that we see as many opinions as possible
<dholbach> hey mvo
<mvo> hi dholbach 
<mvo> ping seb128 
<seb128> pong
<mvo> seb128: mind if I upload a new gnome-applets package? that fixes the sudo problems with modem-applet?
<seb128> not at all :)
<mvo> seb128: thanks :) I'll upload it later then
<seb128> np
<seb128> anybody using vim here ? what's the way to close a file and to go to the next one when you have several files open ?
<mvo> :n
<seb128> thanks
<Seveas> just like in less :)
<mvo> seb128: are you testing gvim :) ? 
<Seveas> seb128, opening them using :sp or :vs is a nice way too
<seb128> mvo: I'm trying to change 30 po in a row to remove #~ before a translation
<Seveas> seb128, sed?
<seb128> emacs open them in po mode which is fine to edit a po but it doesn't want to change them
<mvo> seb128: yes, that's anoying in emacs, I was bitten by it too
<seb128> Seveas: that's an option too, but editing by hand is probably quicker
<torkel> seb128: or :wn to save it and jump to next
* mvo sees lot's of vim user love in this channel
<ogra> yeah
<seb128> I hate vim
<seb128> hate hate hate
<seb128> these :vdsogvsdj are bong
* mvo chuckles
<dholbach> seb128: how about vim-users--vs--emacs-users--beach-volleyball @UDU? :-p
<seb128> you open a file and can't even enter something 
<seb128> that's totally bong
<mvo> football? 
<mvo> ^ --- dholbach 
<seb128> I don't care about emacs neither
<dholbach> beach volleyball! woohoo!
<seb128> but vim is bong
<ajmitch> would have to be rugby
<dholbach> yeah
<daniels> mvo: you mean, http://www.afl.com.au?
<daniels> boo to rugby
<Seveas> boo to emacs :)
<mvo> dholbach: your vim-user--vs-- looks like a tla/baz archive
<mvo> bong@UDU/vim-users--vs--emacs-users--beach-volleyball
<dholbach> mvo: sorry for that... didnt want to scare you
<dholbach> the beachvolleyball idea was only about fun ;-)
<torkel> dholbach: vi vs emacs is never about fun :-)
<Seveas> lol
<Seveas> vi vs emacs vs nano then
<seb128> dholbach: that's not a "vs", but vim ...
<seb128> bah, I've fixed the strings, whatever
<dholbach> seb128, torkel: i don't really care about editors either :-)
<seb128> jdub, mdz: can we get a "REOPEN" for bugzilla ?
<dholbach> ogra_: you missed the  vim-users--vs--emacs-users--beach-volleyball @UDU thing :-)
<ogra> YEAH
<seb128> I don't like to be forced to accept a bug because it was NEEDINFO and there is no other way to get it of the status
<ogra> dholbach, that sounds great !!
<zul> i think you will find that they emacs users will be a bit under stength
<Kamion> pitti: you should really include some content with your pings ;)
<Kamion> pitti: sorry I wasn't around earlier, I haven't been feeling well
<ogra> Kamion, http://www.ubuntulinux.org/wiki/AptGetOrg see the "Clashes with our packages" section....
<Kamion> ogra: I don't see any reason why we should import packages from apt-get.org that already exist in our repositories; I assume elmo has the sense to know that
<ogra> Kamion, we only assumed that it clashes, nobody of the MOTU does know the installer stuff good enough.....i'm fearing it might break something....
<ogra> even if it doesnt clash
<Kamion> ogra: AFAIK Joey Hess' repository is just a copy of stuff he's also uploaded to Debian
<Kamion> ogra: under no circumstances should any installer packages be synced
<Kamion> (from there)
<ogra> Kamion, ok...thanks for elaborating....nobody of MOTU could make that decision....
<mvo> ping thom 
<daniels> Kamion: yeah, I was curious to see if my xfree86 repositories were still there
<daniels> mercifully, they weren't
<mantiena> Hi all
<pitti> Kamion: I didn't understand why the ia64 image is too big...
<pitti> Kamion: second, I wanted to ask whether you already have the German d-i translations
<Kamion> pitti: almost, there are still some fuzzies and one untranslated
<pitti> Kamion: okay, I do the rest tomorrow
<thom> mvo: yo
<mvo> thom: IIRC you modified yelp to know about other installed documentation? if so, could you please have a look at #8194? 
<daniels> jbailey: did you ever get to have a look at that modified radeon_drv.o?
<jbailey> daniels: I tried it in with a few different combinations of modelines and stuff and it didn't seem to work.
<jbailey> daniels: I didn't want to declare it as non-working without chatting with you first, though.
<jbailey> I tried to look up what the modelines or sync ranged ought to be, and found a pile of conflicting answers. =(
<daniels> jbailey: hm. :\
<daniels> jbailey: if you could try the new radeon_drv.o with ModeLine "1680x1050"  147.14  1680 1784 1968 2256  1050 1051 1054 1087 (if it is indeed 1680x1050) and let me know if that works for you (if not, send along a /var/log/Xorg.0.log), that'd be great
<jbailey> daniels: If you'd like, I can wire up that computer now and hack, or arrange to do so tongiht.
<daniels> jbailey: it's not urgent, just sort of a morbid curiousity
<thom> mvo: sure
<daniels> it's pretty much the only case where radeon doesn't Just Work these days
<mantiena> mdz: hi, you told, that udev config file patch for firewire device (see bug #3609 ) should be applied to ubuntu hoary, but it seems firewire devices still doesn't work with ubuntu :( Maybe you could apply fix from bug #3609 to udev package ?
<jbailey> daniels: Well, I'd really like to to work if you have the time.  It's a shame to have a lovely monitor here and have that box in text mode.
<mvo> thom: I wonder if I register the documentation wrong in some way, would be nice if you have a idea. if not, I'll look seriously into it tomorrow
<dholbach> bbl
<mvo> bye dholbach 
<jbailey> daniels: I'm sort of here and there today, but I have a few things that I want to do workwise, so I can match whatever schedule you need if you have time.
<thom> mvo: i'll check in a second; i suspect it's a problem with the omf generation in doc-base, personally
<mvo> thom: thanks! there is no hurry :) 
<daniels> jbailey: sure.  i'll be heading off as soon as i upload xorg for tonight (it's 0007 on a public holiday, and i've been involuntarily nodding off all day), but should be back in about 10-11h if you're around?
<infinity> jbailey : Will you run screaming if I utter the term "refcount"?
<jbailey> Yeah, sounds lovely.  I'll probably be at the gym around then, but can be bck right after it.
<daniels> jbailey: sure, well I'll be around for more or less the whole day after that, so I'll catch up with you then
<jbailey> infinity: No, I'd reply 'begone and come back in 6 weeks when we have a new glibc'.  There's no refcounting bug that's lasted this long that is going to get fixed for either hoary or sarge.
<jbailey> daniels: Lovely.  Beau rves!
<jbailey> infinity: In 6 weeks, I'll run screaming. =)
<infinity> jbailey : I'm beginning to suspect it never got fixed at all.  And I don't think it is in 2.3.4 either.
<jbailey> infinity: Nasty.
<infinity> jbailey : The stars must have been aligned when gotom previously "fixed" it and we all signed off on it.  If I build a chroot from October last year, it's still there, and it's still there on current Sid.
<infinity> jbailey : And Hoary, for that matter.
<jbailey> infinity: I hate to say it, but then it's not a regression against Warty for us.  I'd truly love to fix it, but I don't have the time right at the moment to dive through the linker.  If it's in currenty 2.3.4 I can make it urgent for right after Hoary releases.
<jbailey> infinity: If the fix is clean,  I can ever ask for it to go into hoary-updates and warty-updates.
<jbailey> s/ever/even/
<infinity> jbailey : Yeah, I'll see what I can work up in my personal time.  I didn't assume it'd be Hoary-urgent either.
<jbailey> infinity: Well, I would like to learn that part of the linker.  It was impossible for me to learn it in 5 minutes here and there around my previous IT job and gotom wound up tackling it.
<jbailey> So if you don't have time, don't feel bad. =)
<infinity> The only thing I feel bad about is the Woody->Sarge regression, but I'm more than happy just telling people to upgrade to apache2, which "fixes" the bug.
<jbailey> infinity: Can you put something in bugzilla, and call it major and target it to 5.10?  It'd be nice to have running commentary if you do wind up working on it, and I can do the same there.
<jbailey> infinity: If I can get it done before sarge freezes, I'm sure Steve will accept it. =)
<infinity> jbailey : I'll do something about it in a day or so, when I'm back on a real network.
<jbailey> infinity: Thanks.
<Mithrandir> jbailey: any chance of getting the multiarch ld patch applied for sarge? :)
<jbailey> Mithrandir: Yes, it's one of the dpatch's that I need to contrib back to Debian.  I have 3 or 4.
<jbailey> Mithrandir: We went through the list as a group late last week.
<jbailey> (On #d-glibc)
<Mithrandir> jbailey: I'm just afraid of missing the freeze.
<jbailey> Steve knows that it's coming.
<Mithrandir> jbailey: oh, ok.  I didn't notice, was probably away.
<jbailey> Right.
<Mithrandir> but if you are handling it, I'll stop prodding
<jbailey> No, it's all good feel free to prod. =)
<Mithrandir> ook
<fabbione> mako: hey guys
<fabbione> ops
<fabbione> hey guys
<daniels> hey fabbione
<fabbione> hey dude
<fabbione> what's up?
<daniels> sup?
<daniels> nommuch, just about to upload a new xorg and head to bed
<fabbione> nm.. just come back from a long walk around cph
<daniels> cool, where'd you walk to?
<fabbione> daniels: did you coordinate with mdz?
<daniels> fabbione: he wants it uploaded asap
<daniels> and this one works fine with the live cd
<fabbione> daniels: in the north part, beaches and stuff like that
<daniels> and fixes a *lot* of bugs
<daniels> ah, awesome
<fabbione> daniels: ah ok :-)
<daniels> i didn't get to see too much of the northern part while i was there
<daniels> mainly down south
<fabbione> yeah
<fabbione> the north part is a bit far
<fabbione> both by car and by public transport
<Mithrandir> fabbione: I found my fleece neck, btw.
<daniels> fabbione: ah, ok
<daniels> that'd be it, then ;)
<fabbione> Mithrandir: ah good
<fabbione> daniels: ehehe
<fabbione> Mithrandir: i was sure it wasn't in the car
<fabbione> let see.. this should be the final build for 386-xen0 :-)
<fabbione> xen is nice, but it lacks support for a lot of stuff
<fabbione> Kamion: around?
<fabbione> daniels: btw.. i had some weird ideas about the multiarse setup....
<Kamion> fabbione: yo?
<fabbione> daniels: xen might solve most of our problems...
<daniels> fabbione: i haven't played around much with xen, nor do i really know much about what it is ...
<fabbione> Kamion: yo.. i did see the 2 d-i uploads, but didn't notice anything about sparc. mind to queue the silo ramdisk_size for the next one?
<fabbione> daniels: it's like an e10k in software. Hardware partitioning basically
<Kamion> fabbione: what do I need to do?
<fabbione> [main kernel]  <-> [N child kernels] 
<fabbione> Kamion: for some reason the calculated size was too small (d-i -21)
<daniels> fabbione: ah, crack
<Robot101> if anyone can think of a cool PhD for me to do based around Xen, let me know :P
<daniels> fabbione: so what, run one session in each kernel?
<fabbione> Kamion: i think forcing it to 32Mb should be opk
<fabbione> daniels: yes, but each kernel has restricted access to assigned hardware
<fabbione> daniels: that would solve the problems configuring X for example
<fabbione> daniels: since it doesn't need to be special cased
<daniels> right
<fabbione> on the otherside installation of a xen environment is more complicated.
<fabbione> but there are several benefits imho
<fabbione> like separate upgrades on each virtual machine
<Robot101> fabbione: what's your particular application?
<fabbione> Robot101: for xen? right now i am evaluating the option to use it for my server
<fabbione> that is running N services, and split them in virtual machines
<fabbione> kinda of very hard chroot
<Robot101> yeah
<fabbione> isolating domain0 for world
<fabbione> and allow access to it only via console
<fabbione> that could reduce the introsion to one execution domain
<Robot101> xen has attracted a lot of funding along these lines, and being able to migrate running domains between machines
<fabbione> Robot101: that too. i still need to investigate that option
<fabbione> right now i am making installable decent kernels :-)
<mako> fabbione: oi
<Robot101> xubuntu! :)
<mdke> is jdub around?
<fabbione> Robot101: ehhe, as soon as hoary is out, i will upload the kernels
<fabbione> mako: sorry.. i didn't want to disturb.. just a wrong tab completion
<mako> :)
<fabbione> anyway there are still a lot of limitation for 2.6.10
<fabbione> i need to check what's in bk
<daniels> mdke: unlikely, it's 1am on a public holiday
<Simira> fabbione: hi there! How's life?
<mdke> daniels, heh
<Mithrandir> Robot101: would xubuntu be ubuntu sans gnome, kde and just plain X?
<mdke> daniels, doesn't the same apply to you?
<fabbione> hey Simira !
<Robot101> Mithrandir: no, with xen so it runs all three at the same time! :)
<Mithrandir> Robot101: scary. :)
<fabbione> Simira: everything is fine, thanks! how was your holiday?
<Kamion> fabbione: I'll see if I can find out why the calculated size was too small, first
* Mithrandir hugs Simira 
<Simira> fabbione: wonderful, and a bit tiresome. Now we're home, at last.
<Simira> fabbione: did Mithrandir tell you what he did last sunday morning?
* maswan prods elmo wrt setting up the syncproxy triggers
<daniels> mdke: yeah
<fabbione> Kamion: sure, but since it is not important, please do not spend too much time. If it is hidden just force it to 32
<fabbione> Simira: no, he didn't :-)
<fabbione> Simira: what did he do?
<Simira> fabbione: not? He proposed. I was dieing to tell you, but some other people should be told before others, so...
<fabbione> AHAH GREAT!
<fabbione> Mithrandir!!!!
* fabbione hugs Mithrandir and Simira
<fabbione> Simira: of course, i understand :)
* maswan congratulates Mithrandir and Simira too :)
<daniels> congratulations, guys
<mvo> congratulations!
<Simira> thanks :)
* Simira is very very happy now
<fabbione> Mithrandir: now.. didn't I teach you anything of life???
<fabbione> Mithrandir: didn't you see ME while you were here?
<sabdfl> HAPPY EASTER everybody
<fabbione> hey sabdfl !
<fabbione> thanks same there
<Simira> fabbione: he went out to get our kebab order ;)
<fabbione> Simira: ah ok :-)
<fabbione> i will tease him later
<daniels> sabdfl: happy chocolate weekend
<Simira> happy easter, yes! :)
<mvo> thanks sabdfl, happy easter to you too :)
<ogra> hey sabdfl 
<ogra> happy easter
<daniels> (my little sister has been sugar-rushing all weekend; i don't like chocolate, so she grabbed most of the eggs i got from various people)
<Simira> fabbione: you're welcome ;p
<fabbione> Simira: eheheh
<Simira> daniels: hey, I'll be glad to take them
<daniels> Simira: sadly I fear they may perish in the process of getting to you
* ogra wonders if its the spirit of this channel...
<ogra> Mithrandir, Simira coangrats
<ogra> -a
<Simira> thanks, all
<Simira> fabbione: *sigh* a kebab costs almost three times as much here as in Copenhagen
<crimsun> that's wonderful :)
<fabbione> Simira: yay!
<daniels> Simira: did you guys try the bella burger while you were in cph?
<fabbione> Simira: i love kebab, but i don't eat out so often..
<fabbione> daniels: no we didn't get to it :(
<Simira> fabbione: neither do we
<fabbione> daniels: they were here only 2 days
<daniels> ahr :\
<Simira> daniels: nope. three days, btw. But still :p
<fabbione> bella burgers ++
<daniels> heh
<daniels> those burgers are crack
<Simira> but we (I) got a lot of LEGO and DVD's
<fabbione> they are awesome
<daniels> yeah
<fabbione> I got LEGO for easter :-)
<Simira> oh!
<Simira> lucky you!
<fabbione> instead of the usual eggs
<Simira> we got red roses, from my parents :)
<fabbione> my wife seems to like the nerd inside me :)
<Simira> and safran and tea from Egypt
<fabbione> Simira: nice
<Simira> fabbione: I bet she does
<daniels> fabbione: i had the mosskito grill the other day, which was about eur14 (dkk64?) for something way way bigger than the bella burger ... sausage patty, skinless sausages, chicken, huuuuge pork ribs, capsicum, chips, and a couple of sauces.  finishing that was way harder than the double bella.
<fabbione> ahhhhh
<fabbione> that sounds cool
<daniels> yeah
<fabbione> (106 DKK)
<daniels> they also have a chicken parmiagana that's pretty much bigger than my head
<fabbione> well that's not difficult
<daniels> oh, 1eur -> 8dkk, not 6
<fabbione> considering that is' empty
<daniels> yeah, but that's maybe 50 dkk :)
<fabbione> 7.57
<daniels> haha ... it's empty, but very very big
* ogra gets hungry....
<fabbione> daniels: tbh i think that if you have an idea, it would die of lonliness in your head :P
<daniels> heh
<daniels> i love you too, man :P
<fabbione> ahha
<fabbione> let me take some coffee
<sabdfl> i love the smell of chocolate in the morning
<thom> sabdfl: you never went to school past a mars factory, then
<Mithrandir> daniels: I can courier chocolate from you to Simira, no problem. :)
<Simira> :)
<fabbione> Mithrandir: bad boy!
<fabbione> ;)
<Mithrandir> fabbione: I'm nowhere as fond of chocolate as Simira, so most of it would arrive safely.
<Simira> most of it...?
<fabbione> Mithrandir: i am talking about you proposing Simira :)
<Mithrandir> fabbione: oh, :)
<thom> Mithrandir, Simira: congrats!
<Mithrandir> thanks to all of you :)
<fabbione> did you learn anything from our day in cph? :P
<Mithrandir> fabbione: yeah, you have a lovely wife.
<Simira> :D
* fabbione sighs
<Mithrandir> so I wanted one for myself. ;)
<ogra> heh
* Simira looks over at the jumping coconut... ^_^
* fabbione sighs again :)
<Simira> fabbione: no worries, I'll take good care of him
<Simira> fabbione: and make sure he takes good care of me
<fabbione> Simira: if you are not going to do so, you might wake in the morning with a head of a horse in the bed :P
<Simira> fabbione: I promise!!!!
<fabbione> good girl
<Mithrandir> Simira: just don't use multiple exclamation marks and all will be well. :)
<Simira> Mithrandir: you wouldn't let him do that to me, would you?
<Mithrandir> Simira: *hugs*
* Mithrandir wonders if we should move to #ubuntu-love soon ;P
<Simira> Mithrandir: you didn't answer....
<Mithrandir> Simira: of course I wouldn't
<fabbione> hmmm i think your life is going to DEVELop in a interesting way with the upcoming wedding ;)
<mako> mdz: around yet?
<sid77> hi
<sabdfl> hey mako
<mako> sabdfl: hola
<mdz> mako: yep
<mako> mdz: wanted to know if you needed anything from me (e.g., release announcement) for the RC
<mdz> mako: an announcement would be great
<mako> mdz: i told jane already but i'm probably going to be offline for 24hours starting this evening
<lu|sleep> mako: driving to DC?
<mako> mdz: ok cool.. i'll do it today
<mako> lu|sleep: bus down, sleeping in front of the court, bus back :)
<lu|sleep> hrm
<lu|sleep> _hrm_
<lu|sleep> __hrm__
<lu|sleep> I nearly emailed you on Friday about that
<lu|sleep> I saw wendy's blog
<lu|sleep> (see that last bit?)
<mako_> ok.. maybe i miseed something there
<lu|sleep> <lu|sleep> I nearly emailed you on Friday about that
<lu|sleep> <lu|sleep> I saw wendy's blog
<mako_> was i on wendy's blog?
<lu|sleep> no
<lu|sleep> but she is going down
<lu|sleep> well, going east for her
<mdz> mako_: what's gonig on at the court?
<mako_> oh yeah, tons of people are going down
<mako_> mdz: grokster v. mgm
<lu|sleep> I had an inkling you might do the same
<mako_> probably the most important technology case in front of the supreme court since betamax
<mako_> i figured i needed to go :)
<mako_> lu|sleep: my friend seth has been pestering me to go for MONTHS
<lu|sleep> finkelstein? or a different seth?
<mako_> schoen
<lu|sleep> ah.
<mako_> eff technologist
<mako_> i also know finkelstein and he may also be there, but we're not really good friends
<fabbione> YAY!!!
<lu|sleep> yeah, I know of seth schoen
<mdz> jbailey: ping?
<fabbione> 386-xen0_i386.deb
<mako_> nice :)
<mdz> sabdfl: welcome back
<Kamion> mdz: I'm finishing up the weekend's round of installer translations now
<daniels> mdz: good morning
<mdz> daniels: morning, is 6.8.2-6 on the way up?
<daniels> mdz: working its way there, yes
<mako__> dude...
<Kamion> -msgstr "Whlen Sie den nchsten Installationsschritt:"
<Kamion> +msgstr "Whlen Sie den nchsten Installationsschritt:"
<Kamion> argh, what has happened to the encoding in this file? it's not just UTF-8 encoding of ISO-8859-15, I don't think
<lu|sleep> mako__: your network problems are worse than mine
<lu|sleep> :)
<mdke> hi guys. for the last two days i've had MD5SUM mismatch errors when I apt-get update from the main ubuntu mirror and the gb. mirror. Just tried the us mirror and it works
<mdke> is this worth reporting anywhere?
<mdke> anyone know?
<trulux> mdke: same here, solved now
<trulux> it seems at least
<mdke> oh
<mdke> gb still has that issue
<mako> man, i never liked those guys anyway
<mdke> LOL
<mantiena> mdz: hi, you told, that udev config file patch for firewire device (see bug #3609 ) should be applied to ubuntu hoary, but it seems firewire devices still doesn't work with ubuntu :( Maybe you could apply fix from bug #3609 to udev package ?
<seb128> Kamion: when have you planned to do translations update for the installer ?
<fabbione> mantiena: afaik jbailey is looking at it
<mantiena> fabbione: really ? it would be very nice to have working firewire in ubuntu ;)
<fabbione> mantiena: you mentioned this bug already several times. yes, it will be fixed for hoary. don't worry
<mvo> hey Mitario 
<Mitario> hi everyone
<Mitario> hi mvo :-)
<mvo> Mitario: what was the url for your update-manager website again :) ?
<mvo> Mitario: I was asked about it today and I couldn't remember :/ (and I'm away from my home-computer)
<Mitario> mvo, the website is a bit messed up atm :( sorry, i'm moving some pages to a wiki
<Mitario> mvo, the page was hosted at my weblog, but i've been working on it this week
<Mitario> however if he's looking for a tarball, then it's still http://eyesopened.nl/~michiel/update-manager/
<mdz> mantiena: if you are concerned about bugs in Hoary, please consider ones with severity 'critical' first
<mvo> Mitario: ok, thanks
<mantiena> fabbione: thanks for info
<mdz> daniels: to where are you uploading 6.8.2-6?
<mdz> I thought you said the upload was in progress
<Kamion> seb128: I'm doing them now, got your mail and will include that
<Kamion> seb128: oh, I see that's only base-config
<Kamion> +"Certains logiciels limits peuvent fonctionner avec Ubuntu. Bien qu'ils ne "
<Kamion> +"fassent pas partie de Ubuntu, les outils habituels peuvent tre utiliss "
<Kamion> seb128: should that be "... pas partie d'Ubuntu"?
<seb128> it is
<Kamion> ok, I'll make sure that's changed throughout base-config
<seb128> I'm sending shadow now, and I'll start installer-po then
<Kamion> I'll go out to the shops before doing the upload orgy then
<seb128> hum, I've used a "de Ubuntu", or that's an auto-change from Debian ?
<seb128> k, thanks
<Kamion> that was almost certainly my fault when branding
<daniels> mdz: the upload itself is not actually in progress, no; i had to tweak one variable, as it happened
<mdz> ah
<daniels> mdz: if i'd already uploaded it, i'd not still be awake
<seb128> mdz: hi. Can we get a "REOPEN" in bugzilla ? :)
<daniels> hopefully this build will be quicker now that I haven't got a gnome-terminal session leaking 500MB of ram
* daniels glares at seb128.
<daniels> seb128: g-t!  leaky!
<mdz> seb128: bugzilla already has a REOPEN
<seb128> mdz: since when ?
<daniels> seb128: errr, we've always had reopen
<mdz> seb128: since we installed it
<daniels> seb128: with a reopened state, as well
<mdz> and before
<xuzo> i found a partial fix for the close-lid-crashes-x (#6993)
<mdz> xuzo: great, please add the information to Bugzilla
<seb128> daniels, mdz ? from NEEDINFO I've: ASSIGNED, UPSTREAM, FIXED/..., DUPLICATE, Reassign to, Reassign to QA 
<seb128> my account is broken or what ?
<xuzo> mdz: I think my fix is not very... ortodox
<seb128> I don't have a REOPEN, do you want a screenshot ? :)
<mdz> seb128: you can only reopen a closed bug
<seb128> yeah, and I want to reopen a NEEDINFO
<mdz> seb128: how can you reopen a bug which is already open? :-)
<xuzo> i wish to comment it with someone
<seb128> I don't want to ACCEPT it to get it out of NEEDINFO
<seb128> I want NEEDINFO to NEW
<seb128> even if that's not REOPEN
<mdz> ok, I understand
<seb128> I mean user provide details, that's not a NEEDINFO, I don't want to ACCEPT IT .. so what ?
<daniels> i think if you reassign it to someone random, then back to yourself, it should land in NEW (and not ASSIGNED)
<mdz> if details are provided and the report is complete, why not ACCEPT?
<seb128> because it's not for me
<seb128> ACCEPT mean that I'm going to fix it
<daniels> xuzo: if you provide the details of the fix on the bug, then that will probably help me find out what the real problem is
<mdz> seb128: I don't think we should put more work into fixing bugzilla's workflow, when we will be moving to Malone soon
<mdz> seb128: MOTU are already using malone
<seb128> k
<xuzo> daniels: I'm adding a comment at this moment on bugzilla
<daniels> xuzo: ok, thanks
<daniels> seb128: (the other hackish 'solution' is to close the bug and then reopen it)
<seb128> daniels: atm I leave them as NEEDINFO and forget about them, which is not ideal :/
<xuzo> daniels: done
<thom> redhat's bugzilla auto takes it out of needinfo and returns it to the previous state when more info is added, i believe
<daniels> xuzo: thanks
<fabbione> mdz: i think 6531 can be closed from our bugzilla
<daniels> xuzo: oh, fglrx
<daniels> xuzo: fglrx is really broken with suspending anyway
<mdz> fabbione: 6531 is a bazaar bug
<daniels> xuzo: but i think that specific bug has been fixed upstream in a newer version, regardless
<daniels> mdz: getting an xorg-driver-fglrx module in bz would be nice
<fabbione> mdz: well malone claims that the bug is Severity Normal
<fabbione> mdz: i think we should at least allign the 2 :-)
<mdz> daniels: hmm, my component sync tool doesn't look at restricted yet
<mdz> fabbione: let's worry about Ubuntu bugs, and let the Arch team worry about Bazaar bugs :-)
<fabbione> mdz: yes.. but due to the former that i found the latter :-) and reducing critical or higher from 10 to 9 looks nicer :)
<Kamion> seb128: thanks, merged both base-config and shadow translations
<fabbione> infinity: ping?
<daniels> fabbione: it's 0314
<xuzo> re
<trulux> are there any thoughts on upgrading PAM for Breezy?
<mdz> fabbione: limit your search to product 'Ubuntu'
<fabbione> mdz: yeah that too
<seb128> Kamion: thank you. base-config should here in ~20min
<xuzo> daniels: you are right, the problem is fglrx, now I am using "ati" driver and lid.sh works fine, chvt include. Sorry about the false alarm :(
<daniels> xuzo: no worries
<mdz> daniels: xorg-driver-fglrx added
<daniels> thanks
* fabbione bootstrap a new and fresh chroot
<fabbione> hey pitti
<trulux> pitti: heya
<pitti> 'lo everybody
<fabbione> pitti: where is my daily dildo? ;)=
<ogra> heh
<trulux> fabbione: it's connected to the 2nd usb port
<seb128> Kamion: installer I mean
<ogra> mdz, just fixing the last remaining bug in hwdb-gui before i get on with the server/client code, could you post the output of "cat /proc/asound/card0/id", since i got no card around where it occurs...
<daniels> daniels@catsby:~% cat /proc/asound/card0/id
<daniels> I82801DBICH4
<fabbione> FLY SPARC!
<mdz> mizar:[~]  cat /proc/asound/card0/id
<mdz> rev50
<fabbione> it's building universe at light speed and main is all synced
<ogra> daniels, yeah, yours looks good, mdz has a (rev 0) anywhere behind the name...
<ogra> mdz, thats all ??
<mdz> ogra: yes, I guess it's an ALSA problem then
<ogra> yup
<ogra> ok, so i consider that one fixed for hwdb-gui then :-D
<mdz> yep
<fabbione> offtopic: earth quake in indonesia
<ogra> yippie, on to the server code
<mdz> client/server is more important than any UI issues at this point; that is the top priority
<fabbione> (http://earthquake.usgs.gov/recenteqsww/Quakes/usweax.htm)
<mako> mdz: so, i just got an email to info@ubuntulinux suggesting that we just build ubuntu on gentoo
<ogra> mdz, starting now....and wont stop until its done
<mako> mdz: should i add this to the TB agenda? :)
<ogra> argh
<mdz> mako: I got a bug report that we should just use autopackage instead of the existing packaging tools
<zul> mako: umm..no..
<ogra> argh++
<daniels> fabbione: shit, hit in the same place again
<fabbione> daniels: yes and it has been pretty hard.
<fabbione>  MAGNITUDE   -  8.5
<thom> mdz: we have two days to RC, plenty of time
<mako> mdz: is it possible for a bug report itself to be a bug
<fabbione> thom: isn't RC tomorrow?
<mdz> we're building RC tomorrow for release Wednesday
* mako nods
<pitti> fabbione: sorry, no new crack today for you :-)
<fabbione> mdz: ah... ok.. and i was holding up -32 because i had the idea that it was tomorrow
<fabbione> mdz: well with +24 hours we can get -32 in for RC and i am happy with it for final
<mdz> fabbione: consider it tomorrow
<fabbione> mdz: ok.
<mdz> because we do not want to be making changes tomorrow while we are building and testing
* fabbione will hold up
<fabbione> mdz: sure, but i can test/upload this evening. in both cases i am happy as it is
<mdz> fabbione: there is time to upload -32 today if it is simple and safe
<fabbione> mdz: want to see changelog and diff?
<fabbione> Kamion: do you plan a d-i upload tomorrow?
<Goshawk> does anybody know something about this problem? (t_kernel_font: invalid argument) (during boot)
<Goshawk> it seems a error of k7 ubuntu kernels
* fabbione mumbles
<fabbione> mdz: i will wait with -32, just in case something else shows up.
<fabbione> mdz: one day won't make the difference
<fabbione> and rush is not wise at this point in time
<fabbione> pitti: thanks :-)
<mako> ok.. we have the names of the images for kubuntu been changed yet?
<mako> i got a report today about a mirror who has already screwed them up
<mako> :-(
<mako> the guy only figured it out because of the md5sum
<lamont> mako: I see no evidence of a change
<mako> lamont: neither do i.. but i heard it talked about
<mako> i sent a message to the admins
<mako> my complaint has been lodged
<seb128> Kamion: is "Kill switch enabled on ${iface}" visible during the standard installation ? I don't understand it
<fabbione> elmo: ping?
<daniels> seb128: depends -- it's wireless stuff
<daniels> seb128: some wireless chipsets have a hardware switch that completely disables the wireless interface; this is called the kill switch
<seb128> oh, thanks
<trulux> daniels: some laptops have problems with it, people talk sometimes on the need of booting with winxp and rebooting into GNU/Linux for being able to use the wireless card
<fabbione> hey lamont 
<trulux> daniels: are those issues solved?
<daniels> mdz: there you go, xorg 6.8.2-6 uploaded to jackass.
<daniels> trulux: should be, yeah (with hoary, at least)
<lamont> morning fabbione 
* daniels goes to pass out in bed, instead of occasionally falling asleep in his chair.
<fabbione> daniels: good night :-)
<Lathiat> daniels: its better in my timezone its only 1:46 :)
<pitti> lamont: #8277 -> may it be that the blacklist does not contain kde-i18n-* on some buildds?
<fabbione> lamont: i am taking a look at 7846
<trulux> daniels: good :)
<lamont> pitti: a couple do not.  but then a couple of adjacent buildds have it twice to make up for it... :-(  Fixing
<lamont> pitti: fixed
<pitti> lamont: great, thanks
<pitti> amu: here?
<amu> jep
<pitti> amu: can you please reupload kde-i18n to get an unstripped version?
<amu> pitti: ah, now i remember why i'm looking for you some hourse ago :)
<pitti> amu: I reassigned #8277 to you as a reminder
<amu> pitti: will tell haggai about it, the did the last upload 
<amu> the/he
<pitti> amu: okay, please re-reassign then :-)
<lamont> fabbione: no evidence in daemon.log to indicate two buildd's running - just double checked
<fabbione> lamont: i am just curious to see if i can reproduce it or something.
<fabbione> lamont: if 3/3 can't reproduce, we can atleast downgrade the severity
<lamont> fabbione: yeah, certainly
<carlos> pitti, amu: kde i18n setup is going to be "funny" while we add support in Rosetta for it
* carlos is scared
<fabbione> lamont: i just forgot to update my box in ages :-) it's taking time to get to debootstrap and do a clean chroot :)
<lamont> usually a good idea
<lamont> 358 upgraded, 13 newly installed, 0 to remove and 0 not upgraded.
<lamont> hrm... sounds like about time here, too
* lamont dist-upgrades
* lamont grumbles at xorg
<lamont> -6 better fix things...
<Kamion> fabbione: probably tonight
<Kamion> seb128: the string immediately following that one has more detail, too
<fabbione> Kamion: ok thanks. but i decided to wait for the kernel after RC
* mvo needs to leave now
<mvo> bbl
<seb128> Kaloz: yeah, I've sent an updated po, I didn't now about this switch
<seb128> ups
<seb128> s/Kaloz/Kamion
<mdz> lamont: ETA for xorg builds on first-class citizens?
<mdz> I'll want to roll cloop and livecd builds immediately after
<lamont> mdz: 20:03 for amd64, possibly i386.  20:33 for ppc
<luis_> so I'm getting one in a couple hours; I'll miss any dinner plans, I guess
<mdz> lamont: thanks
<mdz> lamont: can you start a cloop build as soon as 6.8.2-6 is visible to the cloop builders?
<lamont> xorg_6.8.2-6_20050328-1906               00:50:11 (2 entries, sigma 00:22:27)
<lamont> xorg_6.8.2-6_20050328-1906               00:40:38 (7 entries, sigma 00:02:59)
<lamont> xorg_6.8.2-6_20050328-1906               01:07:42 (3 entries, sigma 00:00:12)
<lamont> is i386,amd64,ppc
<mdz> 20:33 + epsilon or whatever
<lamont> and not that you care, but ia64 is: xorg_6.8.2-6_20050328-1906               02:26:22 (2 entries, sigma 00:02:04)
<lamont> mdz: will do
<mdz> thanks
<lamont> ubuntu and kubuntu, or just ubuntu?
<mdz> both, but I'll want to know when ubuntu is done, and kubuntu can lag
<lamont> right
<lamont> you want them launched as that arch is ready, or launch all 3 at once?
* lamont plans on former
<shaya> anyone know if its possible to save aptitude settings (i.e. packages that are marked A) and restore on another compuer ala dpkg --get-selections --set-selections
<Lathiat> shaya: Wrong place for such questions, try #ubuntu
<mdz> lamont: doesn't much matter; I'll wait for all of them to be ready to roll the CDs
<lamont> mdz: Ok
* lamont mumbles  something about hating uidev
<Treenaks> lamont: poke Md
<Kamion> seb128: installer translation merged, thanks
<Kamion> upload time
<lamont> Treenaks: first I have to figure out what I really want it to do.
<lamont> of course, WTH does anything wind up Build-Depending on it, I do not know
<frinkillo> mmm a little question: are there plans in Ubuntu to implement something like Redhat's Stateless Linux? (http://people.redhat.com/~hp/stateless/StatelessLinux.pdf)
<Kamion> mdz: please merge colin.watson@canonical.com--2005/casper--translations--0 up to patch-10
* fabbione giggles at 8312
<fabbione> mdz: i think you really want to explain to the submitter that he needs to read the run level specitications
<zyga> has anyone seen mvo lately?
<fabbione> zyga: he was online not too long ago
<seb128> Kamion: np, thank you
<seb128> zyga: he was here 1 hour ago
<zyga> ah, thanks 
<froud> seb128: ping
<froud> seb128: can you join #ubuntu-doc
<zyga> hmm how many #ubuntu-* are there?
<froud> zyga: a few to many :-)
<froud> zyga: my Konversation is lit up like a xmas tree. Flashing everywhere
* fabbione heads to sleep
<lamont> mdz: so, for the moment, the only viable solution (for between now and release), is to either (a) install udev and its depends in the chroot and then undo the udev postinst, or (b) drop kde entirely :-(
<lamont> so I did (a)
<fabbione> cya tomorrow guys
<zyga> Konversation? oh crap save us from appliKations
* lamont goes to track down exactly why kdeaddons build-depends udev, so he can hurt something
<zyga> lamont: good luck
* froud urges zyga to come to kubuntu :-)
<mdz> Kamion: casper 0.60 uploaded
<Kamion> mdz: thanks
<Kamion> mdz: my plan for tonight is: upload all translation updates (in progress); go to pub, have curry in attempt to get rid of sinus pain in most pleasant way possible; come back, upload debian-installer one way or another; build CDs
<mdz> Kamion: what time do you think the d-i builds will happen?
<mdz> Kamion: I'm currently planning to build&test live CDs as soon as lamont says they're ready
<Kamion> mdz: maybe 23:30 UTC under that plan
<mdz> ok, I'll proceed then, since I should be ready well before then
<Kamion> mdz: if you want to trigger a d-i build yourself at around 22:00 UTC (as long as there are no pending udeb build failures, which there shouldn't be), then that would be good
<mdz> ok
<Kamion> oh, hang on, timezone's changed
<Kamion> er ... make that 21:00 UTC
<mdz> oh
<mdz> cloop builds should start at ~20:33, so we should be right in sync then
<mdz> we can do daily+daily-live at the same time
<Kamion> is elmo around to do byhands?
<mdz> and use your new d-i build for both
<Kamion> and do you mind waiting until 22:30 UTC or so to start CD builds
<mdz> not sure; he said he had plans for the holiday
<mdz> why delay until 2230?
<lamont> did london swithc off daylightsavings already?
<lamont> non-conformists!
<Kamion> mdz: because I won't be back from the pub until then :P
<mdz> hmm,  I actually have an appointment this afternoon
<Kamion> and I would like to give everything a once-over just to be sure
<ogra> ouch
<ogra> http://lists.freedesktop.org/archives/hal/2005-March/002364.html
<mdz> Kamion: I'm going to be out from about 2000 UTC - 2230 UTC myself
<mdz> so that's just fine
<lamont> mdz: livecd builds launched - will double check in a minute to make sure they all got -6
<Kamion> lamont: yeah, we switched to BST on Sunday
<Kamion> UK and US are an hour out of sync for this week every year
<Kamion> mdz: ok, great
<mdz> so I won't be able to do an early set of live CD builds anyway
<Kamion> lamont: -6 of which?
<lamont> well, +1hour to my times earlier, then.
<lamont> xorg
<Kamion> ah
<Kamion> lamont: I'm trying to continue to think in UTC :-)
<lamont> Kamion: problem is, the DC machines are all on london time, not UTC... hence I tend to just convert to london time
<Kamion> aha
<mdz> they ought to be on UTC :-P
<Kamion> ok, all installer translations uploaded; I'm off for a few hours
<lamont> mdz: all building with -6
<lamont> (and past at least fetching xserver-xorg...)
<mdz> thanks
<dholbach> seb128: what about chucking out gtkhtml3.0?
<seb128> feel free
<dholbach> seb128: gnomesword doesnt like 3.6 :-/
<dholbach> but that seems the only problem
<seb128> that's a main package ?
<dholbach> nope
<Robot101> seb128: got any opinion on gaim spellcheck language patches?
<seb128> Robot101: not really looked on what it does yet
<Robot101> mine takes LC_MESSAGES and uses it as the dictionary
<Robot101> IME people complaining about "dictionary is not in my language" outnumbered people who have subsequently complained "dictionary insists on being in my language"
<Robot101> upstream disagree and don't want a locale-based patch that won't work on windows (?!)
<ogra> dholbach, seb128 but its a very popular package
<Robot101> (ie SeanEgan is a tool)
<seb128> ogra: but not maintained ?
<dholbach> ogra: we're talking about gtkhtml3.0 - there is gtkhtml3.6 already
<dholbach> ogra: or are you talking about gnomesword?
<ogra> dholbach, seb128 there was a looong thread on -users about gnomesword, it would be a pity not to have it in hoary too
<ogra> (even if i dont read the ible....there are many people wanting it)
<dholbach> i see
<ogra> bible even
<dholbach> well leave it in
<seb128> ogra: that's not the question, the question is to know if somebody has made it work with a recent gtkhtml
<ogra> try to fix gtkhtml3.0 if possible, universe still has some more days
<seb128> gtkhtml3.0 is not to fix
<ogra> seb128, i dont know
<ogra> seb128, why; it once worked....
<dholbach> i'll drop in a bugreport and we'll have to leave stupid gtkhtml3.0 in
<lamont> seb128: gal2.2 is b0rked on hoary/ia64
<lamont> versioned build-deps are a _GOOD_ thing, dammit
<seb128> how borked ?
<lamont> build-hoary-test/chroot-hoary-test/usr/lib/libgal-2.0.la
<lamont> build-hoary-test/chroot-hoary-test/usr/lib/libgal-a11y-2.0.la
<lamont> contain the string libhowl.la
<lamont> have a nice day
<seb128> ogra: it works, we just want to drop 3.0 because the current version is 3.6
<seb128> lamont: binary NMU ?
<lamont> seb128: don't ahve any of those in the archive at this time, and really shouldn't make any
<lamont> besides, it should really build-depend the right version of whatever gave it that illness
<seb128> so what do you want to do ? upload a new revision saying "fix on ia64" ?
<ogra> seb128, but regarding the popularity of gnomesword i'd bite the the bullet leaving it in universe
<lamont> seb128: the minimum would be a no-source-change upload (like you say)
<lamont> or just declare it dead and not bother... that's an mdz call
<seb128> lamont: we have talked about this, bumped all the GNOME package to the current gnomevfs version just to kick libhowl is bong
<seb128> the apps require 2.6 and we ask 2.10 for nothing
<lamont> ok
<mdz> ia64 is not on my radar until after Hoary
<mdz> in fact
<lamont> mdz: exact;ly
<mdz> Kamion: please remove ia64 from the default architecture list for CD builds until after Hoary
<lamont> mdz: another option for ia64 would be to have it just install server by default. :-)
<lamont> (that much works...)
<lamont> ogra: I think that's a blanket 'don't worry about the package if ia64 is the only thing broken'
<ogra> lamont, which is a good thing currently...
<lamont> right
<lamont> i386 cloop finished
<lamont> d-i uploads should (almost certainly...) be in the archive by :33
<lamont> mdz: i386, amd64 done, ppc is compressing
<lamont> and kubuntu livecd doesn't build (kdepim)
<Lathiat> is changelogs.ubuntu.com what the update manager uses?
<lamont> 30009 root      27   2  565m 513m 3136 R 86.2 25.4   7:46.55 create_compress    
<thom> lamont: yes
<lamont> wow
<thom> uh, s/lamont/lathiat/
<lamont> right
<Lathiat> thom: cheers
<Robot101> what sends the dbus events that update-notifier looks for?
<mako> userlinux makes me want to cry
<Lathiat> Robot101: i thought it used gamin to watch the dpkg status files
<mako> there are comments in the rules file rather than build-depends
<Robot101> mako: hhhnrgh
<mako> and no clean rule :-/ 
<mako> these are metapackages!
<mako> there aren't even real packages
<mako> it's amazing how screwed up they can be
<lamont> mdz: livecd builds on all 3 architectures
<ogra> mako, ping
<lamont> thom: fwiw, you had me searching for context there for a minute... :0-)
<mako> ogra: yes
<Mithrandir> lamont: I sat and looked through the mount source code today.  It'll be _neat_ if we pluginise it.
<lamont> Mithrandir: cool
<lamont> sounds like something for right after hoary, eh?  would be nice to involve upstream as well
<thom> Kamion: *g*
<tseng> mako: yo did you get my mail?
<thom> argh
<Mithrandir> lamont: yeah, I think upstream should be heavily in the process.
<thom> must learn to read before hitting tab
<thom> lamont: *g*
<lamont> heh
* lamont considers changing his nick to !!!
<Mithrandir> lamont: basically, all the file-system specific code can go away (or into per-fs-modules), so can the raid detection and a lot of other stuff.
<mako> tseng: probably.. i haven't finished my inbox for the day
<thom> !!!: sounds good
<Mithrandir> lamont: basically, mount is a lot of special-cases. :)
<lamont> Mithrandir: yeah
<lamont> with special sub-cases
<tseng> mako: ok cool. new CoC signage
<mako> tseng: rad
<tseng> i guess elmo needs to look at it too.
<thom> the Simple theme is awful
<ogra> thom, its simple :-P
<thom> meh. and i can't make firefox work right with it. oh well
<sid77> hi
<seb128> mdz: I've spoken with upstream about the gamin issue, he has no idea on the bug atm and that will need some debug. I've pointed pitti to him who has the bug easily on his box.
<Guilmon> is there a way to get the raw editor file for the graphics for the gnome post-login screen?
<Guilmon> I take offense at the "linux for human beings" ;)
<lamont> Guilmon: that's really a #ubuntu question, but gimp is your friend, I expect
<zul> hey lamont 
<lamont> hey zul
<zul> how is it going?
<lamont> grumblingly well, thanks
<zul> good :)
<Guilmon> lamont: how is that a #ubuntu question when sombody developed the image? ;)
<Mithrandir> Guilmon: there's a gconf key which points to the image; look under gnome-session stuff.
<Mithrandir> Guilmon: dude, if all that's developed is #u-d material, what would be the point of #ubuntu?
<Guilmon> Mithrandir: :) the user community? 
<lamont> Removing apache2-mpm-prefork ...
<lamont>  * Stopping web server (Apache2)...                                      [fail] 
<lamont> invoke-rc.d: initscript apache2, action "stop" failed.
<lamont> Guilmon: this is the channel to discuss your patch to the image/change in the process, etc/.
<lamont> questions about the product are in #ubuntu
<sabmoc> who would I talk to about getting support for setting up booths at confrences?
<tseng> sabmoc: id start with mako
<Guilmon> I think whoever created that image is a speciesist
<sabmoc> mako, ping re:confrence booths
* lamont looks around for thom, to hit him with apache2
<Mithrandir> lamont: wassup?
<Mithrandir> (I'm not thom, but I guess I can be hit nonetheless)
<lamont> grumble
<lamont> total and complete UPS failure... gonna have to get a new one now...
<mako> deb http://people.ubuntulinux.org/~mako/userlinux hoary main
<lamont> apache doesn't want to stop
<mako> userlinux packages isntallable on hoary
<lamont> in a chjroot
<mako> personally, i wouldn't touch them :)
<zyga> mvo: ping?
<Mithrandir> lamont: is /proc mounted?
<lamont> Mithrandir: specifically, if apach2 is _not_ running, and you say dpkg --purge apache2-mpm-prefork, it fails.;
<lamont> yep
<Mithrandir> hm, that's kinda bad.
<Mithrandir> I don't think there's a bug filed about it, so please file one?
<Guilmon> where I can email disputes?
<tseng> Guilmon: disputes?
<tseng> with whom?
<Guilmon> tseng: yes, its an outrage. Somebody is a speciesist
<Guilmon> tseng: "linux for human beings"
<tseng> uh
<dholbach> oh my
<tseng> I think ill just ignore that.
<Mithrandir> Guilmon: if you don't like that, I don't think Ubuntu is for you.
<Guilmon> Mithrandir: I can simply change the boot image to say a more appropriate and non-speciesist phrase.
<schweeb> Guilmon: you're wasting these good people's time
<Mithrandir> Guilmon: sure, please do that, but it's not something which is appropriate or on-topic here.
<lamont> Guilmon: file a bug at bugzilla.ubuntu.com, if you feel it needs to change
<Guilmon> lamont: theres nothign else in ubuntu which I could call offensive since humanity means more than 1 definition of "being human" but also means being humane.
<lamont> Guilmon: #ubuntu
#ubuntu-devel 2005-04-09
<sabmoc> mako, have time to talk about confrence booths?
<mako> sabmoc: give me a second.. i'm sending off something to -devel about these userlinux packages
<sabmoc> mako, no problem
<mako> sabmoc: hey dude
<mako> sabmoc: ok.. in terms of support for ubuntu at conferences .. the only thing we curretnly have to send is cds
<mako> sabmoc: but we can send as many as one might need
<sabmoc> mako, that is all we want
<mako> sabmoc: when?
<sabmoc> mako, the confrence is april 30th
<mako> sabmoc: no rush then.. you'll get hoary cds
<mako> how many cds do you think you want?
<sabmoc> mako, Im not sure
<mako> sabmoc: how big is the conference?
<sabmoc> can I get back to you on that
<mako> sabmoc: of course
<sabmoc> when do you need to know by?
<mako> two weeks from now? maybe a little bit more?
<sabmoc> I will let you know in less than a week
<mako> perfect
<sabmoc> Im still trying to find out if there will already be an Ubuntu booth there or not
<mako> go to shipit.ubuntulinux.org and make the request
<mako> if it's for whole boatload, it will not let uyou order them from the web
<mako> but you can set it to zero and then email me and i can place the order for you
<mako> but you still need to put your shipping information in that way
<mako> and you'll need to confirm any large order
<mako> what conf?
<sabmoc> mako, Linux NorthWest Fest
<mako> sabmoc: ahh. i think i am already sending CDs
<mako> someone else has contacted me about this
<mako> unless it was you
<mako> but there won't be a booth
<sabmoc> it might be someone from my team
<mako> hm.. send me an email
<mako> and i will put you guys in contact
<mako> better to have a coordinated ubuntu plan :)
<sabmoc> 3 members of the loco canadian team are going, was it Burgundavia  that contacted you?
<mako> yeah, i'm from seattle but i've moved out to nyc in the last year
<mako> no, it wasn't burgundavia, it was someone i didn't know
* Burgundavia is going if I don't get funding for UDU
* mako nods
<tseng> i think funding for udu is over
<sabmoc> ah ok, we'll I emailed the confrence mailing list so I should find out who else is going from ubuntu shortly
<Burgundavia> ya, but I tried
<tseng> at least people were getting it approved weeks ago
<Burgundavia> I really only decided recently
<Burgundavia> so I figured I would try
<Burgundavia> I don't really expect to get anything
* tseng neither.
<Burgundavia> which means it is LFNW for me
<sabmoc> *and the people rejoice*
<dholbach> azeem: ping
<azeem> hi
<mako> azeem: hi :)
<mako> dholbach: hi :)
<dholbach> azeem: i just saw that multisync was on our to-fix list and wondered if you wanted to fix it (http://people.ubuntu.com/~lamont/buildLogs/Test/m/multisync/0.82-5ubuntu2/)
<dholbach> hey mako 
<azeem> hi mako
<azeem> mako: you going to LinuxTag?
<lamont> dholbach: will look
<dholbach> lamont: hm?
<dholbach> lamont: i asked azeem :-)
<lamont> dholbach: doh\
<dholbach> lamont: but i won't stop you :-)
<lamont> saw the highlight, assumed me... :-)
<lamont> I don't always like that the buildlogs are under ~lamont
<dholbach> i want   http://qa.ubuntu.com   :-)
<azeem> dholbach: hrm
<mako> azeem: yes, i plan to
<lamont> hrm.. that one seems vaguely like something under the 7891-ish (7885-7893 ish)
<azeem> nice
<mako> azeem: i submitted a couple talk proposals but they haven't gotten back to folks yet.. i guess there's some delay
<schweeb> dholbach: indeed
<azeem> mako: you going to LSM as well, right?
<mako> azeem: yes, i'm definitely going there.. i'm on the schedule already
<azeem> mako: see #debian-devel@OFTC from half an hour ago, tbm talked about it
<azeem> (delay, that is)
* sabmoc is away: onBlur();
<mako> yeah, i'm not really worried 
<mako> whatever :)
<Mithrandir> sabmoc: please turn off public away.
<mako> but if my ubuntu talk gets accepted, it means i can go and not take vacation, which vastly increases the chances of me being able to go :)
<xuzo> is the "automount usb devices" feature supposed to work on hoary?
<azeem> dholbach: heimdal-dev and libedata-book1.2-dev can't be installed together in hoary, though I haven't figured out why yet
<Kamion> mdz: ia64 CDs> done
<dholbach> azeem: *argl* i'll have a look at it too
<fyrty> hola
<fyrty> alguien habla espaol ?
<Mithrandir> azeem: libedata-book1.2-dev depends on libkrb5-dev which conflicts with heimdal-dev
<azeem> ah
<xuzo> fyrty: #ubuntu-es
<seb128> azeem: and the reason is that firefox/kde use libkrb5, and we need to use the same to build stuff like OO.o
<azeem> well, not sure what to do; this doesn't look like a multisync issue
<seb128> just build it with krb5 ?
<azeem> ok
* azeem upgrades his hoary-chroot
<stuNNed> hi i can't find any documentation on loading a custom dsdt, i see this feature is avail in hoary, sorry for asking non-devel quest
<azeem> ok, seems to work fine
* lamont must run an errand to town. back in about 1.5 hours or so.
<azeem> eh, s/work/build/
<azeem> dholbach: http://people.debian.org/~mbanck/ubuntu-hoary/multisync_0.82-5ubuntu3_source.changes
<dholbach> azeem: shall i upload it for you or will it be in debian soon, so i could prod elmo to sync?
<azeem> dholbach: debian isn't affected, it doesn't have evolution-1.2
<azeem> or whatever it was that caused the problem
<dholbach> azeem: alright, will look in some minutes
<dholbach> azeem: thanks for fixing :-)
<azeem> I haven't tested whatever part of multisync it is that uses heimdal/kerberos, but the basic packages still run
<seb128> azeem: and evo uses heimdal for debian
<azeem> ok
<zenwhen> hald is suddenly eating cpu cycles out of nowhere
<zenwhen> enough to make my system choppy
<kent> has some one tried to move the gcursor function to gnome-theme-manager yet?
<ogra> kent, next release
<kent> ogra, as in Gnome 2.12?
<ogra> kent, probably, i'm thinking about looking at injecting it in the theme manager for gnome 2.12
<kent> ogra, I grabed gcursor source from ubuntu archive and looked at it (and theme-manager in capplets from ubuntu archive - using hoary) and it seems that it should not be so hard to do. I even played with glade and made the .glade file for theme-manager get a tab for cursors, just for fun. I can hardly code so I cant help :(
<seb128> ogra: I'm not sure that's a good idea, rather the mouse capplet
<seb128> ogra: http://bugzilla.gnome.org/show_bug.cgi?id=110670
<ogra> seb128, anywhere it fits ;) i havent looked into it extensively yet....wanted to talk to jdub once i have a bit spare time....
<seb128> why to jdub ?
<ogra> seb128, he wrote somethig about including it on ubuntu-devel recently
<seb128> just a remark than it would be nice in a capplet IIRC
<seb128> you probably want to talk to sven, he's one of the upstream 
<seb128> (he's on the MOTU list IIRC)
<ogra> seb128, i know.... i'll have to review his hula packages before release....
<seb128> k
<jdub> yeah man, i would totally send you to talk to someone else anyway :)
<ogra> heh
<ogra> jdub, its not on my todo currently, but i kept your mail in mind...
* jdub thinks it could appear in both the mouse and theme/detail capplets
<ogra> and i'll come back to it if nobody else implements it
<seb128> patches are welcome upstream :)
<ogra> :)
<seb128> jdub: sorry to bother you again with that, but is there any desktop file update planned for g-a-i or that's shifted from hoary ?
<jdub> http://lists.debian.org/debian-devel/2005/03/msg02698.html
<jdub> seb128: yes, i am doing nothing else today :-)
<seb128> :)
<jdub> http://lists.debian.org/debian-devel/2005/03/msg02694.html
* seb128 kicks firefox
<seb128> the grey backgrounds are ugly
<ogra> i like them
<jdub> seb128: yeah, somehow the "use system colours" switch was turned on
<jdub> thom: ping
<seb128>  mozilla-firefox (1.0.2-0ubuntu2) hoary; urgency=low
<seb128>  .
<seb128>    * Fix gtk2 themer to correctly set foreground and background
<seb128> 
<seb128> hum, I may want this update :)
* ogra slowly starts to think that telling people to send the hwdb data to his mailbox as a fallback was an ill idea....
<mdke> is something up with the archives atm?
<zenwhen> is it flooding in ogra?
<mdke> been getting errors for ages
<jdub> seb128: d'oh
<zenwhen> is the server that was supposed to receive that data not up yet?
<dholbach> zenwhen: no, not up yet
<ogra> zenwhen, yup....today the traffic rised, wondering why
<ogra> and i got my first mac mini submission :-D
<mdz> Kamion: still here?
<zenwhen> :D
<dholbach> seb128: what about the  gtk-doc-tools -fix? will we get it from debian?
<dholbach> seb128: i think i'd need it for a fixed gmime2
<seb128> Do we have a build issue for something ?
<dholbach> seb128: hm?
<seb128> I've ignored that because I've not noticed any breakage due to gtk-doc-tools for the moment
<seb128> and there is no reason to change something working :p
<dholbach> seb128: http://people.ubuntu.com/~lamont/buildLogs/Test/g/gmime2/2.0.14-2/gmime2_2.0.14-2_20050321-1131-amd64-failed
<seb128> k, I'll fix it tomorrow
<dholbach> seb128: thank you very much
<seb128> np
<seb128> BTW for the moment time to sleep
<seb128> 'night 
<dholbach> good night seb
<ogra> night seb128 
<mdz> does anyone know where Kamion left off?
<mdz> I don't see a new d-i upload, nor new CD builds as yet
<mdz> lamont: can you tell me if a d-i build happened?
<dholbach> mdz: 1h40m ago he said the last thing, but i'm sure you know that already
* dholbach looks at xcruise
<Kamion> mdz: yes, hold on a sec
<Kamion> lamont: if so, could you tell me what version of eject was in the powerpc d-i build you did?
<Kamion> s/you did/that happened/
<Kamion> the noises I was hearing in scrollback were of a d-i build happening disturbingly early
<mdz> Kamion: I see no d-i build in the upload queue
<Kamion> mdz: ok. (I'd gone off for a bit to do things at home while stuff built ...)
<zul> mdz: ping...bug #8288...???
<zul> mdz: nm..
<Kamion> mdz: shall I trigger one, or have you done so?
<Kamion> zul: might be worth pointing out to that patch submitter that setting bugs PENDINGUPLOAD when they aren't in a developer's local tree yet actively gets in the way of our tracking
<mdz> Kamion: I have not, feel free
<Kamion> running
* lamont did not do a d-i build
<lamont> I just indicated when I thought it would probably be ready for one...
<Kamion> sed: can't read debian-installer_20041227ubuntu23.0.20050329_i386.changes: No such file or directory
<Kamion> mv: cannot stat `debian-installer_20041227ubuntu23.0.20050329_i386.changes': No such file or directory
<Kamion> sed: can't read debian-installer_20041227ubuntu23.0.20050329_amd64.changes: No such file or directory
<Kamion> mv: cannot stat `debian-installer_20041227ubuntu23.0.20050329_amd64.changes': No such file or directory
<Kamion> is that bad?
<lamont> Kamion: did you happen to just have a build running?
<mdz> Kamion: what time do you want to start the upload quarantine for RC?
<Kamion> lamont: what do you mean?
<lamont> yellow had two buildd's running...  Just did a killall make on it...
<lamont> so if you were running BuildDI, um... oops
<Kamion> lamont: yes, I just had a build running
<Kamion> lamont: same on mcmurdo
<lamont> uh, want me to kick one, or you?
<Kamion> er, actually, do I mean mcmurdo? i386 and amd64 anyway
<lamont> didn't kill mcmurdo, though...
<Kamion> lamont: please do, I've lost track of which is which
<lamont> yellow == amd64
<Kamion> hooker's finished apparently successfully; that's ia64 IIRC
<Kamion> ross (powerpc) is still going
<Kamion> mdz: main thing that concerns me is that I haven't yet received a complete Xhosa installer translation, and I know that's a target
<Kamion> Adi promised me a new set of files today, but I guess that slipped
<mdz> we set a deadline for it; if it missed, it missed
<lamont> wanna-build -bamd64/build-db -dhoary --info debian-installer
<lamont> debian-installer: not registered
<lamont> wth?
<Kamion> mdz: other than that ... what's the GNOME situation?
<mdz> Kamion: we're going to delay final to get 2.10.1 in
<jdub> ?
<jdub> why?
<lamont> Kamion: amd64 running
<mdz> jdub: because we don't have time to test that stuff on the day of release
<jdub> but how much do we care?
<jdub> some releases will be translations-only -> pretty safe
<mdz> depending on which packages drop on the last day, we might care a lot
<lamont> Kamion: for future note, BuildDI should not be run in a time that spans :[03] 3
<jdub> some releases will have changes, some of which we care about, some we don't
<jdub> mdz: the tarballs are released on the monday
<mdz> jdub: last time they rolled in monday, tuesday and wednesday
<mdz> if we are guaranteed to have them all on monday, we can do that
<mdz> and go out on the 6th
<jdub> we're not, not entirely
<jdub> but i'm not sure why we care
<jdub> much of the important stuff will be in cvs already
<mdz> we need to give ourselves a full day for release prep and test cycles
<mdz> that means no last-minute new code
<Kamion> lamont: hmm. ok :)
<jdub> so let's not take it
<jdub> i really don't think this is slip-worthy
<mdz> I gave sabdfl the options, and he said he would rather delay than miss some 2.10.1
<Kamion> I'm all for a plan that involves giving ourselves a full day for test cycles, because that means I might not nearly kill myself with work on release day
<mdz> when I suggested that we take what we had on Monday out of 2.10.1
<lamont> Kamion: the failure on mcmurdo was because debian-installer/Packages.gz didn't exist when you tried to fetch it, you see....
<Kamion> I slept for sixteen hours straight following warty release
<jdub> Kamion: the objective for breezy is to have three :)
<mdz> jdub: I'll postpone announcing the delay if you want to argue your case with him
<Kamion> jdub: three what?
<mdz> I did present that as one of the options
<jdub> Kamion: days
<Kamion> yeah. and will that actually happen, I wonder? releases have been awfully last-minute so far
<mdz> jdub: for Breezy, I want to sync RC with GNOME 2.12
<Kamion> so excuse my scepticism :-)
<jdub> mdz: there's probably little use. it's going to be bling-related.
<jdub> Kamion: yes, we'll lock down on monday and release on wednesday, same as gnome.
<mdz> jdub: the argument was that if we do that, we don't have GNOME 2.10, and we don't have GNOME 2.10.1, we have a mix
<Kamion> jdub: it has never actually happened that way so far
<Robot101> *sigh at impending flamewar*
<jdub> Kamion: i'm not saying it has, i'm saying it will
<Robot101> someone proposed a patch to make Gaim use GConf
<jdub> mdz: the mix really doesn't matter -> we're very smart people :)
<mdz> jdub: I know
<Robot101> the windows porter helpfully pipes up to explain how much that would suck
<mdz> jdub: it's a matter of what we say in the release announcement, I suppose
<jdub> mdz: explain RC/2.12 sync?
<mdz> jdub: giving us a full week to QA before final
<jdub> mdz: 2.12.1?
<mdz> jdub: er, yeah, I meant 2.12.1
<jdub> yeah, agree
<jdub> we do mon/wed the week after
<mdz> right
<jdub> in that case, i'll schedule 2.12.1 now
<Kamion> that all makes sense; it just has to include EVERYTHING, including <small>artwork</small> ;)
<mdz> jdub: speaking of artwork, do we have a sound theme or no?
<jdub> no
<mdz> do I need to call Cliff?
<mdz> the sound theme was part of the package
<jdub> probably not
<sabmoc> smurfix, awake?
<Kamion> lamont: ross is done; do I have the other two d-i uploads?
<Kamion> lamont: (and were the d-i uploads from hooker and ross sane, given that I started them between :30 and :33?)
<lamont> Kamion: ross is, um. not done.  same issue (upload didn't happen see my WTH question above - babysitting this run
<lamont> the other 2 are uplaoded
<lamont> ross either made it or didnt.
<lamont> \Mar 29 02:00:24 buildd-uploader: Setting to Uploaded(hoary): debian-installer 
<lamont> mdz: any chance you can still kick cron.hourly on jackass?
<Kamion> lamont: ok, could you babysit a rerun? I don't want to rerun it myself because I know build,build without intervening byhand is risky
<lamont> Kamion: ross is now uploaded
<lamont> but that :24 means it may have missed the last cron.hourly before the :03 cron.daily
<Kamion> and hooker is currently EDONTCARE
<ogra> sabmoc, its 3am here, only the crazy guys are still up :)
<lamont> righty
<dholbach> yeah
<mdz> lamont: I have the privileges to do so; I do not know whether it is safe
<lamont> although I'll go kick it anyway after cron.daily
<lamont> mdz: then nm,
<sabmoc> ogra, so you're saying smurfix isnt crazy enough?
<lamont> mdz: if we want to let Kamion sleep, and ppc doesn't show up in the archive with i386/amd64, then a cron.daily run after the :03 one finishes would be helpful
<ogra> sabmoc, he probably has a real life to cope with tomorrow ;)
<lamont> but not before it finishes...
<sabmoc> haha
<mdz> lamont: Kamion can sleep; I'll drive
<mdz> Kamion: the d-i build is basically only translation updates anyway, right?
<mdz> I don't anticipate any problems that would require your presence
<lamont> is d-i byhanding automated now?
<mdz> I'd rather you were well-rested for tomorrow
<mdz> lamont: no
<Kamion> mdz: right, just translations; the last base-config change is substantive, but is easier to fix if it goes wrong
<Kamion> I can test that tomorrow
<lamont> ah, well, I think that happens in cron.hourly, in which case that's ready to happen
<Kamion> I need to stay up for a little bit more to do the tail-end of translation coordination from today, but I'll go and crash after that
<Kamion> for some reason msgmerge is being a whole lot slower today than I'm sure it was yesterday
<mdz> Kamion: can you push an update of the published seeds?
<aj> hrm
<mdz> lamont: amd64, i386 and powerpc all showed
<ogra> argh....i knew adding a .desktop file was a bad idea....i get about a submission per minute....
<Burgundavia> ogra: isn't that a good thing?
<lamont> mdz: good
<ogra> Burgundavia, nope, not with this prerelease, i have to compute them all by hand then.... the next release adds a md5sum as filename instead of hwdb.xml....(already on my disk here)
<lamont> mdz: ia64 build launched, should anyone care
<mdz> wow, that byhand went poorly
<Kamion> http://mlf.linux.rulez.org/mlf/ezaz/ntfsresize.html -> mentions Ubuntu
<Kamion> mdz: done
<Burgundavia> ogra: ah
<mdz> I think we may need a new d-i build
<mdz> powerpc worked, the other two were skipped without warning
<Robot101> does the installer have a "Shrink Windows partition to make space for Ubuntu" option, or do you have to do it via the manual badger?
<ogra> Burgundavia, and i'll have to mail them the md5sum back to add it to their client....(its necessary to distinguish between the users)
<Burgundavia> ogra: ah
<ogra> Burgundavia, so it will be a lot of work waiting for me....
<Kamion> Robot101: manual
<lamont> hrm.. somehow that's not surprising...
<Burgundavia> ogra: anything I can help with?
<lamont> gimme a minute
<ogra> Burgundavia, not yet, but probably between RC and release....i'll come back to you ;)
<Burgundavia> ogra: ok
<mdz> lamont: it was my fuckup
<lamont> mdz: try the byhand again?
<mdz> lamont: I can't; the files have been moved away and I don't want to try to reassemble them
<mdz> safest would be a new set of builds
<mdz> Kamion: since he mentions Ubuntu, perhaps he could take a look at that new "ntfsresize ate my disk" bug?
<Kamion> mdz: I just followed up to that asking if the reporter could try the troubleshooting instructions
<Kamion> I imagine that's all upstream would say to start with anyway
<lamont> mdz: and you just need i386, amd64?
<mdz> lamont: is it significantly easier to skip powerpc?
<mdz> I thought you had started them already :-/
<lamont> one less machine to make sure it's right on...
<mdz> I guess we'll miss :33
<lamont> was dealing with an email issue - sorry
<mdz> my byhand fuckup was the result of having hacked the script to process a subset of architectures the last time
* lamont is currently wondering why debian-installer isn't even in wanna-build
<mdz> I want to keep it simple on this end
<lamont> so you want ppc again? or it's already in the archive?
<mdz> I want a full set of builds
<lamont> is there already a 20050329 in the archive for ppc?
<mdz> yes
<lamont> ok.  it'll get 200503290
<mdz> please give them all the same version number
<mdz> if you'd prefer to re-upload 20050329, we could try that
<mdz> I think it'll get rejected
<lamont> ok.. they'll all get 200503290
* lamont twiddles thumbs for another 2 minutes
<lamont> (waiting for :35)
<lamont> launched, x4
<lamont> interesting that d-i takes 6 minutes on ppc, 3 on ia64, 2.5 on amd64, and 2- on i386.
<Kamion> it has more bits to it on powerpc
<Kamion> three kernels ...
<lamont> ah, ok
<lamont> so with no more action on my part, bits should be ready to byhand at :44 ish
<lamont> er, :45, since cron.hourly has to run first
<zenwhen> http://gnomesupport.org/forums/
<zenwhen> oh neat
<Kamion> whoopsie
<lamont> so, for the record, :35 is too soon too. fixored
<lamont> ppc still running
* lamont puts buildd-mail on his fixit dammit list
<lamont> uploaded x4, should be byhandable in < 5 min
<lamont> :50
<Burgundavia> mako: ping
<lamont> mdz: feel free to verify that
<mdz> lamont: amd64, i386 and ia64 in byhand, powerpc in unchecked
<lamont> ppc will move at :50
<lamont> cool.
<jdub> gar, drowning in email is not a good start to the day
* lamont takes 10 minutes to work with his daughter on a bo kata
<lamont> jdub: you want more??? :-)
<jdub> not at all :|
<Kamion> mdz: the recipe in #1912 reproduces for me with 2.10, and indeed 2.11 appears to fix it (and mentions some long file name fixes in the changelog)
<tseng> jdub: i could send you one about libmono-dev
<Kamion> mdz: can I sync it?
<jdub> tseng: hrm, which reminds me -> mono 1.0.6 (or patch to fix beagle-related bug)... doable?
<mdz> Kamion: which bits of dosfstools do we actually use (if any)?
<mdz> if it can't break anything, sure
<tseng> jdub: do you know what $beagle-related-bug expands to?
<Kamion> looks like Debian #294177 in fact
<jdub> tseng: not in any useful detail.
<tseng> jdub: thats helpful..
<mdz> jdub: any chance of getting the last of this gamin stuff cleaned up in the next few days?
<mdz> jdub: I can reproduce #7078
<jdub> tseng: dude, #dashboard :-)
<tseng> dude, im in there
<jdub> mdz: DV refuses to believe either us or the red hat desktop team that this bug exists
<jdub> mdz: i'll point them all at martin's test output tonight, see if i can get some traction
<mdz> jdub: is there any way to get debug output out of gamin?
* lamont is back
<mdz> either end of it?
<Kamion> mdz: as far as I can tell we don't use any of it by default; we turned it all off in warty
<jdub> yeah, both GAM_DEBUG=1
<lamont> Kamion: they give you bo kata's in your school?
<mdz> Kamion: perhaps we should remove it from base for breezy then
<jdub> mdz: see martin's output files
<mdz> lamont, Kamion: byhanded
<mdz> ah, ok. so there's probably not much I could add by collecting more traces
<Kamion> mdz: that would go against the "install useful filesystem stuff by default" bits, I think; and I think support for VFAT is really rather good to have. all I meant was that the installer doesn't run any dosfstools code automatically
<wasabi_> good morning ubuntu-nam
<Kamion> lamont: shotokan's entirely unarmed
<Kamion> mdz: sync request mailed, anyhow
<mdz> Kamion: I'm ready for CD builds, you?
<Kamion> mdz: don't see new d-i in the archive yet
<Kamion> oh, duh, my bad
<mdz> already synced to little
<Kamion> mdz: looks good; I've started cron.daily
<wasabi_> so like where are buildd logs kept?
<wasabi_> not just the "what's building" but the full output
<Kamion> wasabi_: http://people.ubuntu.com/~lamont/buildLogs/
<wasabi_> oh duh, i was in Lists
<Kamion> whoa, debian-cd is REALLY verbose now I turned up the verbosity so I could see what list2cds was doing ...
<mdz> Kamion: you're doing a non-jidgo build, right?
<mdz> we don't have all day ;-)
<lamont> Kamion: unarmed is so, um, unarmed. :-)
<Kamion> mdz: we so do ;)
<Kamion> mdz: I didn't turn jigdo off
<mdz> Kamion: I can't start live builds until those are finished, no?
<Kamion> mdz: that's true
<mdz> it takes like an hour with jigdo
<mdz> and perhaps 10-15 minutes without
<Kamion> sigh, oh-kay, restarting
<lamont> Kamion: you should schedule the builds so that livecd builds first... :-)
<mdz> thanks
<lamont> mdz: 7846: was not reproducible on the buildd
<Kamion> lamont: actually the crontab is indeed that way round
<Kamion> at least for Ubuntu
<Kamion> I've stopped that build and started a live one instead, to keep mdz happy :-)
* mdz does a little jig
<mdz> I will have all 3 live CDs downloaded and tested before you have your first jigdo file ;-)
<lamont> Kamion: did we schedule our workout BOF?
<Kamion> mdz: it makes zero difference to me, I will be asleep while it's building ;)
<jdub> mdz: so was the delay going to be one week, or one day?
<mdz> jdub: two days
<Kamion> lamont: nope
<jdub> to release on friday?
<mdz> jdub: yes
<mdz> the late-week kubuntu release went over well
<mdz> some might say a bit too well...
<jdub> late week is bad for pro press
<jdub> but that's not a huge concern for us atm
<mdz> if you're confident that we'd be happy with what we got on monday, we could reopen the discussion
<mdz> but we ought to decide on this before RC
<jdub> i don't think there's much point reopening it
<mdz> Kamion: ooh, .torrents, does that mean thom is giving us auto-torrent-love?
<Kamion> mdz: I put them in a suitable place and told him where they were; I don't know if he's done the other side yet
<mdz> Kamion: are the mirrors updated?
<mdz> I don't see any rsync connections active, but usually it takes longer than this
<Kamion> mdz: cdimage.ubuntu.com seems to be
<Kamion> mirnyy is happier of late, I think
<Kamion> install CD build running; I've disabled the cron jobs, so from now on Ubuntu CD builds are manual only
<Kamion> until RC goes out that is
<ogra> does anybody know of a python-cgitb backport for woody ? 
<mdz> thom: I've been seeing some instances where I don't get switched back to vt7 after opening the lid; is that likely the state-file-being-clobbered bug?
* Kamion -> bed
<dholbach> me too
<dholbach> i'm off to bed
<dholbach> sleep tight everyone
<fabbione> morning
<ogra> hey fabbione 
<fabbione> hey ogra
<daniels> kamion goes to bed as fabbione awake
<daniels> s
<dholbach> hey fabbione 
<fabbione> hey guys
<ogra> daniels, bah, sleep is for lamers *g*
<mdz> daniels: live CD testing with 6.8.2-6 is good on all my test systems
<daniels> mdz: yes, and as I detailed before, live CD and upgrade testing went through fine in all my scenarios here
<fabbione> mdz: are all the images up for testing?
<mdz> fabbione: live are up
<jbailey> Are these the RC images?
<mdz> install should be up soon if it isn't already
<mdz> the build is finished; not sure if the mirror is up to date
<mdz> jbailey: these are approximately RCCC images
<fabbione> mdz: roger
<daniels> release candidate candidate candidate?
<mdz> fabbione: both live and install are up
<mdz> daniels: yes
<mdz> daily-live/current -> 20050329
<mdz> daily/current -> 20050329
<fabbione> @ERROR: max connections (15) reached - try again later
<fabbione> bah
<jbailey> mdz: Cool.  Are we in a no-upload zone now, then?
<mdz> jbailey: we're in a be-careful-dammit zone :-)
<fabbione> hhehe
<jbailey> mdz: Yeah. Mostly I'd like to get the udev with ieee1394 in.  It's adding 4 lines to two config files.
<jbailey> It's be nice to be able to get feedback on that for RC.
<mdz> jbailey: test thoroughly and upload
<lamont> jbailey: if you upload udev, please do it while I'm awake, and tell me that you've done it...
<lamont> well, actually, as long as noone has _versioned_ depends on the newer udev, we're ok
<fabbione>  /usr/bin/autoconf: line 15: /dev/null: Permission denied
<fabbione> lamont: i guess you are talking about these errors, right?
<lamont> fabbione: yep
<lamont> fabbione: where was that?
<mdz> sparc, I hope
<calc> fabbione: nodev mounted
<fabbione> lamont: yes, sparc
<lamont> mdz: I still need to go finish cleaning up hoary-test
<fabbione> calc: udev double mounted /dev
<calc> fabbione: oh ok
<fabbione> i have seen it once already
<lamont> there are some of those that got marked as failed, etc
<lamont> fabbione: I just installed udev in the chroot, then umounted dev/pts, dev/shm, and dev
<fabbione> lamont: yes, that's why i noticed
<fabbione> lamont: what are the packages at fault? kdebase?
<lamont> fabbione: kdeaddons did it, dunno what else
<lamont> anything that build-depends somethign that depends hal, dbus-1, or udev
<fabbione> i noticed the first failure with kdebase..
<lamont> fabbione: I was beyond tracking down _who_ did it...
<lamont> was too busy fixing 2 chroots on 11 buildd;s
<fabbione> yeah i could guess that
<fabbione> so the solution is to install udev in the chroot basically
<lamont> yeah
<fabbione> hackish
<lamont> which means that lacking a build-dep on debconf, and about 15 others will no longer be noticed.
<fabbione> dpkg-gencontrol: error: package linux-xen0-2.6.10-5-386-xen0 not in control info
<fabbione> HMMMM
<lamont> fabbione: dealing with it properly is on my post-hoary list
<fabbione> lamont: yeah, there is no time for hoary...
<lamont> fabbione: my thinking for post-hoary is to divert start-stop-daemon, and mount :-)
<fabbione> lamont: good idea actually. btw how do you handle the mount of udev after a buildd reboot? manually?
<lamont> fabbione: I undo what the postinst did after installing it in the chroot.
<lamont> that way we have the udev package, but none of the doesn't-work-in-a-chroot instanity
<fabbione> i guess i need to check that
<lamont> insanity, even
<lamont> oh, and umount chroot-hoary/.dev as well. :-)
<lamont> if so inclined
<fabbione> so you install udev, but you don't run udev in the chroot....
<lamont> correct
<lamont> can't run udev in the chroot
<lamont> it kinda wants to be one-per-systemmm
<fabbione> and you mount manually /dev & Co.
<lamont> so you install udev in the chroot, undo the mount-funnies, and let it rip
<fabbione> gotcha
<lamont>  /dev is the static one that debootstrap built
<lamont> the trick is to make sure that udev's postinst _NEVER_ runs again.  And that you have /dev/ sane again.
* lamont grumbles at archive.u.c being > 15 _STILL)
<fabbione> meh.. you can only put udev on hold to avoid that
<lamont> yeah, but it has to be installed in the chroot, and you have to fix /dev to be sane
<lamont> and if someone has versioned build-deps on a newversion of udev between now and release, I'll have to hurt something
<fabbione> ehhehe
<daniels> lamont: wget it over the lan and then run rsync-over-ssh to chinstrap or so
<fabbione> lamont: what was that insane deb line to grab _all.deb from another arch?
<lamont> deb http://archive.ubuntu.com/ubuntu dists/hoary/main/binary-i386/
<lamont> it's not _insane_, it's just _sick_. :-)
<fabbione> ehehhe
<lamont> just don't let mdz see, or he'll get vomit on his keyboard again.
<lamont> mdz: why did 8187 and 8189 get pointed at kernel-team:?
* lamont grumbles at jbailey
<jbailey> lamont: Eh?  What did I do this time?
<lamont> jbailey: just trying to figure out why kernel-team wound up on the CC list for 8187, which you closed... dunno if it was you or not, though.
<mdz> lamont: wtf is that (dists/hoary/main/binary-i386)
<jbailey> lamont: It was openned with the cc: in place according to the bugzilla email I got.
<mdz> lamont: it came in with kernel-team on it
<lamont> mdz: that's the magical sources.list line to grab arch: all packages from i386.  apt ignores all of the Arch: i386 packages - since you're on sparc, or whatever)
<lamont> mdz: and yes, it's sick-and-wrong
* lamont reassigns 8189 to debzilla unless someone screams
<mdz> eek, archive-copier failed due to a segfault on amd64
<lamont> ew
<mdz> anyone else doing an amd64 test install?
<calc> mdz: i could download an iso and try it if no one else already has
<calc> but i wouldn't be able to actually do the install until tomorrow
* lamont will grab isos in the morning as well
<mdz> Mar 29 04:02:54 main-menu[3713] : (process:28494): Segmentation fault
<mdz> Mar 29 04:02:54 main-menu[3713] : WARNING **: Configuring 'archive-copier' failed with error code 139
<lamont> but I have no amd64 boxen
<calc> i did hear that some people were having issues with the recent amd64 kernels
<calc> post -28 iirc
<mdz> package-cache-n[28546] : segfault at 0000002a959bd000 rip 0000002a956ea59d rsp 0000007fbfffebc8 error 4
<mdz> the live CD was happy enough
<calc> i'm running a hoary install from several months ago that has just been upgraded over time
<calc> haven't rebooted since -28 though
<mdz> I need for someone else to check whether this works for them
<mdz> fabbione: do you have amd64?
<daniels> i'll test it
<mdz> thanks
<daniels> cdimage/daily/current/hoary-install-amd64.iso?
<mdz> package-cache-names.c hasn't changed in forever, I don't think
<mdz> daniels: yep
<daniels> rsyncing now
<daniels> can you squeeze an install into 1.8GB?
<calc> should be able to
<calc> my /usr is using 1.5 and i have other stuff on it
<daniels> remembering that we copy the archives on to /var
<daniels> hm, I could probably disable that
<calc> it should definitely fit if the cache was disabled
<mdz> I can reproduce the segfault using package-cache-names on the command line
<mdz> daniels: it fails well before you need to worry about that
<daniels> awesome
<mdz> powerpc gets past archive-copier OK, but it's broken in a different way
<daniels> as long as it's not my fault
<mdz> it asks a crazy malformed question
<mdz> seems to be apt-setup-udeb's fault
<mdz> I don't suppose there's a gdb-udeb
<daniels> there is, however, a wget-udeb
<infinity> fabbione : "the usual moon ray hitting the console cable during a solar ecplipse"?.. If that's a usual source of bugs for you, you may have issues. :)
<fabbione> infinity: do you have any better explanation other than Aliens have invaded our DataCenter?
<lamont> daniels: and an ssh-client-udeb
* lamont sleeps
<infinity> fabbione : Well, I initially called it "cosmic rays", so I'm with you, I'm just hoping it's not "usual".
<fabbione> infinity: usual was highly ironic :-)
<fabbione> infinity: i think we can downgrade 7846
<infinity> fabbione : Or close it.  It's either a real bug or not.  There's not much in between.
<infinity> fabbione : I'm leaning toward "not a real bug", given that no one, including lamont, can reproduce it.
<infinity> fabbione : Or I can dowgrade it and reassign it to lamont, since he really, really wanted to reproduce it.  He may be over that by now, though.
<infinity> lamont : ?
<infinity> Oh, sleeping.  Bah.
<fabbione> infinity: i vote for closing
<infinity> Yeah, me too.  lamont can ressurect it, ie still feels the urge to run 50 test builds in a row...
<infinity> s/ie/if he/
<fabbione> yeah
<infinity> PS: Ubuntu bugzilla + dialup = teh suck.
<fabbione> KILL IT KILL THEM ALL!
<fabbione> i can close it for you, if you want :-)
<infinity> Nah, I closed it.
<infinity> Though, I closed it with "fixed" instead of "notabug", cause I weas so excited about the page loading that I wasn't pttention.
<infinity> paying attention, even.  Wow.  Typing.
<fabbione> ok.. we are down to 7 RC bugs
<infinity> That just means I should file a few more.
<fabbione> actually 6.. one is a security for warty
<infinity> I assume you're just looking at critical bugs?
<mdz> daniels: powerpc didn't ask me any X questions on install, and it should have
<daniels> mdz: define 'should have'
<daniels> amd64 live and reconfigure asked me about the resolution
<mdz> daniels: hoary-install-powerpc.iso
<daniels> yes
<fabbione> infinity: yes, only critical or higher
<mdz> daniels: "should have" as in "always has, and it's correct to, because there's no way it could possibly know"
<daniels> but when you say 'should have'
<daniels> failing ddc probe?
<mdz> yes
<mdz> it just dropped me into 1024x768 with no question
<daniels> if you run sudo dpkg-reconfigure -phigh xserver-xorg, does it ask you?
<mdz> yes
<mdz> (as it did on the live CD, which does the same thing)
<daniels> ok
<daniels> you win the grand prize of getting to repack the powerpc install cd
<daniels> either that, or punting a custom build
<daniels> right, I think I see it
<fabbione> daniels: stop smoking crack.. you can't see it :P
<daniels> mdz: davis:~daniels/xorg/repack/xserver-xorg_6.8.2-6_powerpc.deb
<mdz> I don't have an account on davis
<mdz> hmm, apparently I do, only nobody told me
<fabbione> mdz: everybody does..
<fabbione> mdz: it's a porting box
<mdz> daniels: didn't you tell me that failed ddc was one of your test cases?
<daniels> mdz: yes, but I didn't try a fresh install
<mdz> ...
<daniels> mdz: it's a one-line fix, if you repack the cd with the new deb it should be fine
<mdz> daniels: I don't know the mkisofs arguments to rebuild powerpc
<mdz> first hour of testing, only three show-stopper bugs found
<mdz> looking pretty good
<mdz> apparently, remastering powerpc requires a copy of some file out of debian-cd
<mdz> hfs.map
<daniels> mdz: would you like me to kick a custom build for you?
<mdz> might as well, I'll re-test tomorrow
<daniels> huh
<daniels> well, I can't SSH into little anyway
<daniels> so it's up to you to kick the build
<mdz> doesn't matter
<daniels> daniels@catsby:~% ssh little.warthogs.hbd.com
<daniels> Password:
<mdz> I'm done for tonight
<fabbione> mdz: good night
<fabbione> mdz: anything specific you want me to look into while you are asleep?
<mdz> fabbione: working X, working archive-copier and working apt-setup-udeb
<mdz> those are all show-stoppers
<daniels> mdz: well, whenever you get up, put that deb in /srv/cdimage.nny.c/local/packages, and run DEBUG=1 ARCHES=powerpc LOCAL=1 LOCALDEBS=/srv/cdimage.no-name-yet.com/local/packages cron.daily
<mdz> Kamion will be up many hours before I will
<daniels> and you'll get an image under /srv/cdimage.nny.c/scratch/cdimage/
<fabbione> mdz: ok.
<mdz> daniels: it seems unlikely to me that this should be architecture-specific. is it?
<daniels> mdz: no, it is not
<mdz> daniels: then you can test locally
<mdz> wihch will be much faster and not depend on anyone
<daniels> yes, with hoary-install-amd64.iso currently sitting at 43% on the rsync
<mdz> when was the last time you rsynced it?
<daniels> looks like i jigdo'ed it last time
<mdz> when was that?
<daniels> i have an rsynced *i386* iso, but fat lot of good that's done me
<daniels> eleven days ago
<mdz> that should work fine
<mdz> turn off your monitor
<daniels> yeah, I'm sure I'll find some way to work it out
<daniels> goodnight
<fabbione> YAY! linux-image-2.6.10-5-386-xen0_2.6.10-32_i386.deb
* ogra applauds
<crimsun> very nic
<crimsun> e
<fabbione> there is still clean up that needs to be done
<fabbione> :(
<Mithrandir> hi fabio
<fabbione> hey Tollef
<jbailey> Anyone know of a 'diffdiff' program that will show the differences between two diffs, but take into account that the files might appear in the diff in different orders?
<pitti> Morning
<pitti> jbailey: interdiff
<pitti> mdz: okay to upload netkit-telnet into hoary? (security update)
<pitti> i. e. how cold is the freeze ATM? :-)
<jbailey> pitti: Thanks.
<pitti> jbailey: (in patchutils)
<jbailey> pitti: <jbailey> mdz: Cool.  Are we in a no-upload zone now, then?  <mdz> jbailey: we're in a be-careful-dammit zone :-)
<fabbione> jbailey: interdiff?
<infinity> pitti : Speaking of security, got any more for me?
<jbailey> Mmm.  patchutils seems like one of those things I would've traded critical body parts of in the past.  *sigh*
<jbailey> s/of/for/
<daniels> editdiff is rather neat
<Mithrandir> jbailey: you haven't heard of patchutils before?
<infinity> You've never used it before?
<Mithrandir> daniels: emacs does it natively.
<infinity> lsdiff and filterdiff, in particular, are my friends.
<jbailey> Mithrandir: Erm, I've done all my patch editting by hand in vi.
<jbailey> I've gotten quite good at it.
<daniels> Mithrandir: yeah, often I prefer not to use editdiff
<Mithrandir> jbailey: you masochist.
<Mithrandir> :)
<infinity> I still do a lot by hand, but sometimes automation is nice.
<daniels> only when I'm actually adding lines to 30-hunk diffs
<fabbione> jbailey: ehhehe that reminds me so much of all the forwardport of all the xfree86 patches to xorg :)
<daniels> usually I'm fiddling patches to apply cleanly :)
<infinity> I fix offsets by hand, and kill individual hunks by hand, s'about it these days.
* fabbione fixes some rejects too
<infinity> Oh, that too.
<Mithrandir> infinity: M-K kill a whole file in emacs' diff mode.  Quite useful when you don't care to forward-search and such.
<daniels> d/^---
<infinity> Mithrandir : filterdiff does the same thing.
<infinity> But with filterdiff, I can do shell globbing.
<infinity> To, say, remove all instances of libtool.m4 from a diff, etc.
<fabbione> DIE
* jbailey falls over dead.
<fabbione> i won't be able to burn images for a while
<jbailey> fabbione: And I'll tell Angie that it's your fault.
<fabbione> my local mirror just lost a disk
<fabbione> jbailey: ehhe
<daniels> agh
<jbailey> Oh ouch.
<fabbione>       [>....................]   recovery =  0.3% (466488/117220672) finish=505.4min speed=3847K/sec
* fabbione sighs
<fabbione> it will take the usual 2938298932832 hours to rebuild
<infinity> Sure, but it's transparent.
<fabbione> infinity: it is not performance transparent, when i have to burn the iso's from that raid via nfs
<infinity> Picky, picky.
<infinity> You get to complain about your slow RAID rebuilding when you replace my craptop with something built in the current century.
<fabbione> infinity: my laptop is from the previous century too.. so shut up 
<fabbione> :P
<HrdwrBoB> my laptop and raid are both fro the previous century
<jbailey> lamont: Ping?
<fabbione> this raid is at least 4 years old....
<fabbione> jbailey: lamont crashed a couple of hours ago
<jbailey> Ah bugger.  I had missed his going away message.
<jbailey> Oh well, he said it was okay if he wasn't awake.
<daniels> fabbione: your laptop is way, way, way, way, way, way better than infinity's
<fabbione> daniels: ehhee
<fabbione> jbailey: if you plan to upload udev, you have to wait for lamont
<fabbione> i am not sure he did put udev on hold inside the buildd chroots
<fabbione> if he didn't the buildd's will go banana
<jbailey> Ah shit.
<jbailey> I hit go already.
<fabbione> oh well
<fabbione> let's cross the fingers :)
<jbailey> His line after telling him said that it was okay as long as nothing dep'd on the new version.
<jbailey> There's no reason for anything to do so.
<fabbione> than it should be fine
<Mithrandir> any ppc people with a hfs filesystem around?
<Mithrandir> I have a patch 7936, but would like to test it on a powerpc system, not just AMD64
<jbailey> Mithrandir: I don't have an hfs partition, but I imagine that I can probably create on on a loopback.
<Mithrandir> I guess just being on powerpc should be enough
<jbailey> Mithrandir: What do you need?  I need to go pass out soon.
<infinity> daniels : Do you have a (resonably) current hoary i386 install CD?
<infinity> daniels : And have you sorted out your burning issues? :)
<daniels> infinity: 'reasonably', and yes
<Mithrandir> two seconds, I just need to clean the patch of auto cruft
<infinity> daniels : warty blows up pretty spectacularly on my craptop, so I still haven't done much with that hard drive.
<daniels> infinity: i mean, i just burnt my last, so i need to head up to safeway and get a new lot
<daniels> ah
<Mithrandir> jbailey: http://err.no/patches/hfsutils-no-extern-int-errno.diff ; could you apply that and check whether hfsutils still works?
<jbailey> Mithrandir: Erm, extern int errno was causing the linker to segfault?
<jbailey> That's nasty.
<infinity> daniels : The more current, the merrier, I guess.  If my laptop is finding obscure bugs, I may as well file/fix them while I'm at it.
<Mithrandir> jbailey: yes.
<Mithrandir> jbailey: there's a patch for it, but I was told of it a bit too late in the release cycle, so didn't push it in.
<jbailey> Mithrandir: I didn't try it without the patch, but with the patch, it builds fine.
<Mithrandir> jbailey: I'm just as much interested in whether it still seems to work. :)
* ogra yawns
<jbailey> Mithrandir: I have an hfs partition on a loopback now.  Do you know these tools at all?  It would help if you can tell me what to test.
<infinity> Yeargh.  doko, doko, doko...
<Mithrandir> jbailey: no, no idea, really.
<jbailey> =)
<Mithrandir> jbailey: but I'm afraid Kamion will torture and kill me if I break some powerpc stuff because hfsutils was to build on amd64. :)
<jbailey> Mithrandir: hmount and hls appear to work.
<infinity> daniels : Maybe we could hook up for abite to eat and CD handover? :)
<jbailey> Mithrandir: As does hmkdir, hcd, and hpwd
<jbailey> Mithrandir: My guess is you're good to go.
<daniels> infinity: today?  tomorrow?
<infinity> daniels : Whichever.  I do need to eat sometime today, so today would be cool.
<daniels> infinity: i assume you're on zone 1-only, so I'd need to make my way into Monash
<infinity> daniels : 1-only, yeah.  We could eat in town.  (I'm at home right now... No MOnash til tomorrow)
<Mithrandir> jbailey: ok, thanks.
<daniels> infinity: oh
<infinity> daniels : Also, Zofia kept asking all weekend when we'd hang out again.  I think she likes you.
* jbailey wanders off to bed.
<fabbione> night jbailey 
<daniels> infinity: heh :) can't blame her
<infinity> daniels : She's easily led astray.
<daniels> infinity: i need to see xorg 6.8.2-7 through or i'll be flayed to death, so is later good for you?
<infinity> Later's cool.  Work is more important, obviously.  I'm just doing some low-bandwidth, text-editor-only package hacking today, waiting on tomorrow for other stuff.
<daniels> cool
<daniels> say about 8:15ish in city?
<daniels> actually, shit
<infinity> Not so sure about the shit.
<daniels> hm, yeah, 8:15ish is doable
<infinity> Yup, we can do 8:15.
<infinity> Clocks?
<daniels> rad
<daniels> if you're up for ~$16/main, there's a sensational japanese place right near it
<infinity> Zofia'll be cool with that.
<fabbione> "You can have all the faith in your hardware that you want, but Murphy has enable/root." <- lol
<daniels> infinity: phat
<dholbach> gooood morning
<infinity> daniels : Kay, I'm hanging up the modem.  We'll see you there.
<daniels> infinity: rad.  take care.
<Mitario> hello everyone
<ogra> morning dholbach 
<ogra> mdz, ping
<pitti> Kamion: here?
<ogra> hi pitti 
<pitti> Hi ogra 
<ogra> Kamion, was up until 4:30 i think....might sleep
<pitti> oops
<pitti> ok
<ogra> err 3:30 UTC
<thom> mdz: almost certainly yes (LIDSTATE being clobbered)
<thom> mdz: and, auto torrent is happening this am
<fabbione> hey thombot
<daniels> morning thomarse
<thom> morning, y'all
<thom> lamont: apache2 is all infinity's fault
<ogra> hey thom 
<pitti> Hi sivang 
<sivang> hey pitti 
<pitti> Hi seb128 
<seb128> hey hey pitti :)
<dholbach> hey seb128 
<seb128> hi
<dholbach> seb128: just an hour after you left, i wanted to ask you something, but now i forgot
<seb128> erf
<seb128> mdz, Kamion: around ?
<dholbach> seb128: ah yes... what about gnome-vfs-extras? is it needed or in any way useful?
<seb128> no, that's deprecated
<seb128> merged in gnome-vfs2
<dholbach> seb128: kamion left at 4:30 (our time)
<dholbach> seb128: can we chuck it out? because it doesnt build anymore?
<seb128> $ apt-cache show libgnomevfs2-common | grep Conflicts
<seb128> Conflicts: gnome-vfs-extras2, gnome-vfs-sftp, nautilus (<< 2.7.2), libgnome2-0 (<< 2.8.0-5), gnome-panel (<< 2.9.2)
<seb128> you speak about the GNOME 1 version ?
<seb128> $ apt-cache rdepends gnome-vfs-extras
<seb128> gnome-vfs-extras
<seb128> Reverse Depends:
<seb128> 
<thom> seb128: the gtk theme fixes in firefox yesterday are overridden in ephy already, btw
<seb128> just drop it
<dholbach> i speak about http://people.ubuntu.com/~lamont/buildLogs/Test/g/gnome-vfs-extras/
<dholbach> ok
<dholbach> seb128: thanks
<seb128> thom: yeah my epiphany works fine again, thanks
<seb128> dholbach: np
<GheRivero> good morning!
<seb128> dholbach: 
<seb128> xpat2 (1.07-8ubuntu1) hoary; urgency=low
<seb128>  .
<seb128>    *
<seb128> nice changelog :p
<ogra> heh
<Jeeves_> Morning
<dholbach> ARG
<dholbach> *CRY*
<dholbach> i leave now... go to bed... to the bar anywhere *HOLLER*
<seb128> :)
* seb128 kicks pitti
<pitti> ouch
<pitti> ?
<seb128> so you no -fr on ia64 ?
<seb128> :)
<seb128> s/you//
<pitti> seb128: no -de either
<ogra> dholbach, nooo, you need to stay and keep me awake with funny changelogs ;) 
<pitti> seb128: within the last few days, some hog was placed onto the CD obviously
<seb128> pitti: that's not an excuse for no -fr :p
<pitti> seb128: I'd be glad to add those langpacks again :-)
<seb128> BTW just kidding, but that's weird, I don't know half of the locales in your list :)
<dholbach> ogra: i seemed to have cared more about a building package than a nice changelog
<ogra> heh
<seb128> pitti: BTW when have you planned to update the language-packs ?
<pitti> seb128: around noon, but I need to check with Kamion
<seb128> k
<seb128> so I'll update the desktops components today
<pitti> uh, for RC?
<seb128> do I need to get an approval from somebody to upload today ?
<pitti> yes
<seb128> grrr
<pitti> Kamion or mdz
<pitti> seb128: see mdz's mail
<seb128> I know
<daniels> pitti: or jdub
<seb128> but I've pinged 1 hour ago
<seb128> and neither of them care to pong
<seb128> I'll just go ahead :)
<seb128> pitti: why not for RC ? :) There are just translations updates
<pitti> oh, then it's probably okay :-)
<seb128> I want to include the strings from the bugzilla bug
<pitti> ah, that'd rock 
<seb128> BTW have you contacted DV
<seb128> this gamin bug really sucks and it's not likely to be automagically fixed upstream for hoary
<pitti> no, not yet
<pitti> family kept me busy over the holidays...
<dholbach> yeah... someone contact DV to sign herve's key *grmbl*
<pitti> and telnet...
<ogra> hey, why do you guys upload all the time...?
<Mithrandir> ogra: to saturate your network connection.
<dholbach> hehe Mithrandir: exactly
<seb128> pitti: np, if you can do that this week would be nice :)
<Mithrandir> ogra: specially for you, my friend.
<Mithrandir> also, the buildds need to exercise.
<seb128> pitti: I don't get the bug easily here
<pitti> seb128: sure, this whole stuff really sucks ATM
<ogra> Mithrandir, i have had another nice hacking night and am only awake to get approval :)
<dholbach> seb128, ogra: i hope next changelog is better
<seb128> ie: I've it sometime, but if I start all in debug mode I can wait hours without getting it again
<ogra> dholbach, yeah, be creative ;)
<Mithrandir> ogra: crazy person.
<ogra> hehe
<dholbach> ogra: mail him your phone number and go to bed :-)
<seb128> dholbach: bah, don't worry, that's just weird to have an empty one :p
<ogra> dholbach, nah, i wanna have the fun to see the build failing short before RC ;)
<dholbach> hahahaha
<dholbach> seb128: i don't even know how i managed it, to have it empty... even after just 4 hours of sleep
<seb128> bah, 4 hours is a normal night, isn't it ? :)
<ogra> heh
<dholbach> yeah
<Jeeves_> Anyone with a rsync server that I can Rsync?
<Jeeves_> archive.ubuntu.com/ubuntu is @max connections
<fabbione> Jeeves_: there is a list of mirrors on the wiki
<Jeeves_> fabbione: I can just use any of them.
<Jeeves_> Oki :)
<daniels> ross: dude!
<ross> daniels: hey!
<daniels> ross: how was your trip?
<ross> ROCKING
<seb128> hey hey ross
<daniels> rad :)
<ross> hi seb128 
<thom> ross!
<ross> thom!
<thom> you had fun, then?
<ross> oh yes
<thom> lots of photos?
<ross> 650
<thom> blimey
<ross> don't you read my blog?
<thom> not today, i haven't
<ross> see http://www.burtonini.com/blog/life/india-2005-03-24-17-41
<ross> and i'll write more at some point...
<dholbach> does someone know whats up with elmo?
<dholbach> is he in holidays?
<daniels> When booting the Live CD (20050329) and selecting the settings shown above
<daniels> somehow X defaults to a Dutch keyboard layout (no one has a Dutch keyboard in
<daniels> The Netherlands...) so US is the correct layout setting. Works in console, but X
<daniels> defaults to NL keyboard layout.
* daniels frowns.
<Jeeves_> What does a NL-keyboard even looks like?
<Treenaks> Jeeves_: get an IBM PC, you can get NL keyboards with those
<Treenaks> but you're right, no sane person uses NL keyboards :)
<seb128> jdub: around ?
<ogra> seb128, bored ?
<seb128> why ?
<ogra> because you cant upload ?
<seb128> I can
<ogra> yes, but you shouldnt
<seb128> I'm updating the translations for the differents desktop packages :p
<ogra> ah
<seb128> translations updates should be fine
<seb128> and Kamion is not around
<ogra> nope
<seb128> and mdz probably sleeping
<ogra> looks like
<ogra> yeah, Kamion
<Kamion> seb128: you were looking for me?
<seb128> yep
<ogra> me too
<seb128> I guess that's ok to upload some desktop stuff for translations update ?
<seb128> ie: just an update of debian/patches/translations
<Kamion> not sure; I guess so
<seb128> that, and the patch from http://packages.qa.debian.org/g/gtk-doc/news/2.html 
* daniels heads out for a while.
<ogra> Kamion, and i'd like to upload a nearly done hwdb-client (with working submission and running (interim) server), mailed mdz already, but i'll fall asleep the next few minutes
<Mithrandir> ogra: catch some sleep, mdz shouldn't be around for a few more hours, I'd imagine.
<Kamion> client/server stuff is high-priority, as mdz said
<Kamion> we need testing of that#
<ogra> so i'm allowed ? i fear i'll sleep to long...
<Kamion> anything we need to be aware of, that might need to be fixed urgently?
<ogra> not on my side...
<Kamion> ok, go ahead then
<ogra> yeah, great, thanks :)
<pitti_live> Hi folks
<thom> hey Kamion 
<seb128> Kamion: and about http://packages.qa.debian.org/g/gtk-doc/news/2.html ? :)
<Kamion> seb128: gtk-doc> so are we having problems at the moment with the wrong jade being used?
<Kamion> thom: morning
<pitti_live> hey Kamion
<Kamion> pitti_live: morning
<seb128> Kamion: not than I'm aware of, but we have issues with ":" (MOTU guys have some FTBFS due to it)
<seb128> do you want to grab both changes from Debian ?
<dholbach> Kamion: the problem can be seen here: http://people.ubuntu.com/~lamont/buildLogs/Test/g/gmime2/2.0.14-2/gmime2_2.0.14-2_20050321-1131-amd64-failed
<dholbach> Kamion: jani worked around it in a fluxbox package or something as well
<Kamion> 'issues with ":"'?
<Kamion> oh, I see
<seb128> rahh
<Kamion> seb128: ok, go ahead
<seb128> the debian page has shifted with today's upload
<seb128> http://packages.qa.debian.org/g/gtk-doc/news/3.html
<seb128> I was pointing this entry in fact
<Kamion> haha, ok
<seb128> both changes or just this patch ?
<seb128> I'm fine with the patch only
<dholbach> thanks
<Kamion> seb128: just that patch; I did wonder why the other one was necessary
<seb128> k
<Kamion> but all the miscellaneous jades confuse me
<seb128> I don't really know about that, but since we have not breakage atm I prefer to not touch it
<Kamion> seb128: right, definitely
<Kamion> seb128: BTW, when you said "some desktop stuff", how much?
<seb128> 5-6 packages
<Kamion> sounds ok
<seb128> just to update the translations with strings from #7370
<Kamion> seb128: actually, surely those are handled by language packs?
<Kamion> oh, but you need to upload in order for them to get into the langpacks, ok
<seb128> that and .desktop files are not handled by language-packs
<Kamion> ah
<pitti> Kamion: what's the deadline for uploading update langpacks?
<seb128> not before my desktop translations updates :p
<Kamion> pitti: I imagine we'll build candidate CDs this evening with the aim of publishing tomorrow
<Kamion> so sometime this afternoon
<Kamion> (understand that that's a deadline I invented just now, but it seems reasonable ...)
<pitti> yeah
<pitti> seb128: can you please ping me if you uploaded everything?
<seb128> k
<dholbach> see you later
<zyga> why does openoffice depend on ia32-libs?
<Kamion> zyga: that's amd64-specific. OOo doesn't work in 64-bit mode, so we ship 32-bit OOo.
<zyga> Kamion: OO is broken in 64bit mode?
<Kamion> zyga: yes
<zyga> Kamion: is that fixable or is this permanent?
<zyga> s/that/this/
<Kamion> zyga: it's being worked on upstream, but it's a LOT of work.
<zyga> Kamion: eh, too bad, thanks :/
<zyga> Unpacking ia32-libs (from .../ia32-libs_0.5ubuntu3_amd64.deb) ...
<zyga> dpkg: error processing /var/cache/apt/archives/ia32-libs_0.5ubuntu3_amd64.deb (--unpack):
<zyga>  error creating symbolic link `./usr/lib32/libGL.so.1': No such file or directory
<zyga> Errors were encountered while processing:
<zyga>  /var/cache/apt/archives/ia32-libs_0.5ubuntu3_amd64.deb
<zyga> root@amd64:/home/zyga # dpkg-query -S /usr/lib32/libGL.so.1
<zyga> diversion by xorg-driver-fglrx from: /usr/lib32/libGL.so.1
<zyga> diversion by xorg-driver-fglrx to: /usr/lib32/fglrx/libGL.so.1.xlibmesa
<zyga> xorg-driver-fglrx: /usr/lib32/libGL.so.1
<zyga> does this mean that ati binary drivers are causing this?
<Kamion> not sure, ask Mithrandir/daniels
<thom> argh, colin walters posting on u-devel. namespace collison, brain damage
<zyga> Mithrandir: ping
<Mithrandir> pong
<pitti> Mithrandir: any chance of packaging thunderbird 1.0.2 for hoary?
<pitti> Mithrandir: otherwise, can you backport the security fix?
<Mithrandir> I can package it, no problem.
<Mithrandir> I'd need approval, though
<pitti> yeah, sure
<zyga> Mithrandir: can you give some insight on what is going on with xorg-driver-fglrx and /usr/lib32/libGL.so.1
<pitti> Mithrandir: I think the best time would be immediately after RC release (if it's approved)
<Mithrandir> pitti: ack
<Mithrandir> zyga: probably a missing divert in ia32-libs.
<zyga> Mithrandir: shoud I file a bug?
<Mithrandir> zyga: I think it's filed already
<zyga> It's a clash between xorg-driver-fglrx and ia32-libs
<Mithrandir> 7542
<zyga> Mithrandir: that's it - nothing new for me to add, thanks
<Mithrandir> I was thinking about fixing ia32-libs for Debian today anyhow, so.
<Seveas> ogra, ping?
<dholbach> Seveas: i hope he's sleeping
<Seveas> :)
<dholbach> Seveas: he had another 28h hacking session
<Seveas> i just wanted to say that the hwdb client works (except for sending)
<Seveas> oof
<dholbach> cool
<dholbach> i'll tell him (once he wakes up ;-))
<dholbach> he'll be delighted to hear
* Seveas is on fglrx, that was the problem yesterday :)
<dholbach> hi elmo, could it be that some builds are "hanging"?
<tseng> hi dholbach 
<dholbach> hey tseng, hey mvo
<mvo> hey dholbach 
<zyga> mvo: hey
<mvo> hey zyga 
<mvo> zyga: I send you some mail, did they reached you yet?
<zyga> mvo: would you accept a patch that extracts changelogs from .debs and shows them to the user for update-manager?
<zyga> mvo: checking
<mvo> zyga: have you seen the bugreport about it ?
<zyga> mvo: yes - and - yes
<zyga> mvo: I agree about string freeze
<mvo> zyga: there is apt-listchanges already that does that, if update-manager gets this feature, we should use that code I reckon
<mvo> zyga: thanks (about the string freeze)
<zyga> mvo: that would make update-manager recommend apt-listchanges
<zyga> mvo: the code that can manualy extract the changelogs is pretty small, are you sure we need another package to do that?
<mvo> zyga: we would have to work that bits out. what's the best stragy. just copying is probably a option
<zyga> copying? the code?
<zyga> mvo: I was also thinking about showing update urgency 
<mvo> zyga: yes, the extracting code (if it is small and easy)
<trukulo> i prefer to show apt-listbugs instead of apt-listchanges (my opinion)
<zyga> mvo: sort by urgency and add some background color for easier information 
<mvo> zyga: the urgency is a nice feature, but it's not really needed for ubuntu. our policy is that we only have security or critical upgrades, so each update has about the same urgency 
<zyga> mvo: too bad :/
<mvo> trukulo: apt-listbugs is nice, but it's written in ruby IIRC
<trukulo> mvo: oh, i didn't know, ok
<trukulo> think it was on python
<mvo> zyga: it's a nice feature to track unstable though, we may think about it
<zyga> mvo: how would we do that? 
<mvo> trukulo: yes ... does the version in ubuntu interface with the ubuntu bugzilla? I haven't used it at all in ubuntu yet :) 
<trukulo> mvo: don't know, i only use apt-listbugs in sid
<trukulo> or sarge, never with ubuntu
<mvo> zyga: using urgency for tracking the ubuntu/unstable release?
<mvo> trukulo: ok
<zyga> mvo: how about opening a branch for breezy?
<Mithrandir> zyga: when hoary is out.
<mvo> zyga: it's only a week :)
<trukulo> mvo: only a week for breezy to be released?
<dholbach> trukulo: wiki/HoaryReleaseSchedule
<pitti> Hi zyga, how's it going
<trukulo> thaks dh
<dholbach> trukulo: no problem, tr ;-p
<zyga> mvo: how about urgency on upcoming realeases?
<zyga> mvo: like hoary is now being updated all the time
<doko> jdub: please could you have a look at #7538? doesn't seem to be OO.o specific.
<mvo> zyga: for breezy, we can talk about new features again :)
<zyga> mvo: this is all for breezy 
<dholbach> to be honest, i liked sneezy better... ;-)
<zyga> hehe
<zyga> dholbach: just don't fork us yet ;] 
<dholbach> zyga: don't worry
<thom> Kamion: just to check, the "torrent" tree on little will get releases and arrays/whatever when they're added, right?
<Mithrandir> mjg59: is nstx known broken on amd64?
<Kamion> thom: yeah
<Kamion> WHOA
<Kamion> so, this archive-copier bug that mdz mentioned
<Kamion> I can reproduce it
<thom> Kamion: cool, thanks
<Kamion> and it turns out that it manifests precisely when the sum of the sizes of all Packages files on the CD is an exact multiple of 4096
<Kamion> THAT WOULD EXPLAIN WHY I NEVER NOTICED IT BEFORE
<thom> that's a great bug, congrats
* zyga hates api changes in libraries of scripting languages, grrr
<doko> zyga: talking about PHP4?
<zyga> doko: I don't use php much so I don't know but I was talking about python
<zyga> standard c library suxx but at least I's stable :P
<dholbach> seb128: thank you!
<seb128> np
<abelli> hello everybody
<pitti> Hi abelli 
<faux_> any chance of getting mono 1.0.6 into hoary final?
<zyga> mvo: ping
<abelli> is mark around?
<Mithrandir> doko: /usr/lib/gcc/x86_64-linux/3.4.4/32/libgcc_s.so points to /usr/lib32/libgcc_s.so.1, which doesn't exist.
<mvo> zyga: pong
<abelli> sabdfl: ping
<HiddenWolf> Is the amd64 install daily safe?
<thom> faux_: about as much chance as microsoft releasing XP under the gpl, i'd suggest
<Seveas> hmm
<Seveas> tough odds...
<abelli> thom: never say banzai. :)
<ross> anyone got a url listing the positions in virtual memory linux puts what types of object? i.e. heap, stack, libs...
<Treenaks> ross: does linux put it there, or ld?
<Seveas> ld does
<Treenaks> Seveas: oh yeah you're the expert :P
<Seveas> :)
<Seveas> i'm searching for my papers, i have a nice figure
<ross> thanks
<Seveas> hmm, ok, you need the text with it
<Seveas> can i send you a document (pdf) by e-mail?
<ross> Seveas: pdf is fine, ross@burtonini.com
<mvo> Seveas: can you put it on a url somewhere? i would be interessted too :)
<Seveas> ok
<Seveas> look at staff.science.uva.nl/~dkaarsem/ckpt/ in five minutes
<Seveas> have to regenerate the pdf and put it there
<mvo> Seveas: thanks
<Seveas> it's on there
<Seveas> http://staff.science.uva.nl/~dkaarsem/ckpt/ckpt_draft.ps
<Seveas> you just have to ignore the ckpt header and ckpt data, than you have the structure of a normal elf binary
<mvo> Seveas: nice, thanks
<pitti> Kamion: still okay to upload trivial fixes (g-v-m)?
<Seveas> mvo, ross, i would appreciate it if the document doesn't get spread all over the internet
<Seveas> it's an early draft :)
<faux_> thom: hehe ok, thanks
<ross> Seveas: ok
<mvo> Seveas: sure
<Kamion> HiddenWolf: no, broken
<Kamion> pitti: what fix?
<doko> mithrandir: hmm, I'll look at it.
<pitti> Kamion: #7725
<pitti> Kamion: just fixing a symlink target
<pitti> Kamion: /usr/lib/g-v-m/g-v-m-gthumb.sh pointed to g-v-m, not to g-v-m-gthumb
<HiddenWolf> Kamion: *sigh* What's the latest amd64 image I can use?
<Treenaks> g3e-v4e-m5r :P
* Mithrandir kicks gconf
<Mithrandir> silly stupid thing.  Stop stomping on my settings.
<Kamion> pitti: yes
<Kamion> HiddenWolf: I think yesterday's is OK, but I haven't checked because I'm too busy fixing it :)
<Mithrandir> seb128: is it intended that gconf should stomp on user settings just because the files in gconf happens to be symlinks instead of files?
<dholbach> bbl
<seb128> Mithrandir: where do you have some symlinks ?
<Mithrandir> seb128: /home/tfheen/.gconf/desktop/gnome/applications/window_manager/%gconf.xml is a symlink to ~/dotfiles/gconf/.../%gconf.xml
<Mithrandir> it seems like the xml backend unlinks the file instead of rewriting it
<seb128> I guess that's not a documented usage :)
<seb128> patches are probably welcome though
<Mithrandir> it's a sane way to keep ~/.gconf in version control
<seb128> bah, the mtime stuff make it changing all the time, isn't it ?
<Mithrandir> if so, I'm going to whack that too
<seb128> look on the file
<Mithrandir> into not changing the mtime unless the node has changed.
<seb128> there is a mtime
<Mithrandir> I know.
<Mithrandir> but gconfd can compare the old and new node and not change the mtime unless the node actually has changed.
<Mithrandir> seb128: why doesn't changing /desktop/gnome/applications/window_manager/current (when gnome is not running) actually change the window manager?  It seems to be overridden back to metacity each time.
<Keybuk> isn't that an unused key?
<seb128> Mithrandir: do you have $WINDOW_MANAGER defined ?
<Mithrandir> seb	no
<seb128> in fact /usr/bin/gnome-wm determine the wm to use
<seb128> and set the key
<seb128> look on the different conditions
<Mithrandir> ah, seems I have to set the default keey
<Mithrandir> s/kee/ke/
<seb128> IIRC it should use current for your user and fallback on default if current is not working
<thom> kamion/mdz: autotorrent madness looks good :_)
<Mithrandir> seb128: it doesn't, it uses default.
<Mithrandir> seb128: at least, that worked for me, and it's according to the docs in gnome-wm
<seb128> something is bogus, I don't get why there is 2 keys
<Mithrandir> seb128: but contrary to the docs in the schema.
<seb128> yeah
<Mithrandir> I guess I'll have to fix the gconf backend too. :/
<pitti> seb128: regarding the "Submit to Ubuntu database..." translation in hal-device-manager; the string is marked as translatable in glade, but it doesn't appear in the pot file
<pitti> seb128: do you know how to extract these strings automatically?
<seb128> bah, don't bother, use my method
<seb128> gedit po/nn.po and copy the msgid msgstr here :p
<pitti> okay :-)
<seb128> gedit or whatever you want but be sure to be in UTF-8 :p
<zul> hey
<fabbione> elmo: ping?
<Kamion> thom: great!
<elmo> fabbione: ?
<fabbione> elmo: sorry i just got a mail from katie i don't really understand: pcsc-lite_1.2.9-beta6-1_sparc.changes UNACCEPT
<elmo> fabbione: don't worry, I'll take care of it
<fabbione> elmo: ok, i won't :-)
<fabbione> elmo: last question, did you have any time to move sparc.u.c? if not, would it be possible to get just one pulse?
<pitti> seb128: darn, h-d-m is not even i18n'ed
<elmo> fabbione: pulsing,  I really will try and fix today
<seb128> pitti: not cool
<Mitario> hi everyone
<fabbione> elmo: thanks a lot, but don't rush. I am more than happy as it is now
<pitti> seb128: that's too invasive, I don't do this now
<Kamion> go apt, it's your birthday
<pitti> seb128: I just updated the .desktop file
<pitti> congrats, apt :-)
<pitti> Kamion: how many years?
<Kamion> pitti: not *really*
<seb128> pitti: k, thanks
<Kamion> pitti: you haven't heard the "go $FOO, it's your birthday" thing going round Canonical?
<pitti> no, I didn't
<pitti> Kamion: was it some special rule in a $NAMEOFOURLEADER game?
<Kamion> pitti: no - it just carries extreme sarcasm and "$FOO is broken"
<Kamion>         PACKAGE_COUNT=$(LC_ALL=C apt-cache stats | grep 'Normal Packages:' | awk '{ print $3 }')
<Kamion> this is particularly helped by apt randomly changing to 'Normal packages:'
<pitti> -i then? :-)
<Kamion> yup
<_mvo_> Kamion: where does this "go $foo ..." come from (originally)?
<Kamion> _mvo_: dunno, it's an elmo-ism I think
<thom> _mvo_: elmo, possibly via 50 Cent
<RShadow> Can I ask a question
<pitti> RShadow: you already did :-)
<RShadow> I have a question about ubuntu policy..
<pitti> RShadow: just go ahead
<RShadow> HostingGeek Umm no
<RShadow> HostingGeek if he has to rebuild
<RShadow> HostingGeek then he also need to rebuild all the packages
<RShadow> HostingGeek as per policy
<RShadow> HostingGeek thats why with 1 change in one of xorg's packages means a new package for each part of xorg
<RShadow> is that ubuntu's policy?
<Kamion> that's not policy, it's how the system works technically
<Seveas> Kamion, is xorg one source package?
<Kamion> Seveas: yes
<pitti> yes
<fabbione> Seveas: yes
<RShadow> So if a new version of evolution is released .. then the entire gnome tree has to be rebuilt
<Kamion> RShadow: er, no
<Kamion> RShadow: uploads happen in units of source packages
<Kamion> RShadow: evolution is a different source package from the rest of GNOME
<Seveas> cool, i'm starting to understand apt :)
<Kamion> but libx11-6 is in the same source package as xserver-xorg, say
* RShadow is confused
<Kamion> RShadow: just FYI, HostingGeek is not what you might call an expert on Ubuntu policy
<RShadow> Kamion: I know .. he has been lying to me for like 45min now
<RShadow> Kamion: I just wanted to bust him some more
<Kamion> Seveas: it's not apt, it's the archive management system, plus (a) things like GPL requirements to have source matching binaries, (b) sanity
<Seveas> ah, thats right yeah
<Seveas> and the sanity argument is definitely right :)
<Kamion> (b) is more important really, we really don't want to have binary packages lying around that we can't rebuild, it just gets silly
<fabbione> Kamion: do you want me to see if 7906 is reproducible?
<fabbione> acutally i can test 8287 too
<Kamion> fabbione: no, I know why #7906 is happening and I'm sure it's reproducible
<RShadow> not to be a bother more .. but is there a xdirectfb package for ubuntu?
<fabbione> Kamion: ok, what about 8287?
<Kamion> fabbione: yes, that would be useful
<fabbione> it means installing Xp, but it is for a good cause ;)
<Kamion> RShadow: not as far as I know
<fabbione> Kamion: ok, i will finish the standard i386 install and test that
<kagou> hi
<fabbione> Kamion: btw.. i have xen kernels ready to test. Perhaps we should take a look at UDU if we can use them for d-i testing
<Kamion> fabbione: the problem's always been that requiring a different kernel means you have to do a separate build of d-i with different sets of module udebs, which means that you invalidate testing of a lot of the things that can actually break d-i
<fabbione> Kamion: good point..
<Kamion> but I mean sure, more testing's always useful, I just don't think it's a substitute for real testing, and especially with automatic installations you can get even more benefit with the same amount of automation from testing on real hardware :-)
<Kamion> s/real testing/real hardware/
<fabbione> no it's not a substitute for real hardware when it goes to hardware detection, but it can be useful to test generic code
<thom> Kamion: did you ever look into the testing plan stuff?
<Kamion> thom: no, sorry :(
<Kamion> fabbione: yeah, that's true
<thom> Kamion: heh, damn. i was hoping to be able to steal something for the server testing stuffs
* fabbione comes from the E/// test department and really doesn't want to go back there
<fabbione> thom, Kamion: i really know the pain you are going trough
<thom> fabbione: well volunteered; i want to see your work by the end of school today!
* thom ducks
* fabbione hugs and licks thom on the face
<fabbione> Kamion: apt-setup udeb goes banana here. all the screen is cluttered with tons of stuff
<fabbione> but it seems to work tho
<Kamion> fabbione: I'm fixing some stuff, and also it's known-broken in that way for some types of installs (server, iirc)
<Kamion> the output's harmless
<fabbione> i am not there yet in testing.. still doing the normal one
<fabbione> Kamion: the standard install is asking for the CD in stage 2
<fabbione> :(
<lamont> moo
<fabbione> hey lamont 
<pitti> Hi lamont
<lamont> fabbione: shame on you scaring jbailey that way. :)
<zul> hey lamont 
<fabbione> lamont: ehehhe
* fabbione is a true bastard inside
<lamont> morning zul, pitti
<fabbione> and outside.. i have to admit i am improving
<jbailey> lamont: Actually, him telling me that the buildds went nuts at least let me know that it was the udev-in-chroot issue that you were worried about. =)
<lamont> jbailey: heh
<Kamion> fabbione: was this a netboot install?
<fabbione> Kamion: no, cd install, but there are problems in phase2 too. checking now
<Kamion> fabbione: odd, well I'm fixing the apt-setup spamming the screen problem now, but who knows what consequences the broken apt-setup/another question might've had
<fabbione> it is installing some extra packages from CD that were not copied to the hd
<fabbione> i wonder if that's related to archive-copier problem mdz was talkign about this morning
<Kamion> which ones?
<Kamion> the archive-copier bug was as far as I know specific to amd64 (although only by chance)
<Kamion> I doubt it's related
<Kamion> (I've fully analysed and fixed it already)
<fabbione> ok it's the media that sucks
<fabbione> I/O error
* lamont back in a few
<Kamion> thom: could you look at why rookery's mirror is so badly out of date? it's starting to become a real problem for sanity of germinate output and things
<thom> Kamion: sure, looking
<Kamion> thanks
<elmo> don't bother, I'm working on it
<thom> oh, k
<elmo> kamion: it's the same reason I explained to you last week...
<Kamion> elmo: mirnyy's load issues? I thought those had been fixed/worked-around
<elmo> kamion: no, mirnyy not being archive.u.c anymore
<Kamion> oh, so it was just mirroring from an out-of-date place?
<elmo> yes
<mvo> Kamion: I'm doing a test-install right now and got a strange question ". Hoever, you may want to add another source to apt, so it can ownload from more than one location.". is this a known problem? (it's not translated and the leading "." looks wrong)
<Kamion> mvo: yes, known, fixing
<mvo> Kamion: thanks
<elmo> Kamion: btw, mirror stuff is still asking random extra questions on netboot
<Kamion> the leading "." is a debconf bug I think, but it doesn't matter because I'll be making that question go away again except in expert mode
* fabbione loves Kamion so much to install XP on a test machine
<Kamion> elmo: yeah, I know :(
<Kamion> haven't figured out exactly what I need to do to fix that
<Kamion> mvo: this is what I was talking about above, with apt changing the capitalisation of "Normal Packages:" in apt-cache stats
<mvo> Kamion: matt applied a patch that changes some capitialisation recently :(
<mvo> in 0.6.35 IIRC 
<Kamion> mvo: yes, that's what did it
<maswan> elmo: psst. mirror pushes to se.archive? or should I start cron-mirroring again?
<elmo> maswan: releases or archive?
<maswan> elmo: archive. currently I'm updating manually when I think I need new packages for my laptop. :)
<elmo> maswan: please cron.mirror - I haven't worked out the details of how often/when to trigger archive mirrors
<maswan> elmo: Ok.
<elmo> Kamion: btw, please trigger frei.ubuntu.com for cdimage/releases pulses
<Kamion> elmo: done
<Kamion> elmo: any I can remove from the current list? (syncproxy, auckland, mirnyy, frei, orcadas)
<elmo> Kamion: do you have separate triggers for releases/cdimage/torrent?
<Kamion> elmo: no
<elmo> then, no not really
<Kamion> ok
<elmo> well, you could drop auckland actually
<elmo> might as well break people using archive.u.c/cdimage/ now
<Kamion> hmm, good idea
<Kamion> elmo: done; I guess nuking archive.u.c/cdimage/ altogether would be best so that people don't get confused by out-of-date stuff
<elmo> yeah, I'm about to 
<elmo> pitti: what were those mozilla packages you wanted removed?
<pitti> elmo: mozilla-firefox-locale-{de,es-ar,es-es,pl,pt-br}
<elmo> pitti: hmm, ok, thats not what I was hoping ;)
<elmo> pitti: there's a bunch of uninstallable mozilla-locale packages - don't suppose you'd care to have a look? ;)
<pitti> ah, these
<pitti> elmo: gimme a minute
<pitti> elmo: we need syncs for mozilla-locale-{da,it,ptbr}
<thom> anyone want to admit to owning a printer? if so, can you reproduce 8342?
<elmo> pitti: can you do the usual mail-for-approval dance?
<pitti> elmo: already approved
<pitti> elmo: these are quite old
<elmo> pitti: msg-id or on IRC?
<pitti> elmo: by mail
<pitti> elmo: Message-ID: <20050320170222.GQ17070@alcor.net>
<mvo> thom: works for me(tm)
<thom> i think he's upgraded and not restarted
<thom> mvo: thanks
<elmo> pitti: all I have is this mail from you about this sync, not that msg from matt
<elmo> (not that it matters now, but FYI)
<elmo> Kamion: rookery's syncing now and should be able to sync from now on
<elmo> how often did you wanted it synced?
<Kamion> elmo: every six hours, say?
<Kamion> that should satisfy my AWTY needs ;)
<Kamion> but more seriously should be enough for translation updates at least
<elmo> pitti: also mail ssays de-at too - still need that?
<thom> and changelogs too i suppose
<Kamion> oh, changelogs runs on rookery?
<mvo> thom: changelogs++
<elmo> yes
<pitti> elmo: de-at is obsolete now, you can ditch it
<pitti> elmo: no, please wait, this was for ffox
<pitti> elmo: right, we need that too
<elmo> daniels: ? [in the right chan] 
<elmo> kamion/mvo/anyone else who cares: ok, done, at 4,10,16,22 :15
<mvo> elmo: thanks!
<Kamion> elmo: great, thanks
<elmo> Kamion: at some stage we should switch little over to using sync-proxy too, but ICBA ATM
<Kamion> elmo: nod
<elmo> xfree86-driver-fglrx
<elmo> ^-- looks to be the last remaining uninstallable in main
<Seveas> elmo, isn't that fglrx-driver?
<elmo> oh and the -dev too
<elmo> Seveas: dunno
<Seveas> on warty it was fglrx-driver, on hoary xfree86-driver-fglrx, sorry
<fabbione> elmo: afaik these 2 packages are there only for people that still want to run xfree86
<fabbione> elmo: it should be safe to move them to universe
<fabbione> elmo: where the xfree86 server is
<fabbione> + they are in restricted, aren't they? they can't be in main
<Kamion> multiverse not universe
<Kamion> I've asked for that demotion a couple of times but I guess it got lost
<elmo> ah, sorry, guess so
<elmo> demoted now
<jani> elmo let me know when you can be bothered with sync requests and keyring administrivia, thanks
<Kamion> https://bugzilla.ubuntu.com/attachment.cgi?id=1911 -> hm, I wonder how I'm supposed to debug this
<fabbione> Kamion: ask lamont :-)
<Kamion> fabbione: ELANG - this is Chinese
<fabbione> oh
<elmo> right auckland's no longer serving cdimage or releases
<fabbione> ask Herbert?
<elmo> if anyone complains, please point them at the right CNAME
<fabbione> elmo: so i guess archive.u.c doesn't serve cdimages anymore?
<elmo> fabbione: yes
<elmo> s/auckland/archive/
<fabbione> ok
<Kamion> fabbione: it's not a problem of understanding the language, just "random characters go missing"
* fabbione wonders why XP reads from CD to "Save settings"
<fabbione> Kamion: all this torture just for you :)
<fabbione> it rebooted already into phase 2^64
<lamont> Kamion: obviously missing some utf-8 glyphs
<lamont> fabbione: and that's chinese, not japanese... :)
<Kamion> lamont: yeah but the question is why Debian's OK
<doko> kamion, mdz: please could you review a python2.4 upload (chinstrap: ~doko/python2.4-debdiff)
<lamont> Kamion: little green men?
<lamont> aka, nfc
* lamont would start with (1) comparing the translations, and (2) seeing what fonts are loaded in each
<Kamion> doko: have you tested a debootstrap with that version?
<doko> hmm, maybe I should, although it installs, the integrity check shows no additional modules.
<Kamion> doko: just worried about extra deps and stuff
<Kamion> you said extra bluetooth functionality was added to socket; won't that pull in libbluetooth1?
<Kamion> doko: apart from that, ok
<doko> kamion: no, only some constants from the bluetooth headers are added to the socket module
<Kamion> doko: ah, ok
<elmo> pitti: fr, it and ptbr are still br0ken
<pitti> elmo: mozilla or ffox?
<pitti> elmo: oh, I see
<Jeeves_> Ehm,     SMTP error from remote mailer after RCPT TO:<mirrors@canonical.com>:
<Jeeves_>     550 <mirrors@canonical.com>: Recipient address rejected:
<Jeeves_>     User unknown in virtual alias table
<elmo> meh, is that address still on the webpage?
<elmo> I swear I've edited it a hundred times
<Jeeves_> So where should I report my mirror? :)
<elmo> Jeeves_: mirrors@ubuntu.com
<Jeeves_> Ack
<Jeeves_> Done
<doko> kamion: debootstrap succeeded
<pitti> elmo: can you please sync m-l-fr as well?
<Kamion> doko: ok, go ahead
<Kamion> thanks
<daniels> elmo: represent
<elmo> daniels: sorry, doesn't matter
<daniels> rad
<daniels> but while you're at it, could I please get access to little back?
<elmo> pitti: ok, done
<pitti> thanks
<doko> kamion: uploaded
<elmo> if that installs, we're down to: kdesdk and mozilla-locale-{ptbr,it} as uninstallables
<fabbione> elmo: kdesdk is also FTBFS :)
<doko> elmo: please could you sync python2.3 from unstable (same locale.py patch as in the python2.4 upload)
<fabbione> it needs kdewebdev from universe
<elmo> fabbione: I know, riddell's aware
<fabbione> rocking
<elmo> doko: was the python2.4 upload approved?
<pelle> is paul sladen still working on usplash?
<jbailey> pelle: I don't think so.
<Mithrandir> elmo: could you please sync guifications from unstable?  (universe package, not in ubuntu, afaik)
<pelle> jbailey: ok. is anybody else doing that?
<jbailey> pelle: Daniel Stone and I looked at it briefly, but it's defered until breezy.
<pelle> jbailey: do you have a repository for it?
<jbailey> pelle: Nope.  We didn't get beyond reviewing really what would need to happen in what piece.
<pelle> jbailey: ok, thanks
<elmo> Mithrandir: done
<doko> elmo: 16* ^^
<Mithrandir> elmo: thanks
<doko> elmo: yes
<Mithrandir> daniels: xserver-xorg _still_ asks loads of questions on upgrades.
<elmo> doko: 2.3.5-2, yah?
<daniels> Mithrandir: bah, impossible.  which version?
<elmo> doko: if so, done
<jani> elmo, could you sync darcs from unstable (universe)?
<doko> elmo: thanks
<elmo> jani: done
<daniels> Mithrandir: if you could unpack the deb, repack it with postinst and config modified to use sh -x, and send me the output, that would be fantastic
<daniels> doubly so if you use DEBUG_XORG_PACKAGE=verbose
<daniels> or =developer, whichever
* daniels -> zzzz
<Mithrandir> daniels: I'll do that.
<jbailey> Hmm, apparently there are limits to the number of computers I can plug into a breaker. =)
<thom> bloody hell how big is kdepim; seems like i've been mirroring it for hours
<daniels> Mithrandir: cheers
<daniels> thom: hoooooooge
<daniels> thom: the problem with kdepim is that they were sharing lots of code between kmail et al and lots of kdepim components
<daniels> thom: so rather than make another component for a common library, kdepim subsumed kmail and friends
<thom> holy mother of god thats CRACK
<daniels> it makes sense from the point of view of having a big monolithic tree anyway
<thom> as far as that makes sense, sure
<elmo> hmm, I've ended up with no /.dev and /dev symlinks pointing to /.dev.  yay
<elmo> including initctl
<elmo> double yay
<Mitario> hi guys
<abelli> ciao
<dholbach> hai
<mvo> hey dholbach, wb
<lamont> mdz around?
<lamont> for that matter, any ppc-possessing people with a little time on their hands?
<thom> lamont: sure
* elmo whispers 'davis' at lamont
<lamont> elmo: it's a runtime bug
<lamont> :-)
<elmo> X forwarding! ;)
<thom> elmo: sicko :-)
<fabbione> yeah right
<thom> lamont: 'sup?
<elmo> thom: it's only streaming video
<elmo> what could possibly go wrong?
<lamont> thom: if you're in the mood:  grab kino_0.75-6, edit debian/control (remove libavcodec-dev from build-dep), edit debian/rules (remove --with-avcodec), build it, and see how much of 5379 you can reproduce
<Kamion> lamont: ah, figured out the Chinese font thing
* Kamion decrements bubulle's beer count ;)
<lamont> Kamion: what was it?
<lamont> elmo: do you have any idea how much it hurt when I fire up mozilla with a remote display?
<Kamion> lamont: the switch from languagechooser to localechooser included a change from using anna-install to get bterm-unifont to using apt-install instead - but bterm-unifont's a udeb, so anna-install really was needed
<elmo> lamont: dude, that's how I access iLOs on *.d.o :-P
<Kamion> bterm-unifont is the non-reduced font used as soon as more than just the bare initrd is available
<lamont> iLO?
<elmo> transatlantic mozilla == pain, mmk
<daniels> elmo: pussy
<Kamion> it was figuring out that it looked different in CD-ROM and netboot installs that did the trick
<elmo> lamont: i<mumble>Lights Out, remote management cards on HP servers
<lamont> elmo: yeah, but I'm shaped to 256kbps...
<daniels> full kde session over dialup == fun
<daniels> elmo: integrated?
<elmo> daniels: that's it
<lamont> daniels: in the same way that the chinese water torture is "fun" to experience?
<daniels> lamont: (this was when I was maintaining kde but didn't have the diskspace to build kdebase from kde3 at home)
<lamont> note to channel: Kamion can debug chinese problems.  Send him your wierd crap.
<lamont> daniels: ouch
<lamont> thom: the question on 5379 is do we (a) remove the build-dep and down grade the bug, (b) remove the build-dep and close the bug, or (c) see about promoting libavcodec-dev to main...  (b) would be ideal, but I suspect (a) is the conclusion we'll reach
<lamont> hrm.. speaking of which, I should go fetch iso's in a short while.
<Kamion> lamont: screw you, hippy :-)
<lamont> Kamion: any fresh CD builds planned, or can I presume they'll stay staic for a bit...
<Kamion> lamont: another one this evening; not too many changes though
<lamont> Kamion: woot
* lamont LOL at 'fetch isos... screw you"
<daniels> elmo: can't you get a serial console over telnet with ilo?
<koke> elmo: is my key already added to keyring??
<lamont> daniels: i==internet --> web, of course.
<elmo> daniels: yeah, but some features (particularly remote setup/config changes) requires a browser
<koke> I've been offline for some days and I don't know much about the progress...
<Kamion> lamont: not the intended sequence ;)
<daniels> elmo: right
<elmo> koke: I've been offline with easter weekend too, I'll go see where we're upto with the new MOTUs in a bit
<lamont> Kamion: that's what made it so damn funny
<mvo> Kamion: test-install went fine BTW on i386 (modulo the problem you already know about in stage1)
<daniels> lamont: er, you can feed it xml-rpc stuff to control most everything without needing a browser
<lamont> daniels: ok
<daniels> ilos are love
<koke> elmo: ok, I don't even know if mako has sent you the neccesary data
<daniels> part love and part crack, but that's ok.  it's the good crack.
<lamont> daniels: crack-love?
<daniels> love the crack
<daniels> g'night kids
* lamont watches the channel tail-spin
<lamont> g'night daniels
<mvo> night daniels 
<Kamion> mvo: thanks
<elmo> ok, who broke ubuntu-desktop
<mdz> lamont: here
<Mithrandir>  bah, why can't emacs edit scripts inside debian packages?
<Mithrandir> stupid editor.
<lamont> mdz: wondering your thoughts on 5379, but I guess we should see what the real story with avcodec is first...
<lamont> (comments between my ping and now)
<mdz> Kamion: how do we look?
<Simira> mdz: better than ever, sweety ;)
<ogra> sexy like always :)
<Kamion> mdz: fixed the two of your showstoppers that belonged to me
<Mithrandir> mdz: approval for ooo-amd64 upload with newest ooo?
<mdz> Kamion: including the one which I apparently caused, eek
<thom> lamont: building
<mdz> Mithrandir: ok
<mdz> er
<Kamion> mdz: ah well
<mdz> daniels just left?
<Kamion> mdz: the archive-copier bug was amazing
<mdz> I don't see a xorg upload while I was away
<lamont> there's a -6ubuntu26
<elmo> lamont: err?
<mdz> Kamion: yeah, saw your analysis
<dholbach> ogra: wb
<Kamion> mdz: indeed, nor I ...
<ogra> hey dholbach 
<Kamion> though he did post a suggested fix procedure; I guess I could try that out
<mdz> he was supposed to test that and have a new upload in the archive by now
<mdz> fabbione: here?
<fabbione> mdz: yes
<Kamion> elmo: ubuntu-desktop> hmm?
<mdz> fabbione: do you know what happened with daniels and xorg?
<elmo> Kamion: nm, it was python being o-o-d
<elmo> will fix itself
<Kamion> k
<fabbione> Kamion: i just managed to complete the setup for 8287.. fillint up the hd with junk right now :-)
<elmo> still on: kdesdk (known fix, AIUI) and mozilla-locale-{it,ptbr}
<fabbione> mdz: nope.
<Kamion> maybe time to phone daniels; he's not been gone long
<fabbione> mdz: he left 10 minutes ago or so
<Kamion> fabbione: the ramdisk_size in silo.conf in installer-sparc/current/images/mini.iso looks accurate to me
<fabbione> Kamion: i will test again later to see if it was just a case
<pitti> seb128: what's the status of the uploads? I'm asking because of langpacks
<seb128> Kamion: are you updating the installer translations for the preview today ? or that's already updated ?
<seb128> pitti: I've just uploaded nautilus-sendto, I think all the packages are uploaded
<seb128> let it some time to build
<pitti> Kamion: seb128 is ready, is there still time for langpack updates?
<Kamion> seb128: I'm only updating translations in the cases where I'm uploading the packages anyway
<Kamion> at the moment I have no plans for any more
<seb128> k
<Kamion> pitti: yes, I think so
<seb128> no big deal, but one of the french string in the kbd screen is too long and cut, I've just noticed :)
<pitti> seb128: okay, so as soon as nautilus-sendto is built, I can go
<seb128> pitti: correct
<Kamion> seb128: yeah, too late for that sorry, I've already started the d-i initrds rebuilding
<seb128> np
<zul> lunch
<mvo> Kamion, mdz: permission to upload a one-line fix to gnome-system-tools? debdiff at: http://people.ubuntu.com/~mvo/review/gnome-system-tools/gnome-system-tools_1.2.0-0ubuntu3.debdiff
<mdz> mvo: ok
* lamont resumes his quest, albeit slightly refined...
<lamont> any kino users out there with a ppc box and some time to play?
<mvo> mdz: thanks 
<Kamion> hmm, translation issues in tzsetup-udeb/apt-setup-udeb still
<Kamion> I suspect it's better to fix those after RC :(
<doko> Kamion, mdz: ok to upload the fix for #8284?
<fabbione> mdz: the fix proposed on the mailing list seems to work
<fabbione> mdz: i am building a livecd for testing
* thom chuckles at mjg59 sending bug reports by SMS
<doko> mdz: the OO.o upload with the xhosa translations won't make it until tonight, I haven't got the complete translations yet.
<seb128> doko: oh, you are doing an OO.o upload ? 
<seb128> doko: I'll send you a french translation for the menu entries if that's ok
<doko> seb128, yes, small 250.000 line patch
<doko> seb128, yes
<seb128> thanks
* Mithrandir uploads ooo-amd64
<doko> Mithrandir: cool
<Mithrandir> it takes a few minutes, upload.u.c is a tad slowish
<trulux> tritium: hey
<Mithrandir> doko: uploaded.
<mdz> doko: ok
<mdz> fabbione: thanks
<ogra> mdz, hwdb.ubuntu.com/hwdb-data# ls |grep -c .xml
<ogra> 149
<Mithrandir> doko: tell me when the xhosa stuff is up there so I can use a gig more of bandwidth.
<ogra> this is for less then 7h up 
<ogra> :)
<mdz> ogra: nice!
<schweeb> ogra: if you remind me in about 7 hrs I'll send my data in :)
<ogra> yup :)
<mdz> ogra: we'll include a blurb in the release candidate announcement; that should kill your server nicely ;-)
<ogra> argh
<Mithrandir> ogra: it would be nice if I could go back in the hwdb-client
<trulux> btw, anyone owns a copy of Sun Tzu's Art of War in pdf? I'm going to buy it on Amazon but I need to make a review for tomorrow and I've forgotten mnay references and sayings from the book
<ogra> Mithrandir, i doubt i will make it in this release, i'm happy that i have gotten it in the shape it currnetly is, there are still some small but nasty bugs to fix
<trulux> from the online copies of the book at sonshi.com
<Mithrandir> trulux: http://www.kimsoft.com/polwar.htm , for instance?
<Mithrandir> trulux: or http://www.huntingdonsucks.com/downloads/the_art_of_war.pdf for a pdf
<Mithrandir> ogra: and it should list the data it sends before sending it off, due to privacy reasons.
<trulux> Mithrandir: many thanks!
<Mithrandir> ogra: and it would be nice if the timeout counted down and had a real progress meter for the upload. :)
<ogra> Mithrandir, there is no private data inside :) except the comments the user wirtes himself
<Mithrandir> ogra: it should still list what it's going to send.
<Mithrandir> and the fading is dog slow over forwarded X11. :P
<ogra> Mithrandir, the sendbar is one of the nasty little bugs i talked about ;)
<fabbione> mdz: the test you did with a working DDC probe was ok or do you i need to test that too?
<fabbione> mdz: the code path is pretty clear and it shouldn't have any problem
<mdz> fabbione: it would be worthwhile to test that as well
<Mithrandir> ogra: how does it handle the case of multiple sound cards?
<Mithrandir> (or video cards or whatever)
<fabbione> mdz: ok, if i give you an i386.deb can you test it? the machine i have with DDC working has non-suitable setup for it right now
* lamont grumbles at mvo for exposing the inconsistencies in the archive.  (apt-get sometimes gets Release.gpg from one "day", and Packages.gz from another --> sig errors)
<lamont> s/archive/archive production process/
<ogra> Mithrandir, the test currently only picks the default alsa device (first card) but the detailed info is in hwdb-xml -d
<elmo> lamont: don't use ftp-master then :P
<ogra> which is attached to the file
<elmo> that inconsistency isn't exposed in the real world
<lamont> elmo: is user in #ubuntu
<lamont> he managed to catch the mirror process
<mvo> lamont: you are not the only one. users complain about that too :)
<ogra> Mithrandir, the app doesnt by far do what i wanted to do it yet, version2 will be a lot more automated....
<elmo> eh, how?
<lamont> mvo: yeah - been chatting with Seq about it in #ubuntu
<fabbione> ok anybody with an i386 and DDC working?
<lamont> elmo: rsync still takes finite time to move the files
* fabbione urges somebody to do a test
<lamont> hence, you can grab one, rsync comes blazing through, and then you grab the next
<elmo> lamont: time to fetch dists/* shouldn't be that much, it's not like it mirrors pool/ in between
<fabbione> the output from xresprobe will tell you if your DDC are working
<lamont> esp true for users with slower links
<lamont> elmo: yeah - the user is the one taking the long time
<elmo> well I don't see how we could fix this really
<mdz> fabbione: the only machine where I could test that is a laptop with LCD; that doesn't test the proper case, does it?
<lamont> elmo: me neither
<lamont> elmo: on the bright side, once hoary ships, we stop generating new Packages/Release.gpg files every 30 minutes... :-)
<fabbione> mdz: did X actually detecte the LCD size properly?
<mdz> the only way to fix that case would be to fetch both files at the same time, I suppose
<mdz> fabbione: yes
<fabbione> mdz: than it is ok
<mdz> fabbione: but doesn't it do that by calling X, not using DDC?
* lamont wonders if hoary-updates is at least in as a comment in /etc/apt/sources.list now, or if it's going to be as usable as warty-updates was...
<fabbione> xresprobe does the detection passing the info back to X
<fabbione> it doesn't really matter how it detected the info
<fabbione> mdz: grab the xserver-xorg from people.u.c/~fabbione
<fabbione> mdz: purge the one you have installed and make sure there is no /etc/X11/xorg.conf
<fabbione> install the one from p.u.c
<fabbione> and see if you get prompted for a question or not
<elmo> lamont: it's definitely in, maybe even enabled by default
<enrico> mdz: what did you want me to upload?
<elmo> whine whine whine
<mdz> enrico: current svn, with mako's fixes to the about page
<elmo> mdz: in any idea how I convince apt-ftparchive to not generate Packages/Sources files?
<lamont> mvo: how about this (for breezy timeframe, of course): fetch Release.gpg, Release, if bad-sig ,fetch Release.gpg.  if bad-sig, error.  Fetch Packages.   check all Packages, if bad sig, refetch Releases.gpg, Releases as before.  Packages sigs must be in one of the two validated Release files.
* lamont feels sick
<enrico> mdz: I'll try.
<thom> mdz: i did that yesterday
<thom> enrico: ^^
<elmo> there doesn't seem to be a tree equivalent of 'Contents " "'
<mdz> enrico: ^^
<mvo> lamont: we could also try to fetch Release.gpg and Release in parallel?
<thom> mdz: sorry, should've mentioned it
<elmo> enrico: ^^
<lamont> mvo: sure
* elmo didn't want to feel left out
<mdz> lamont: you can easily check the functionality of hoary-updates by doing a test install
<lamont> mdz: is inplan
<mdz> thom: I didn't see it go by on hoary-changes, thanks
<mdz> lamont: would be a good idea to pull down CDs now so that you can rsync less later
<lamont> mvo: if you fetch them in parallell, then you have to refetch both if you get a badsig
<lamont> mdz: gonna drive to the neighbors, where fresh iso's were downloaded overnight
<thom> mdz: np; i just had a horror moment and checked - ubuntu-docs |    0.4.1-1 |         hoary | source, all :-)
<Kamion> lamont: should be enabled by default as of base-config 2.62ubuntu17
<lamont> Kamion: ok.
<HoMiE-[G] > hey
* lamont will verifiyt that
<mdz> lamont: wonderful
<lamont> :-)
<HoMiE-[G] > i was just told to ask her about serial mouses
<HoMiE-[G] > is there anything i can do to get mine working ?
<airox> Is python similar to other programming languages ? So, is it easy to learn ?
<HoMiE-[G] > anyone ?
<lamont> Kamion: /current is from ~02:30 UTC?
<schweeb> airox: it shouldn't be tough... although that's a bit OT for here
<airox> Well ubuntu uses python a lot didn't it ?
<schweeb> yes
<airox> Ok
<Seveas> airox, yes, but this is a development channel
<airox> I know :)
<airox> That's why I asked.
<HoMiE-[G] > yo
<HoMiE-[G] > can someone help me ?
<elmo> pitti: ?
<fabbione> Kamion: where in partitioner i can resize the NTFS thingy?
<lamont> HoMiE-[G] : that's a #ubuntu question
<schweeb> airox: if the channel name was #python, it would be on topic :)
<lamont> HoMiE-[G] : this would be the channel to discuss your patch to fix it.
<lamont> :-(
<HoMiE-[G] > my mouse isnt ps2
<HoMiE-[G] > its serial
<pitti> elmo: ?
<fabbione> Kamion: never mind
<airox> schweeb: It had a reason behind (sorry can't seem to find a better translation for this sentence).
<seb128> doko: http://rafb.net/paste/results/flz8ku47.html
<elmo> pitti: you on top of the mozilla-locale crap or should I file it as a bug?
<HoMiE-[G] > i asked in #ubuntu
<HoMiE-[G] > but they said to come here
<HoMiE-[G] > cause they didnt think a serial mouse is supported
<pitti> elmo: are there still issues? I thought now we've got everything?
<lamont> HoMiE-[G] : my daughter's computer had a ps2  mouse plugged into the serial port
<lamont> until the motherboard died, that is.
<elmo> pitti:  -it and -ptbr aren't installable ATM
<HoMiE-[G] > lemont
<pitti> elmo: okay, I'll look after it
<HoMiE-[G] > well mine is a ps2 mouse
<HoMiE-[G] > plugged into a serial port
<HoMiE-[G] > what can i do ?
<Treenaks> HoMiE-[G] : plug it into a PS/2 port, or make sure the mouse is capable of functioning in the way you've connected it
<HoMiE-[G] > i know it is
<Kamion> lamont: right, I'm currently rebuilding
<HoMiE-[G] > cause i used it on windows for the longest time
<lamont> HoMiE-[G] : in any case, it's not a development question, hence OT
<doko> seb128: thanks
<seb128> thank you
<lamont> Kamion: ok.  holler when you're done, so I can freshen things before I go fetch
* lamont has the 02/03:xx images
<mdz> fabbione: hmm
<enrico> thom, mdz, elmo: thanks ^^
<mdz> Unpacking xserver-xorg (from xserver-xorg_6.8.2-6_i386.deb) ...
<mdz> Setting up xserver-xorg (6.8.2-6) ...
<mdz> cat: /var/lib/xfree86/xorg.conf.md5sum: No such file or directory
<mdz> xserver-xorg postinst warning: not updating /etc/X11/xorg.conf; file has
<mdz>    been customized
<fabbione> mdz: did you make sure that /etc/X11/xorg.conf was removed?
<fabbione> i didn't see that error at all
<mdz> fabbione: yes, but then I installed xserver-xorg and it failed to configure due to a missing dep
<mdz> hmm, still happening though
<mdz> see /msg
<fabbione> mdz: can you try to purge it completely?
<fabbione> and reinstall again?
<mdz> fabbione: I have done that several times, but sure
<fabbione> mdz: weird.. because i don't get that message here
<fabbione> mdz: that error is weird
<fabbione> i am checking if i can reproduce it with a DDCable machine
<mdz> it is 100% reproducible
<fabbione> but i don't think that is the problem
<mdz> fabbione: the result is a correct xorg.conf, though
<fabbione> not the line i changed at least
<fabbione> the change is just to handle the priority at install/upgrade time
<mdz> this machine is not up to date; I will upgrade it and re-test to be sure
<fabbione> but nothing more than that
<fabbione> mdz: ok thanks
<fabbione> i am almost finished installing my box here
<fabbione> so i can test on more machines
<fabbione> and livecd is burning
<elmo> Removing render-dev ...
<elmo> dpkg - warning, overriding problem because --force enabled:
<elmo>  This is an essential package - it should not be removed.
<elmo> that's some good crack, monsieur dpkg
<fabbione> ahahhaha
<fabbione> mdz: see ^^^we can blame Keybuk !
<Mithrandir> <Keybuk> iz gtk bug
<mdz> elmo: how did that happen?
<elmo> mdz: I removed a bunch of packages from a chroot, including python2.4 and python2.4-minimal and it seemed to lose it in terms of what it considered Essential
<Keybuk> don't suppose you've got a copy of your status file around?
<elmo> pre or post?
<Keybuk> elmo: both
<Keybuk> Mithrandir: s/Keybuk/seb128/
<elmo> Keybuk: only post now - but I'll copy that to one side and try and reproduce
<Keybuk> it could be that the file is a little corrupt, and the field has become attached to the next package in the list (guessing)
<elmo> oh, I have status-old
<elmo> Keybuk: http://people.ubuntu.com/~james/paste/status
<elmo> Keybuk: http://people.ubuntu.com/~james/paste/status-old
<maswan> elmo: did you want anything important?
<elmo> maswan: hmm?
<Mithrandir> maswan: saw my message about grim?
<maswan> Mithrandir: yeah, thanks
<Keybuk> elmo: looks like you've purged stuff since
<elmo> Keybuk: yeah, meh, that status-old isn't pre the apt-get purge.. lemme retry 
<Keybuk> doesn't match any bug I'm aware of :-/
<Keybuk> oh, wait
<elmo> reproducible at least
<Keybuk> what's the "Removing" line *after* that message? :p
<elmo> Removing patch ...
<elmo> dpkg - warning, overriding problem because --force enabled:
<elmo>  This is an essential package - it should not be removed.
<elmo> Removing quanta-data ...
<elmo> for example..
<Keybuk> kooky
<elmo> getting a pre and post for you
<mdz> Keybuk: say, why is it that dpkg doesn't seem to pay attention to priority changes in new versions of binary packages?
<Keybuk> mdz: because apt never calls dpkg --update-avail? :p
<mdz> avail?
<mdz> I mean Priority: in the status file
<mdz> for installed packages
* fabbione boots liveCD on non-DDC machine
<ubuntu> So I'm playing with a live CD of hoary and I see the default evolution launcher in the panel is still "versioned"
<pitti> seeeeeeeeeeeb!!!
<Keybuk> mdz: because the info from the available file overrides it
<Keybuk> it assumes that ftpmaster is all-knowing
<pitti> seb128: I think there is something wrong with your g-c-m upload
<mdz> Keybuk: ??///
<seb128> pitti: oh ?
<Keybuk> the Priority, Section, etc. of a package is frequently bogus
<Keybuk> because ftpmaster override it
<shaya> just evolution-2.2 now
<seb128> ?
<mdz> hmm, point
<pitti> seb128: all po files are in po/, but da.po is in gnome-cups-manager-0.30/po
<shaya> it woul seem to cause the same problem as warty's evolution-2.0 issue
<Keybuk> so dpkg always uses the values from the available file
<Keybuk> and writes those to status, not what it found in the package
<shaya> why not just make that launcher "evolution" (plain no version)
<seb128> pitti: hum, lemme check
<Keybuk> but because apt never updates dpkg's available database, things never change
<mdz> I maintain that dpkg's available database is a bug
<elmo> Keybuk: same place has status-pre, status-post and not-so-essential.txt.  can reproduce on demand if you need more
<fabbione> mdz: -7 is go for me on install on both non-DDC and DDC boxes. Testing LiveCD now
<mdz> fabbione: great, thanks
<seb128> pitti: utch, lemme fix
<mdz> fabbione: 1 question on non-DDC, 0 questions on DDC?
<shaya> mdz: a bug or a dselect tied into guts of dpkg issue?
<fabbione> mdz: correct
<Kamion> mdz: it's not really dpkg's database anyway, it's dselect's
<mdz> Kamion: see above, though
<Kamion> mdz: and its author agrees with you that it shouldn't be in dpkg
<shaya> which remidns me
<shaya> why in the world does dselect pre-depend on dpkg?
<Kamion> shaya: upgrades
<shaya> upgrades?
<Kamion> shaya: it's transitional
<shaya> hmm
<mdz> shaya: you mean dpkg pre-depending on dselect?
<Kamion> hasn't stopped people filing bugs in an attempt to break the transition though
<shaya> Kamion: it's been like that for ages
<seb128> pitti: in fact it's in po/da.po and gnome-cups-manager-0.30/po/da.po
<Kamion> shaya: that's because it's ages since woody
<mdz> shaya: it's been like that for <1 Debian release
<seb128> pitti: that's bogus but works :p
<shaya> ah
<shaya> makes sense
<shaya> so since sarge will never ship, it will never change :)
<Keybuk> Kamion: ish; there's a lot of requirement in dpkg for an available file too
<Keybuk> removing it isn't a simple matter
<Kamion> Keybuk: mm, true, actually I think I was thinking of the desired-state bit in status
* Mithrandir whines to lamont that the ooo-amd64 isn't finished building yet.
* kain is away: e poi onslaught
<Keybuk> eg. dpkg relies on package control data being in available to support --configure -a
<mdz> shaya: I don't think that's true, apart from not being very nice :-P
<Keybuk> elmo: can you reproduce with -D7777 and send me the (yards) of output
<seb128> pitti: fixed
<elmo> Keybuk: k
<Keybuk> uh, status and status-old don't match what you actually did in not-so-essential.txt ?
<Keybuk> ah, *finds status-pre and status-post in ..*
<seb128> shaya: what do you want to change to the evo desktop files ?
<elmo> yah, sorry, ignore status and status-old
<fabbione> mdz: -7 is go on 3/3 boxes with expected behavior, both install and liveCD
<mdz> fabbione: fantabulous, upload when ready
<fabbione> mdz: it's on the way
<lamont> Mithrandir: thanks
<Mithrandir> lamont: what's up with it?
<lamont> Mithrandir: successful build, just needs a little bit of love\
<Mithrandir> oh, ok
<lamont> crested is coming back into the rotation, and um, needed some, um, personal attention
<fabbione> elmo, lamont: can we make xorg -7 go slightly faster to the buildd?? it should be accepted in 2 minutes by katie
<Mithrandir> *chuckle*; :-)
<lamont> fabbione: that's an elmo question
* Kamion tests out the pre-publishing scripts
<fabbione> elmo: ?
<elmo> well I just locked myself out of my home machine with keybuk's evil -D 7777 DOS
<elmo> laLALALAla
<Keybuk> don't tell me you forgot to redirect the output? :p
<fabbione> elmo: you rock!
<mdz> smurfix: ping?
* lamont wonders what this lovely Keybuk-DoS is...
<elmo> fabbione: pushed through
<Keybuk> lamont: I suspect he just went dpkg -D7777 over an ssh connection
<Keybuk> it tends to give a lot of output veryveryvery fast :p
<fabbione> elmo: thanks
<lamont> ah, -D == debug?
<jani> elmo could you please sync from unstable ruby-defaults and ruby1.8 ? I tested them, thanks (for darcs too)
<Keybuk> (and usually coredumps at some point, yay)
<lamont> Keybuk: hrm.. you should fix that. :-P
<Keybuk> lamont: I fix 'em as I find 'em
<elmo> jani: ruby1.8 is in main
<jani> elmo, oh :(
<elmo> will need approval from mdz before I can sync that at this point
<mdz> I thought we managed to kick ruby1.8 out of main
<elmo> I assume no point in syncing one without the other?
<jani> I thought all ruby was universe
<jani> elmo, right they go together
<elmo> mdz: swig and redland-bindings seem to be pulling it in
<jani> indeed I wonder why since ruby is in universe
<mdz> jani: today is the day before the Ubuntu 5.04 release candidate; we aren't changing anything without a very good reason
<mxpxpod> jbailey: hey
<mdz> jani: what bugs will it fix?
<jani> mdz, right I missed the fact ruby1.8 was in main
<mdz> jani: is it needed to fix some universe packages?
<jani> mdz, well a lot of bugs since it's a stable ruby
<jani> but some packages in sid depend on it
<jbailey> mxpxpod: 'sup?
<mxpxpod> jbailey: not much... how goes the libmpeg2 stuff?
<jani> and we cannot bring those in (rake, ruby on rails) without updating ruby
<jani> besides ruby in sid makes it easier to install since it is no longer scattered to so many poackages
<jbailey> mxpxpod: I'm not actively working on it at the moment.  It doesn't segfault, which is an improvement over before, it's just slow.  Did I miss something else?
<mxpxpod> jbailey: that's about it
<mxpxpod> jbailey: it's really jittery
<jbailey> mxpxpod: Yeah, it's because it's doing it all without any altivec instructions.
<mxpxpod> jbailey: oh, that's nice ;)
<jbailey> mxpxpod: Since I don't know any altivec assembler, I tossed it into the "things to care about for breezy" bucket. (Bug #8007)
<mxpxpod> jbailey: breezy?
<jbailey> mxpxpod: The release after Hoary.
<mxpxpod> I thought it was grumpy after hoary
<dholbach> mxpxpod: Sneezy-1
<dholbach> ;-)
<Kamion> mxpxpod: it changed
<mxpxpod> ah, ok
<Kamion> and ubuntu-announce got mail
<jbailey> mxpxpod: I think the name change was a side effect of WEsley Crusher saving the multiverse too many times.  I have no explanation beyond that.
<fabbione> Kamion: 8287 unreproducible here :(
<dholbach> jbailey: *snigger*
<Kamion> fabbione: doesn't surprise me too much
<fabbione> Kamion: yeah
<jani> mdz, so no change to ruby before RC means no change before release either?So I know if I should look at the issue
<Kamion> ok, cdimage release publishing should go faster now
<mdz> jani: it depends on which packages in main depend on it
<jani> elmo said swig and redland
<mdz> if those two are regression-tested with the new version, we _might_ be able to update it, but it makes me uncomfortable
<mdz> if it's just to get a stable release and not to fix specific bugs, I'd prefer not to sync it
<Kamion> we did have complaints about the ruby split-o-matic packaging
<Kamion> somebody was pushing for an Ubuntu repackaging
<Guilmon> Kamion: the ruby split packaging is stupid, I concur
<jani> mdz, no specific bugs I have been bitten by but the changelog lists a lot of them.
<jani> Kamion, debioan unstable already improved on the situation
<jani> there are less packages now some were merged in libruby
<Guilmon> Kamion: I try to use ruby's network library, I don't expect downloading seperate libs.
<Guilmon> mdz: where are the source files for the GNOME startup picture?
<Kamion> jani: yes, I know
<jani> no need for ubuntu repackaging the debian-ruby people seem to be in it
<Kamion> I read the changelog
<jani> Kamion, ok :)
<Guilmon> It would be nice if ther was a Ruby-devel monthly snapshot
<Guilmon> Matz adds really nice features between releases
<Guilmon> there are tar gzips on the ruby site daily fyi
<jani> my main reason fror syncig would be that some apps not in ubuntu but in sid depend on versions of ruby >1.8.2
<Guilmon> 1.8.2p2 is old ;)
<mdz> Guilmon: ubuntu-artwork
<Guilmon> mdz: it has source, or just the destination file?
<mdz> Guilmon: ?
<Guilmon> mdz: is it jpg or gimp source?
<mdz> ubuntu-artwork is the source package which builds the ubuntu-artwork binary package
<mdz> Guilmon: it is neither; I believe it is a PNG
<Guilmon> oh.
<Guilmon> mdz: who has the source?
<mdz> I am not sure that anyone has it, why?
<Guilmon> mdz: I'm assuming it was created from gimp or ps.
<mdz> photoshop, I believe
<HoMiE-[G] > hey
<HoMiE-[G] > can someone help me ?
<HoMiE-[G] > with pppoe ?
<mdz> HoMiE-[G] : this channel is where we coordinate development work; for help ask on #ubuntu
<dholbach> HoMiE-[G] : you know this is a #ubuntu question
<HoMiE-[G] > yeah i know
<HoMiE-[G] > but they wont help me :P
<HoMiE-[G] > i ask and they dont answer
<HoMiE-[G] > they said to set it up
<HoMiE-[G] > its in gnome
<schweeb> you're not gonna get much of a response in here either
<mdz> be patient, or ask on the ubuntu-users mailing list
<dholbach> HoMiE-[G] : try ubuntu-users@lists.ubuntu.com
<HoMiE-[G] > but when i go into it dont see it
<HoMiE-[G] > ok
<HoMiE-[G] > then
<HoMiE-[G] > sorry
<ggi> Ho ho! - http://lists.ubuntu.com/archives/ubuntu-devel/2005-March/006241.html
<nohar> hi guys
<seb128> mdz: so we are going with 2.10.1, nice :)
<opi> Polish LoCo meeting in #ubuntu.pl, all people related, please join :-)
<mdz> seb128: yes, per sabdfl
<seb128> k
<mdz> lamont: ping when xorg 6.8.2-7 is uploaded, please
<Seveas> mdz, it's been sent out to hoary-changes...
<pitti> hmm, no meeting now?
<pitti> darn, daylight saving...
<dholbach> pitti: changed - i heard about it 3-4 hours ago
<dholbach> pitti: i changed it on wiki/Calendar as well
<Kamion> Seveas: that's source upload, mdz's asking about binary upload
<pitti> but it's still 20:00 UTC?
<Seveas> i see
<dholbach> pitti: that's how mdz changed it on wiki/TechnicalBoardAgenda
<pitti> yeah, I didn't take daylight saving into account...
* Seveas still pretty new at all of this automated things, sorry for the disturbance
<shaya> thom: you here?
<Keybuk> pitti: it's currently 1907UTC, meeting in one hour :)
<pitti> Keybuk: yeah, I just noticed :-)
<zul> pitti: date --utc usually works ;)
<dholbach> Keybuk: what about: The next meeting of the Board will be on: Tuesday 12 April 2005 at 2000 UTC   ?
<dholbach> Keybuk: no wiki/TechnicalBoardAgenda?
<dholbach> s/no/on
<Keybuk> dholbach: no agenda, I guess; I last checked more than 2 hours ago
<dholbach> hm ok
<pitti> lamont: ping
<lamont> pitti: ack
<pitti> lamont: I just tried to build new langpacks
<pitti> lamont: and noticed that nautilus-sendto_0.3-0ubuntu6_translations.tar.gz has an ancient format
<pitti> lamont: i. e. from a very old pkgstriptranslations version
<pitti> lamont: is that possible somehow?
<lamont> pitti: hrm... checking
<pitti> lamont: I repack the tarball manually
<pitti> lamont: nautilus-sendto_0.3-0ubuntu6_translations.tar.gz.old is the tarball that was created originally
<lamont> pitti: uh, yeah./
* lamont kicks crested
<lamont> fxied, and yes, nautilus-sendto was built on the buildd in question
<pitti> lamont: thanks
<pitti> lamont: does that affect other builds as well?
<pitti> lamont: nevermind, my script will find out... :-)
<lamont> there were about 4
<lamont> which, depending on order, may or may not be affected.
<pitti> lamont: okay, that's a manageable number for manual repacking
<smurfix> mdz: 
<lamont> oo.o-amd64, kubuntu-meta
<carlos> mvo: around?
<mvo> carlos: yes, but I'm preparing dinner :) 
<mvo> carlos: that is, I wanted to leave for dinner now. is it urgent?
<carlos> mvo: not really
<carlos> mvo: will talk tomorrow if I'm not around when you are back
<mvo> carlos: what is it about ? rosetta?
<tritium> Hmm, I see a nick highlight for me, but it's beyond my scrollback.
<thom> shaya: yeah?
<thom> tritium: you don't have anything as useful as /lastlog -hilight?
<tritium> thom, I'll try :)
<tritium> thom, learned something new
<shaya> thom: you recently put a rtl patch into firefox? is that Simon Monatgu's from bugzilla?
<thom> shaya: yes
<shaya> ok, it fixes the rtl issues w/ pango, but not the combining characters
<shaya> still screws up horribly on rtl text w/ combining characters (i.e. hebrew w/ vowels)
<shaya> I'll bug him about that
<shaya> just wanted to know what the story was before I bugged him
<thom> shaya: ok; yeah, please do - i know next to nothing about international font madness :-)
<thom> it's his patch unchangeds
<shaya> no problem.  doesn't really effect me except for a bible site that has the text in hebrew and refuses to remove the justified attribute
<shaya> as normally moz+pango works fine with hebrew+vowels, except if you justify the text
<shaya> then it just falls down horribly
<shaya> but email's sent
<TD> hello. is there any way to programmatically determine that an ubuntu-style sudo/disabled-root system is in use?
<pitti> seb128, Kamion: langpack updates are ready for upload. Okay to go?
<mdz> smurfix: regarding the problem of non-latin keymaps where people can't login
<mdz> smurfix: is there a way to find all of those semi-automatically so that we can fix them in one batch?  users continue to report new examples
<TD> (without detecting ubuntu specifically, obviously)
<smurfix> mdz: Hmm, let me look at it a bit
<thom> TD: root passwd as * or ! would be a good guess (here is a better place)
<mdz> TD: sudo lets you query it for this information, but authentication is required
<mdz> TD: what is the specific problem you need to solve?
<TD> hmmm, yes, need to know without authentication really
<TD> essentially when running something as root, how to know whether to ask the user for the root password or their own password
<TD> when providing a custom authentication gui
<fabbione> mdz: -7 is go on all arches
<mdz> fabbione: only amd64 and i386 are in the archive so far, waiting for powerpc
<fabbione> mdz: ok, it should enter within 20 minutes
<mdz> it's in accepted/
<fabbione> yeah but daily runs at :03 and :33
<fabbione> so approx 20 before it hits the archive
<mdz> yep
<pitti> seb128, Kamion: okay, I'll upload now since I didn't hear any objections :-)
<smurfix> mdz: The list is: am ar bg by dz el il ir iu jp lo mk ml mm mn ru th tj ua uz 
<mdz> smurfix: so far the solution has been to use "us,<foo>" as the X keymap
<mdz> smurfix: should we do that for all of those?
<smurfix> mdz: That does look like the most-correct solution
<mdz> el, ru and one other have been reported as bugs
<seb128> pitti: fine with me
<TD> thom: how do you mean. ubuntu disables root by setting the password to * or ! ? that doesn't sound quite right ...
<lamont> mdz: ppc xorg missed the last cron.daily by 4 minutes...  will hit this next time around (:03)
<lamont> but you know that
<mdz> TD: not the password, but the encrypted password field in the shadow database
<mdz> TD: which obviously requires root
<mdz> I think the best you can do is to make it a configurable setting
<mdz> indeed, the two methods are not mutually exclusive; they can both be in use on the same systems
<mdz> and a different method needed depending on which user is authenticating
<mdz> some users in sudo, others using the root password
<TD> ah i see
<smurfix> mdz: Unless somebody from $LOCALE tells us otherwise, lets do it that way. One or two of them might have a non-US basic layout but I don't have any way to check for that.
* TD nods
<TD> hmmm
* TD wonders how to explain this in a newbie friendly fashion
<smurfix> mdz: Ah, there's a more comprehensive list in /etc/X11/xkb/rules/xorg; grep for "nonlatin"
<smurfix> mdz: it's commented out, so *possibly* the fix is to just remove the comment markers
<smurfix> mdz: if that works (dunno how well-tested it is) that'd let us avoid the workaround at xorg.conf generation time
<mjt> mdz: where's that bug re el, ru layout?
<mjt> (i'm using ru here... ;)
<mdz> mjt: #7656, #8202
<ogra> mdz no meeting today ?
<mdz> ogra: no meeting today, and no meeting next week (due to the release)
<ogra> (because -meeting is crowded)
<mdz> is the topic stale?
<ogra> including sabdfl
<ogra> nope, dholbach removed it
<mdz> ok then
<sabdfl> ah
<fabbione> who canceled the meeting?
<fabbione> i need somebody to throw in the same room with my wife while she boils down
<zul> hehe
* fabbione heads off to sleep
<fabbione> good night
<mjt> well, selecting just 'ru' w/o 'us' is indeed a bug ;)
<mjt> ditto for el and other non-latin layouts/languages
<TD> does ubuntu hoary still install the lsb package by default?
<pitti> night fabbione 
<zul> night fabbione 
<mjt> for "ru" there should really be 2 choices: "en,ru" and "en,ru(winkeys)" (expect more bugs if that isn't done ;) -- the former comes from old typewriters, the latter has been "invented" by M$ and is far more suitable for a computer; there are both types of keyboards out there
<mjt> m$ defaults to the equivalent of "ru(winkeys),en" 
<lamont> mdz: so does this mean yet newer CD images with xorg -7?
<zyga> TD: hey
<zyga> TD: do you want to customize your password dialog for ubuntu?
<TD> yeah. well, no. not really. i'd like to detect when sudo is available and use that, as asking the user for their own password is better ui than asking for the root password imho
<TD> but it's looking like we'll just special case for ubuntu and live with sucking :)
<zyga> TD: that's a bad idea
<smurfix> mjt: gdm doesn't have a keyboard layout widget (yet?), so we need to start off with US layout (for now?)
<TD> yeah. it's not great. but it beats asking the user for a root password they don't have
<lamont> TD: ubuntu-desktop Depends: lsb
<mvo> Kamion, mdz: permission to upload libgksu: http://people.ubuntu.com/~mvo/review/libgksu/libgksu1.2_1.2.5a-1ubuntu2.debdiff ? suppresses a bogus message, talked to kov (upstream) about it and he agrees with it
<TD> lamont: thanks, i had a vague feeling it'd been removed but i guess not
<zyga> TD: why don't you add a checkbox 'I don't have root pasword, use sudo instead'
<lamont> TD: plan is for breezy to remove it
<TD> ah
<TD> that'd be why i had the vague feeling
<lamont> since lsb Depends: mail-transport-agent, and that's going away from base
<TD> zyga: we already have a "No password" button for when you don't have superuser access at all. And I don't want to put the term "sudo" in the UI
<TD> sudo isn't a word that's meaningful to end users, generally
<TD> one alternative is to ask the user for the "System access password" and then try both su and sudo
<zyga> BTW: why gdm by default (with ubuntu skin) has no way to do a remode xdcmp login?
<lamont> my first project for breezy is to free my baby (postfix) from the base-chains that bind it
<zyga> TD: that would be usble :-)
<lamont> TD: you could try su, and then fail back to sudo, or vice versa
<zyga> TD: I guess probing is the simples way
<TD> yeah, that's what we are thinking
<lamont> or assume that executable /usr/bin/sudo + /etc/sudoers ==> sudo for root...
<TD> or rather try sudo then su. problem is sudo generates scary errors and warnings sometimes. like the "lecture" :)
<lamont> but that's probably not wise.. (the assumption)
<lamont> lecture is disabled on ubuntu
<TD> and if you get it wrong it sends an email to root
<TD> heh, good :) it's not disabled everywhere though
<lamont> yeah.
<lamont> hence su then sudo might be better...
<lamont> or have a config option that says what order (and whether) to try
<lamont> root_access: sudo, su
* TD nods
<zyga> lamont: that's not really useful - TD is trying to make autopackage compatible with ubuntu
<TD> yes, su then sudo may work better. i'd avoid a config option
<TD> this is supposed to just work dammit :)
<lamont> well, packaging for ubuntu vs debian could be different (diff defaults, etc.)
<zyga> TD: how about system specific config file
<zyga> TD: /etc/autopackage.specs
<zyga> TD: if it's there read it and know better
<TD> zyga: that's just a variant of "detect ubuntu" which is why i was asking about the lsb package
<TD> i'd rather not do that if possible. using sudo instead of root password is a pretty good idea
<zyga> TD: Ubuntu could just have that tiny package in ubuntu-base stuff
<TD> it would not surprise me if other distros copied it
<TD> zyga: well that was just being discussed on the mailing list, and i don't think it's going to happen anytime soon
<zyga> TD: true 
<zyga> TD: not adding the whole autopackage stuff
<zyga> TD: just one small specs file
<zyga> TD: try asking again
<TD> well, the objection isn't that autopackage is too big. it's that it's the wrong approach entirely
<TD> so i doubt the base/desktop maintainers would be more amenable to that. anyway we can already detect ubuntu
<zyga> TD: well then you're stuck between the hammer and the anvil ;] 
<TD> yeah ;)
<zyga> TD: anyway you could try asking again
<zyga> cat /etc/autopackage.specs
<zyga> sudo
<zyga> ... that's it
<TD> we'll figure something out. anyway, i think that's enough for today. TV time :) i'll be around later, but all my questions are answered now
<mdz> mvo: hmm
<mdz> lamont: yes, it does
<mdz> CDs building now
<lamont> rsync just about done now.. :0)
<mvo> mdz: if you have doubts, we can postpone it (or leave it as it is). it's only a cosmetic problem, gksu sometimes gives spurious warning-messagesboxes because it don't always get the interaction with sudo right
<lamont> mdz: holler when they're done, eh?
<lamont> reminds me.. .parent teacher conferences the next 2 days... ISTR bonnie's is on the 31st.
<koke> elmo: I don't want to be tiresome, but what happened to my key? I've already a package for upload :)
<pitti> fabbione: new CAN
<pitti> oh, he's asleep
* mvo goes to bed now too
<zul> pitti: gah...more? :)
<pitti> zul: no, just a CAN for an already fixed one
<pitti> zul: can you add it to the changelog, too?
<zul> i can put it my archive and tell fabbione to pull from it
<pitti> zul: I mail him
<mdz> lamont: install CD builds and cloop builds are in progress
<mdz> I'll start live CD builds when both are done
<lamont> woot
<lamont> mdz: with jido?
<lamont> jigdo, even
<mdz> no
<mdz> jigdo takes an extra hour
<Kamion> no it doesn't
<Kamion> it's certainly slower but it isn't an extra hour
<Kamion> I'll see if I can rope Steve McIntyre in post-hoary to help me switch to JTE
<mdz> Kamion: doing the jigdo post-publish would be sufficient for our purposes, I think
<mdz> new install CDs are syncing
<mdz> Kamion: I'm going to run to the store for food; can you coordinate with lamont to get a new live build started when the cloops are ready?
<elmo>  [TXT]   hoary_probs.html        29-Mar-2005 21:37  242
<elmo> yay!
<elmo> now if only breezy would stay that way ;-P
<lamont> elmo: heh
<Mithrandir> lamont: still no ooo-amd64? :/
* lamont will need to go child-gathering in about 65 minutes...
<lamont> Mithrandir: should be there by now... grumble.
<Kamion> mdz: post-publish> if you don't mind not being able to build CDs until the jigdo's done, that would certainly be possible; though it'd require some kind of republishing step
<Kamion> mdz: yep
<schweeb> lamont: heh, rephrase that, or you'll sound like a paedophile ;)
<Mithrandir> lamont: doesn't look like that.
<mdz> elmo: anastacia output is looking good too, finally
<elmo> mdz: I know! no more db4.0! *dance*
<elmo> we should do this release thing more often ;)
<Mithrandir> elmo: did you hear my sick, sick thing I thought of at FOSDEM?  (wrt libdb)
<Mithrandir> we could just make a binary-compatible alternate library which used sqlite as the backend.
<Mithrandir> it'd be broken, but in alternate ways. ;)
<schweeb> elmo: dunno if you're the one to talk to, and I don't really care much, but gsf-sharp never got announced to hoary-changes, even though it's in the archive, and I got my notify emails... just figured you'd want a bugreport on your emailer tool
<elmo> Subject: Accepted gsf-sharp 0.3+svn20050320-1 (source)
<elmo> schweeb: that?
<schweeb> yea
<schweeb> hrm, I don't see it on the changes archive
<elmo> it got sent - hoary-changes suffers from overly fascist spam filtering
<schweeb> ahh
<elmo> 'cos our mailman setup is to damn dumb to be able to do innovative cutting edge filtering like, err, filtering on a given header
<schweeb> alright then, all is good :D
<crimsun> schweeb: (don't worry, none of mine are announced either)
<schweeb> lol
<elmo> crimsun: that's the Maintainer field, you could avoid that
<crimsun> elmo: yeah, I stripped '.'
<crimsun> elmo: also tried quoting it
<crimsun> (ogra let me know)
<schweeb> elmo: should I change the package to not build on amd64 and ia64, as they don't have mono packages, or would that be on your end?
<elmo> but in any event, end-of-day, we should just beg/bribe tollef to fix our mailman to filter on X-Katie, and have jdub not apply our spam filters to hoary-changes
<elmo> schweeb: I'd just leave it - it doesn't do any harm for them to not build, and hopefully amd64 at least will get mono eventually, and this way you won't have to change your package when it does
<schweeb> that's what I figured
<mdz> Kamion: ubuntu cloops are done, kubuntu in progress, I'll start cron.daily-live
<mdz> scratch that, only one is done
<lamont> mdz: was just considering whether to say that i386 was done.
<lamont> amd64 is compressing, ppc is rsyncing-to-loop
<Kamion> mdz: yeah, was watching the i386 cloop and had just noticed ...
<lamont> ad64 done
<lamont> ppc still restoring image
<lamont> ppc is [ 9]  Block#   378 size  65536 ->  34803 [compression ratio  53%, overall:  34%] 
<koke> elmo: did mako sent you my key? I'm not sure who I have to ping
<elmo> koke: hmm, no, you're not in mako's list yet
<koke> ouch!
<elmo> I'll send him a mail
<koke> elmo: thanks anyway
<seb128> haggai: around ?
<lamont> Kamion: over 3/4 done compressing
<lamont> Kamion: ubuntu cloops are go
<CarlK> hi folks
<CarlK> Does anyone want to help me figure out why my e-machine box keeps "stoping" (but not locking) durring a daily install?
<lamont> CarlK: that'd be a #ubuntu question
<CarlK> even on the same install image, it is never the same place that it stalls, and most of the time I can get to a shell
<Kamion> lamont: builds started
<CarlK> lamont - I am just using it to test installs and report install bugs,
<lamont> Kamion: kubuntu-live cloop will fail, I expect (kdepim)
<CarlK> I was wondering if anyone here 
<Kamion> lamont: that should be fixed now
<CarlK> I was wondering if anyone "here" wanted to see if there was an install problem or if my box is just haunted
<lamont> Kamion: yeah, but it's still building...
<Kamion> CarlK: I'm inclined to think the latter, personally :)
<Burgundavia> CarlK: why don't we debug on #ubuntu, and if it is a bug, then we can report it to bugzilla
<Kamion> bugs with that kind of description are usually broken hardware ...
<lamont> Kamion: ppc is still building, i386 will enter the archive in 9 minutes, and amd64 is there.
<CarlK> Burgundavia - see ya there
<lamont> kdesdk also needs to be built, amd64 is doing that now, the others are waiting for cron.daily to run
<CarlK> Kamion - me too - I ran stresslinux for 12 hours and didn't have any problems
<lamont> Kamion: so, yeah, it's fixed.  But the fix is still in-flight. 
<lamont> Kamion: 2100UTC sound about right for the i386 install iso timestamp?
<Kamion> lamont: yes, that's right
<lamont> cool
* lamont gets ready to go child-collecting, will wait for cron.daily so he can give kdesdk back on i386
<lamont> ppc may have to wait for my return
<lamont> if kdepim doesn't finish in time, I'll at-job the kdesdk thing to happen 30 min latyer
<lamont> back in 5m ors
<lamont> or so
#ubuntu-devel 2005-04-10
<Riddell> lamont: what's the kdesdk thing?
<Riddell> ah I see
<Kamion> new live CDs up
<lamont> ew.  ppc has 1.5MB of the 2.5MB needed for a successful log.
<lamont> something tells me it won't be done by :00 :-)
<lamont> OTOH, ia64 is at 1.2MB. :-(
<lamont> kdesdk will be given back at :40.  Good luck kdesdk and kdepim. :-)
* lamont will be back in about an hour and a half
<pitti_> night everybody
<dholbach> bye pitti 
<seb128> 'night pitti_
<mdz> Kamion: amd64 install starting stage 2, archive-copier looks good
<mdz> Kamion: that new progress bar is still a little funny; it goes through 2 steps without updating the progress bar
<Kamion> mdz: ok, I'll have a look at it post-preview
<Kamion> er, post-rc
<Kamion> it's better than a blue screen though :)
<mdz> yes
<Kamion> powerpc install in base system
<mdz> definitely cosmetic
<Kamion> the lack of translations in tzsetup and apt-setup concerns me more
<Kamion> that requires the locale to be generated earlier, I think; or alternatively a cheesy templates hack
<mdz> en_US seems to have very good translation coverage
<Kamion> haha
<mdz> I'll be able to confirm the xorg fix shortly on amd64
<mdz> my powerpc test install is at about the same point as yours
<Kamion> mdz: btw what do you mean by "goes through two steps"?
<mdz> Kamion: the text at the bottom of the dialog box changes, but the progress bar doesn't
<Kamion> weird, don't see where that could be happening; I'll watch out for it
<mdz> it changes to "Checking for CD-ROM..." or similar
<Kamion> yeah, that's got a STEP immediately before it
<Kamion> unless I just fouled up the use of the progress interface somehow
<mdz> is the previous step doing STEP after, rather than before?
<Kamion> it goes START INFO <stuff> STEP if (condition) { INFO <stuff> STEP } STOP
<mdz> interesting
<mdz> I don't know why it looks the way it does, then
<mdz> it's as if that last STEP doesn't take effect
<Kamion> the INFO inside the if is the one associated with the message you mentioned
<mdz> amd64 xorg is good
<Kamion> I see what you mean - but the message before "Checking for CD-ROM" disappeared too quickly
<Kamion> mdz: I think I know what it is: the condition (above) is looking for a file on the CD, so it's probably seek delay between STEP and INFO
<mdz> powerpc booting stage 2
<mdz> Kamion: I  just watched it on amd64, and it was too fast to notice
<mdz> but on powerpc I could see the delay
<mdz> no DMA on that CD-ROM either, on powerpc
<Kamion> I should move the test up anyway to get the progress bar length right, which would fix it as a side-effect
<elmo> why does the gnome keyboard stuff always come up in a too-small window?
<elmo> and does anyone know how I map a us (if it matters) win key to alt?
<nictuku> hi.
<nictuku> I'd like to request that you please compile pound with "--enable-msdav" in the distributed package
<nictuku> that goes in debian/rules, line 31
<tseng> msdav = microsoft webdav?
<nictuku> yes. Technically, it add the *possibility* of enabling WebDav access in pound.
<tseng> we already removed libhowl due to legal issues
<tseng> this *sounds* even shadier
<nictuku> don't worry, it just makes pound forward some HTTP commands.
<nictuku> it's required to make subversion work behind pound, either.
<tseng> ok.
<tseng> can you add it to MOTUTodo on the wiki please/
<tseng> ?
<nictuku> sure. Is it possible to make it ship with hoary?
<dholbach> nictuku: could you provide a source package?
<dholbach> nictuku: that would be the easiest thing for us
<nictuku> I could, but I don't even know if hoary uses 1.7 or a newer version of pound.
<dholbach> nictuku: you have hoary?
<nictuku> not yet (production servers).
<dholbach> ah i see
<dholbach> Version: 1.7-1
<nictuku> how should I update debian/changelog?
<dholbach> nictuku: would you joib #ubuntu-motu
<nictuku> sure
<jdub> tseng: howl was removed for licensing reasons
<tseng> s'what I said
<tseng> just wanted to be sure this wouldnt put us in the same boat, you know.
<jdub> you said it in response to enabling something in existing open source code
<Kamion> mdz: hmm, there is a very ugly pile of scrollkeeper errors on powerpc install
<mdz> Kamion: install-amd64 successful
<Kamion> /var/lib/scrollkeeper/C/scrollkeeper_extended_cl.xml:2526: parser error : Extra content at the end of the document^M
<Kamion> ic-repo-aptline">The Syntax of the APT line^M
<Kamion> mostly that sort of thing
<Kamion> and there is indeed garbage at the end of scrollkeeper_extended_cl.xml
<mdz> powerpc is in scrollkeeper here
<mdz> I'm starting some kubuntu builds
<mdz> seb128, pitti: here?
<mdz> something odd just happened
<mdz> I inserted an Ubuntu amd64 live CD while logged into the desktop
<Kamion> and can somebody please fix that stuff about scrollkeeper trying to load a network entity?
<mdz> an icon appeared on the desktop, but it was called "CD/DVD-ROM"
<mdz> and when I double-clicked it, I got burn:///
<minghua> Kamion: yeah, that bug is annoying, especiall there is an email complaining about it
<mdke> ping seb128 
<seb128> mdz: pong
<mdke> heh
<mdz> seb128: any idea why that is happening?
<seb128> mdz: are you sure that's not a blank CD ?
<mdz> seb128: yes, I just booted from it :-)
<mdz> and it's not a burner either
<seb128> mdz: could you look with lshal or hal-device-manager what kind of CD is detected ?
<Robot101> mdz: are you aware of a buglet where when doing dist-upgrade with apt, and using pinning or default releases, it wants to install/uninstall stuff based on the conflicts/depends of the highest available version, rather than the version which is the installation candidate?
<Robot101> mdz: resulting in apt-get dist-upgrade wanting to install or remove things, but upgrade saying everything is up to date?
<mdz> seb128: will do, after I finish this live CD test
<seb128> k
<mdz> seb128: it is a DVD+RW, so it could be written again, might that be related?
<seb128> it should be depend on what hal detects
<mdz> Robot101: that's not quite what's happening, but yet
<mdz> Robot101: s/yet/yes/
<Robot101> mdz: I get it because of the python changes in hoary - dist-upgrade wants to remove python, even though upgrade is happy
<juan> hi guyz. will you update mono package to 1.0.6 or 1.14 ?
<mdz> bug 170522 or something like that
<seb128> mdz: hum, could be
<mdz> yep, #170522
<Robot101> mdz: aha, OK
<Robot101> well that one hasn't been filed too many times :)
<mdz> can someone fix the "none busy" error on shutdown?
<mdz> it's the last remaining wart on the live CD
<juan> hi guyz. will you update mono package to 1.0.6 or 1.14 ?
<mdz> and iirc it affects the installed system too (though it's less visible there due to the lack of interactivity)
<mdz> juan: tseng looks after our mono packages
<tseng> juan: im working on 1.1.4 as a maybe
<Kamion> oh for pity's sake, I hate heisenbugs
<tseng> right now everything is failing spectacuarly
<seb128> mdz: who handles the about-ubuntu stuff ? He has put a po file C/about-ubuntu-fr.po instead of making a fr/about-ubuntu.xml ...
<mdz> seb128: the doc team has it in svn
<mdz> seb128: the best thing would be to fix it and send a patch
<seb128> they don't know how that work, do they ?
<juan> tseng ? mmm let me see, thx :)
<mdz> seb128: no, enrico did it originally but he no longer has time
<seb128> k
<mdz> so currently no one is maintaining the packaging
<tseng> juan: i just said it doesnt work at all
<tseng> even a little bit.
<Burgundavia> seb128: if you send a patch, I will commit it
<seb128> mdz: that's not important for the candidate, I'll fix that for hoary though 
<juan> tseng opps ok :/
<seb128> Burgundavia: that's easy, put the french xml file as fr/about-ubuntu.xml
<juan> I'll have to compile it xD thx
<seb128> Burgundavia: /usr/share/gnome/help/about-ubuntu/
<seb128> Burgundavia: C/about-ubuntu.xml is the default one, translation are <locale>/about-ubuntu.xml
<mdz> seb128: it says is_blank=1, is_rewritable=0
<Burgundavia> seb128: ok, will do
<seb128> mdz: and it's not blank ? hal bug I would say 
* lamont returns
<dholbach> i know you couldnt care less about BOFs at this stage of the release, but is there a way to still get a CDBS BOF in?
<Kamion> Burgundavia: while you're at it, fixing the various broken symlinks in the doc packages would be good
<Kamion> mdz: I wonder if the scrollkeeper thing is just because /usr/share/xml/4.3/docbookx.dtd is 4.3b2, not 4.3, so the proper catalog entry isn't registered
<mdz> Kamion: live is good x3
<Kamion> Debian #301157
<elmo> hey, can we fix that damn blurry icon of update-foo before release?
<jdub> in the splash? yes, that's fixable
* jdub gars at lack of real icon for it
<mdz> Kamion: given a successful i386 install report, I'm fairly satisfied
<dholbach> elmo: if you talk about the faded icon in the tray that you get while "something happens", that's a feature
<elmo> dholbach: no, like jdub said, I mean the one in the splash
<mdz> seb128: is sound preview in nautilus expected to work?
<dholbach> mdz: if you have sox installed
<mdz> but we don't install sox by default
<mdz> and that's silly besides
<jdub> very silly, very silly
<Kamion> adding a system id to the 4.3 catalog entry seems to fix the annoying "Attempt to load network entity" errors
<Kamion> per suggestion in Debian #301157
<Kamion> but I'm not sure about doing that given that the docbook 4.3 files in docbook-xml are actually 4.3b2, and I don't know what happens if you change that
<seb128> mdz: you need sox or mpg123/ogg123 
<mdz> seb128: why doesn't it use gstreamer?
<jdub> it was written before gstreamer existed
<jdub> and no one has really cared enough about the feature to redo it
<jdub> it's possible it could be redone with the nautilus extension framework though
<Kamion> so anyone willing to own up to knowing about docbook-xml?
<dholbach> jdub: something we could add on a potential wiki/WantAnIdeaForYourUniOrSchoolProject
<jdub> dholbach: cool
<jdub> Kamion: i may be able to answer
<seb128> mdz: what jdub said
<dholbach> jdub: that's why i wrote wiki/AcademicInvolvement ages ago ;-)
<mdz> I swear we talked about this before
<mdz> it's a shame not to have that feature work out of the box
<Kamion> jdub: see comments above about docbook 4.3 / 4.3b2 / system ids
<jdub> hmm
<jdub> interesting
<mjt> re netcache proxies - typical "ftp user" variant (USER something@host:port -- proxycheck tries just that).  Your example 194.172.17.76 just have port 25 out blocked so you can't list it in dsbl.
<mjt> doh mischan
<mjt> sorry
<jdub> Kamion: hrm, don't think so
<jdub> Kamion: one of the docs must refer to a bad schema
<Kamion> jdub: it's weird because 4.3/ChangeLog in the source says "DocBook XML V4.3 released" at the top
<Kamion> jdub: no, all the docs look perfectly fine, it's the catalog that's broken
<Kamion> and as I say making the 4.3 catalog look like all the other 4.* catalogs fixes it
<jdub> oh, i missed that big
<jdub> bit
<Kamion> oh, hang on, there aren't 4.3b2 entries in there at all
<Kamion> they're in comments
<dholbach> good night
<Kamion> I think I'll upload docbook-xml to fix this, if nobody objects; the errors are ugly
<mdz> has anyone tested current/hoary-install-i386.iso yet?
<jdub> night dholbach 
<dholbach> bye jdub and i'll start wiki/HacksWeCouldNeed first thing tomorrow :-)
* lamont notices that is rsync has finished, heads to the neighbors to fetch
<juan> !
<Kamion> mdz: will do in a bit
<Kamion> docbook-xml fix uploaded; we don't *have* to go with it for RC
<nictuku> can someone please report if this is currently accessible? http://www.grupomabel.com.br/ubuntu/
<Burgundavia> nictuku: it is
<Burgundavia> some people on #ubuntu are reporting the tracker is unavailable for torrents
<nictuku> thank you Burgundavia.
<Lathiat> nictuku: works fine
<nictuku> thank you.
<helio7>  http://releases.ubuntu.com/hoary/ torrent tracker is not doing its job I'm fairly sure; I've verified the problem with other folks, but can't figure out where to report it to the Ubuntu administration; can anyone here relay that message?
<elmo> helio7: how do you mean not doing it's job?
<helio7> "Error: Requested Download is not authorized for use with this tracker" is the message I get; I'm just trying to help out by seeding the latest hoary ISOs; they were working a few days ago... but now are not... you can try one  hhttp://releases.ubuntu.com/hoary/hoary-preview-install-ia64.iso.torrent
<helio7> I confirmed the error was not unique to my system by asking someone in #azureus to try; they received the same error
<elmo> Kamion: err, dude?
<Kamion> gar, I didn't realise thom had disabled all the existing torrents
<Kamion> ok
<Kamion> I thought it was on the basis of "existing torrents, plus new stuff in torrent tree"
<CarlK> Kamion - you need any more info?  I was going to poke around
<Kamion> CarlK: nope
<Kamion> CarlK: if you mean on the torrent thing
<CarlK> Kamion - torrent thing.  k.  I'll get back to other things
* lamont_r wonders why acpi says I have no battery
<Lathiat> need one of the magic laptop acpi moduules?
<Lathiat> lke the ibm and dell ones?
<helio7> from the sounds of your talk; my message has been received by those with the power to fix it.  Correct?  
<mdz> helio7: yep
<elmo> helio7: yeah, thanks
<Kamion> right, I'm on it, I'm just in er a slightly awkward situation machine-wise right now
<Kamion> helio7: can you stick around for a bit?
<helio7> np thank you; just trying to do my small part to help out Ubuntu; I'm very appreciative; sure I can stick around.
<Kamion> elmo: I think those ISOs should be heading back towards orcadas now; can you see whether the autotracker magic is working?
<elmo> Kamion: I _think_ it's okay
<Kamion> helio7: can you give it another try?
<helio7> yup verified here as well Kamion + elmo (= cool
<helio7> you all rock
<Kamion> fantastic, thanks for the report
<Kamion> it was a combination of things, mostly my screwup/misunderstanding, so sorry about that
<helio7> If I had a server I'd be hosting; seeding the torrents is the least I can do for this great system;  happy I could help; see you all another day
<elmo> kamion: just blame thom - I always do
<Kamion> heh
<seb128> 'night
<Kamion> I still can't seem to get http://releases.ubuntu.com/hoary/hoary-preview-install-ia64.iso.torrent though
<Kamion> i386 works
<helio7> ia64 is showing 2 seeds and 3 peers for me; no connection yet, but no error message either; I think it's just a question of availability
<Kamion> right, fair enough; I'm not really used to BT from the client end
<lamont_r> Kamion: lol
<Kamion> I just chuck stuff at torrent.ubuntu.com and hope it works :)
<CarlK> is all ok, or should a BT nut snoop around?
<Kamion> I think it's sorted; please mail cjwatson@ubuntu.com about any other errors (although note I'll be going to bed soon)
<Kamion> er, any other CD image BT errors that is ;P
<lamont_r> livecds finally finish downloading (x2)
<lamont_r> now to see how fast install CD's finish
<Kamion> mdz: btw install-i386 was fine, in case I forgot to say
<mdz> Kamion: great
<mdz> Kamion: do you want to go with RC tonight or tomorrow?
<Kamion> I haven't tried the live images yet, and I'm getting rather tired
<mdz> ok, let's send a call for testing to the lists and get some rest for tomorrow, then?
<Kamion> yeah, I think that's sensible
<elmo> kthxgnight
<mdz> Kamion: ok, please activate the bat-signal before you go
<Kamion> mdz: mm. I'd like to have jigdos for the install CD, but little's mirror has been synced since then so it's probably no longer possible to generate them
<Kamion> how do you feel about a rebuild of that lot, incidentally picking up the docbook-xml fix?
<mdz> haven't paid attention to what's been uploaded since then
<mdz> s/what's/what else has/
<Kamion> mdz: nothing else in my hoary-changes box
<juan> where is the dbus session start command at ubuntu? I mean, if it's on .bashrc... or another file... I want to build dbus with mono support, that's the reason... ?
<mdz> Kamion: docbook-xml is irrelevant to the live CD, right?
<daniels> fabbione: thanks a lot dude -- g'night
<CarlK> yesterday's live boots on my e-junk box
<mdz> CarlK: excellent
<CarlK> mdz - maybe - it does't help explain why I can't install
<Kamion> juan: /etc/X11/Xsession.d/75dbus-1-utils_dbus-launch
<CarlK> I have todays live and install - I'll burn and see what they do
<Kamion> mdz: well, it's in the desktop seed, so it's in both
<mdz> Kamion: but the change was only to fix the scrollkeeper errors, right?
<juan> Kamion thn! ;)
<Kamion> mdz: right, it's an addition to the catalog
<Kamion> mdz: it might affect the help browser on the live CD
<mdz> Kamion: I'm happy to go out with the current live CDs, and rebuilt install CDs, then
<mdz> no sense having to re-test them in this case
<juan> Kamion can I compile the lastest dbus and use it correctly at hoary?
<Kamion> juan: dunno
<Kamion> mdz: ok, I'll start a rebuild now, and test them all first thing tomorrow
<juan> Kamion sorry, I dont know what's dunno, sorry, I guess I can do that... or not?
<Kamion> juan: dunno = don't know
<juan> oh ok thnx :S
<juan> hmmnn
<juan> has hoary a dbus version with mono support?
<juan> I need that thing :/
<daniels> juan: apt-cache search dbus mono
<juan> sorry daniels thanks
<Kamion> juan: it's in universe; and this is an #ubuntu question really
<juan> mm
<juan> yes but I've compiled mono 1.1.4
<juan> I think dbus support is for 1.0.5
<juan> at ubuntu package..
<daniels> try it and see?
<juan> ok, np
<mdz> Kamion: hmm, DVD images
<bob2> bah
<bob2> the hibernate script doesn't ensure you're going to reboot into the same kernel you suspend from
<bob2> so if you upgrade kernel, don't reboot, hibernate, then you lose everything
<juan> daniels that worked, sorry and thanks.
<Kamion> mdz: you want them built?
<Lathiat> bob2: swsusp2 blats a big fat warning at you
<bob2> swsusp/pmdisk tells you it's screwed and continues booting
<bob2> which trashes the image
<Lathiat> heh
<Lathiat> nice
<bob2> swsusp2 is crack, tho; he wants to have THE KERNEL prompt the user about
<bob2> printf/gets from kernelspace, baybe
<Lathiat> suspend2 works far better however, and the kernel does blat at you about a few things that could screw your system
<Kamion> like what?
<Lathiat> booting from the wrong kernel
<bob2> how does it work better?
<Lathiat> booting when the root filesystem has already been mounted
<Kamion> I mean like what, pre-swsusp2
<Lathiat> bob2: i've never got the in kernel stuff to work for me, swsusp2 works nice, plus it has nice status bars and whatnot to let you know whats happening, and lets you suspend compress the image which speeds things up, among other things
<bob2> hm, had no problems with swsusp
<Lathiat> doesn't even suspend
<Lathiat> let alone resume
<bob2> if it doesn't work for you, that would be a bug (mjg59 said it should work pretty much everywhere now)
<Lathiat> (and suspend to ram works fine)
<Lathiat> i'll try it now
<bob2> heh, may not be fixed in the 17 minutes before the RC
<Lathiat> hahaha
<Lathiat> at least daniels fixed my resolution bug so 16:10 lcd resolutions now work
<Lathiat> that means all the important stuff on my laptop works out of the box which is rad
<bob2> itym "totally rad" ;-)
* lamont__r burns isos to CD
<mdz> Kamion: yes, I think we ought
<Kamion> mdz: ok; you want to run cron.dvd after my cron.daily run finishes, then?
<mdz> Kamion: sure
<Kamion> (note jigdo is turned off for DVD by default, so no need to hack it ;))
<mdz> if it finishes within the next 4 hours or so, I'll test it too
<mdz> oh, it should then
<Kamion> DVDs take 45mins-1hr or so
<zenwhen> Is the DVD going to be shipped?
<lamont__r> Kamion: wonder if you could be convinced to burn a mini-dvd iso.. (with no packages, just the front end...)  That'd be within my rsync abilities...
<Lathiat> oh lovely
<Lathiat> null pointer dereference in the kernel :)
<Lathiat> i wish the nv driver didnt have horrid color depth problems, gradients look like ass, especially the ones in the ubuntu backgrounds and whatnot
<Kamion> lamont_r: isn't that kind of pointless?
<lamont_r> Kamion: well, I was gonna brutalize it...
<Kamion> lamont_r: concatenate the install CD and the live CD, it'd be nearly as good
<lamont_r> Kamion: ok
<Kamion> you could rsync off that; would still take a few hours
<lamont_r> as in, include all the .deb/.udeb's from both?
<Kamion> I was thinking of 'cat' actually :)
<Kamion> hmm - wonder what would happen if you just catted all of main together plus a cloop, and rsynced
<Kamion> that's basically jigdo only stupider
<lamont_r> does rsync really handle bouncing around reordering like that?  didn't think it would...
<Kamion> dunno ...
<lamont_r> np
<Kamion> lamont_r: anyhow, take the install CD, delete all the .debs from it, dump in the live cloop and any missing .udebs; that's basically your DVD, modulo a bit of bootloader-fu
<Kamion> lamont_r: hey, you could try out the debian-cd stuff I got into baz recently
<Kamion>   baz register-archive http://people.ubuntu.com/~cjwatson/archives/colin.watson@canonical.com--2005
<Kamion>   baz get colin.watson@canonical.com--2005/cdimage--mainline--0 cdimage
<Kamion>   cd cdimage
<Kamion>   baz build-config configs/devel
<Kamion>   make -C britney/update_out
<lamont_r> Kamion: saw the email, was going to try that
<Kamion> then hack up the hardcoded paths in cdimage/bin/* and cdimage/debian-cd/CONF.sh (at least)
<Kamion> actually maybe not the latter any more
<Kamion> then cron.dvd and pray ;)
<lamont_r> and cdimage assumes that the archive is where in relation to itself?
<lamont_r> or rather, it assumes that /cdimage is right under the top of /ubuntu, yes?
<Kamion> /srv/cdimage.no-name-yet.com/ftp
<Kamion> or rather $CDIMAGE_ROOT/ftp; $CDIMAGE_ROOT is the cdimage above
<lamont_r> and $CDIMAGE_ROOT/ftp/cdimage?
<Kamion> so you get $CDIMAGE_ROOT/{bin,debian-cd,germinate,ftp,...}
<Kamion> no
<lamont_r> ah, ok
<mdz> Kamion: it so does take an extra hour for jigdo
<mdz> at least it did including ia64; maybe it's only 45m now
<mdz> Kamion: will cron.dvd make torrents?
<Kamion> mdz: don't mind me, I was only looking over the log files which include timestamps ;)
<Kamion> mdz: yeah, you'll get torrents created by publish-daily
<Kamion> (automatically)
* lamont_r wonders if that means there are yet newer isos....
<mdz> the last non-jigdo build for 3 architectures took 11 minutes
<Kamion> last cron.dvd seems to have created torrents successfully
<mdz> this one is looking like about 50
<Kamion> mdz: cron.dvd, fire at will
<Kamion> mdz: I'm outta here for the night
<mdz> Kamion: night
<elmo> cron.daily's disabled on ftp-master for a couple of hours btw - i'm just generating contents files ;)
* lamont_r heads back home
<josue> so, just a few hours from RC eh? good work everyone ;)
<shaya> whose in charge of the live-cd or installer?
<shaya> madwifi doesn't work with my thinkpad t42p with either with current live cd/installer
<shaya> but it worked with my old system (before the hard disk died)
<shaya> only difference is I had 686 kernel vs. 386 kernel live cd/installer use
<shaya> so something seems screwed up with them
<mdz> thom: the tracker is responsive, but there are no peers
<sPoof_> mdz: New MoinMoin package ready: http://debian.jones.dk/hykrion/pool/ubuntu/moin/
<wasabi__> holy artwork: Ubuntu hardware database
<wasabi__> slick
<bob2> daniels: is BinaryDriverHowto inaccurate for firegl on hoary?
<lamont> must buy new monitor soon
<lamont> hrm.. pressed the power button, why'd it say I did that twice, I wonder...
<mdz> wasabi__: credit goes to ogra
<fabbione> morning guys
<fabbione> mdz: how is the situation?
<mdz> fabbione: we did one more build in order to get jigdo files
<mdz> of the install CDs
<mdz> so live CDs are basically gold
<fabbione> rocking
<mdz> install CDs need sanity checking
* fabbione rsyncs
<mdz> should be identical to the last one except for docbook-xml
<fabbione> rsync cdimage.ubuntu.com::
<fabbione> rsync: connection unexpectedly closed (0 bytes received so far) [receiver] 
<fabbione> rsync error: error in rsync protocol data stream (code 12) at io.c(359)
<fabbione> is it overloaded or am i poiting the wrong one?
<smurfix> fabbione: Do you have an rsync already running?
<fabbione> smurfix: yes, but it is running towards sparc.u.c
<fabbione> i guess they are the same machine...
<mako_> mdz: hey dude.. just plugged in
<mdz> mako_: hey
<mako> grokster was awesome.. i was 25th of the 35 general public people that got in
<fabbione> hey mako
<mako> hey there!
<fabbione> any link to the full story?
<fabbione> no i don't read /. :)
<infinity> mdz : Do we want a (6 character patch) fix for that info segfault, or are we long past fixing anything that isn't critical?
<mdz> infinity: depends on whether it's a weird corner case or something people could actually encounter without trying
<infinity> It's bitten me dozens of times.
<infinity> And I'm not alone.  The Debian bug is full of "me too"s.
<mdz> the change would only affect the info reader, right?
<infinity> <nod>
<mdz> and not the bits that the world build-depends on
<infinity> Right.
<mdz> wait until after RC, but it should be fine
<infinity> Kay.  When's it safe to upload stuff again? :)
<infinity> I'll just queue up uploads i have approval for until I get a go-ahead.
<mdz> I'll post to -devel
<infinity> Check.
<fabbione> Riddell: ping?
<lamont> uh... why did keyboard choser just decide I have a serbian keyboard I wonder...
<crimsun> wait, you stole my serbian keyboard!
* lamont takes notes
<lamont> so, if I told it I want japanese, I should still be able to get keyboard chooser to pick american, yes?
<lamont> Gah! no casper translations to japanese????  hrmpf/
<minghua> lamont: I am not sure, when I tried installing in Chinese, I didn't have a chance to choose keyboard
<minghua> not that China uses any keyboards other than US layout though
<wasabi__> VS.Net sure is retarded.
<wasabi__> Nearly impossible to properly source control web projects.
<wasabi__> oops
<wasabi__> darnit. I hate IRC
<wasabi__> I see somebody whose nick looks like miguel so I spew out some mono crap in the wrong place.
<wasabi__> sorry. ;0
<calc> haha
<calc> does he even use freenode?
<wasabi__> no clue
<calc> i think he is mostly on gimp
<wasabi__> yeah.
<wasabi__> I know where he is. I just don't know where I am.
<lamont-jp> hrm.. /var/log/syslog doesn't get saved anywhere before the pivot-root, it appears...
<calc> wasabi__: heh
<calc> wasabi__ gets eaten by a grue
<wasabi__> Wow. ant is about to be built properly by the buildds.
<wasabi__> There are 13 things dep-waiting on it.
<lamont> kind of interesting to see what does and does not have translations in some languages
<lamont> Hrm... one should probably not use 'New Login' on the livecd.
<lamont> mdz?
<wasabi__> Ooh and just disappeared from the buildd list.
<wasabi__> s/and/ant
<wasabi__> Oh no it didn't. =(
<wasabi__> oh man. so close.
<wasabi__> jdepend needs multi->universe
<wasabi__> =(
<fabbione> mdz: do you have any opinion on #8287? I couldn't reproduce it here and have been trying for almost 4 hours
<fabbione> mdz: resized the damn thing like 9 times
<mdz> lamont: ?
<mdz> fabbione: this is the only such report I have seen
<fabbione> yes and i think that the filesystem was already dirty before the resize. I agree with the submitter that the check should be done before the resize and error reported.
<fabbione> that's the only explanation i have
<mdz> fabbione: but ntfsresize does a check itself
<mdz> it succeeded; you can see in the log
<fabbione> broken check?
<mdz> dunno
<mdz> Mar 27 15:22:35 main-menu[3124] : (process:18257): NTFS volume version: 3.1
<mdz> Mar 27 15:22:35 main-menu[3124] : (process:18257): Cluster size       : 4096 bytes
<mdz> fabbione: were those the same in your test?
<fabbione> mdz: hmmm no idea..
<fabbione> i will have to test it again
<fabbione> i trashed the setup to test X yesterday
<lamont> mdz: <lamont> Hrm... one should probably not use 'New Login' on the livecd.
<lamont> did we document that?
<mdz> lamont: does it break horribly?
<lamont> well, rebooting gets you back to a usable machine... or is the username and password documented somewhere?
<mdz> the password is locked
<lamont> and it requires one to get back from 'New Login'.
<mdz> shouldn't zapping the X server get you back as well?
<lamont> or a new user to log in as...
<lamont> I expect so
<mdz> I don't think it's any worse than the Lock Screen issue
* lamont reboots one more time
<lamont> I think it is equivalent to the lock screen issue
<fabbione> mdz: install cd still asks from the CD on phase2
<fabbione> is that expected?
<mdz> fabbione: absolutely not
<mdz> and it didn't for me (the last set)
<mdz> md5 of your iso?
<fabbione> rsynced an hour ago.. checking now
<fabbione> but it didn't read anything from it
<fabbione> just asked
<fabbione> c868ccfe958f85f3ef96c06f45707ad6  hoary-install-i386.iso
<mdz> it's a bug if it asks
<mdz> and it's a new bug in this build :-(
<fabbione> i agree :)
<fabbione> well it's not critical for RC
<mdz> yes it is
<fabbione> i need to check if netboot will ask
<mdz> we can release the previous build as RC though
<mdz> the docbook-xml thing was cosmetic
<lamont> 8d318ffb862129b32c2c267513e138a9 - doesn't ask
<fabbione> mdz: what about asking Kamion first?
<fabbione> perhaps it is simple to fix
<mdz> fabbione: sure, I'll be asleep when he arrives
<fabbione> i will remind him if that's ok with you
<fabbione> we will need the usual round of test anyway when you wake up
<lamont> fabbione: about when does pitti usually show up?
<fabbione> lamont: in 30 minutes
<fabbione> hold on...
<fabbione> mdz: wait.. it might be the usual I/O problem on my cdrom
<fabbione> mdz: never mind
<fabbione> the installer did it right
<fabbione> archive copier couldnt
<fabbione> read xlibs
<fabbione> and that's why it asked again later
<fabbione> so the behaviour is proper
<mdz> phew
* fabbione hates this shit
<fabbione> the weird thing is that i have problems only reading from the install media
<fabbione> never from live
<lamont> mdz: the blue arcs across the lower left of the screen... are those supposed to be there?
<fabbione> and even with different media
<mdz> lamont: you mean the artwork?
<diamond> fabbione: that reminds me, the warty live cds can't be read by either of my nec dvd-rw drives, but work fine in other computers. very annoying -/
<mdz> fabbione: install reads the entire disk, live only reads parts of it
<lamont> well, I don't see the blue arcs, but later I do...
<fabbione> mdz: yes i know.. but i would have noticed read errors running big applications
<fabbione> X is not what i would really define small :P
<mdz> fabbione: the odds are much lower
<fabbione> yeah i agree
<lifeless> could just run badblocks on it
<fabbione> FLY SPARC!
<fabbione> mdz: i think we can manage to get sparc/main in perfect wync for Final
<fabbione> too bad we won't have iso's
<fabbione> kubuntu made the buildd lagging a lot recently
<mdz> yes, kubuntu has been churning
<fabbione> mdz: due to gnome upcoming the 6th, do you think i will be allowed to sync main for sparc before we close hoary 100%?
<fabbione> it would be a real gain if it is all there
<mdz> fabbione: I'm not sure what you mean?
<mdz> we won't delay the release for sparc :-)
<fabbione> well gnome is quite big
<fabbione> no no i am NOT asking to delay the release
<fabbione> just if i am allowed to upload the sparc binary after hoary is released (in case the buildd will lag)
<fabbione> to sync main
<fabbione> and close hoary forever
<fabbione> morning pitti
<pitti> Hi folks
<pitti> Hey fabbione, how are you?
<fabbione> pitti: i am ok.. thanks and you?
<fabbione> any new dildo for me?
<pitti> fabbione: I didn't think about them over night :-)
<fabbione> tsk :P
<pitti> fabbione: oh, I *have* one :-)
<pitti> fabbione: did I tell you about CAN-2005-0767?
<fabbione> pitti: send it over
<pitti> fabbione: that's the recent Radeon DRI fix
<pitti> fabbione: so something to add to your changelog :-)
<fabbione> pitti: ah ok..
<pitti> fabbione: I already mailed the other one to you
<fabbione> but that's already fixed
<pitti> fabbione: I revieved the CAN database yesterday, this gives a lot of new crack :-/
<fabbione>   * [SECURITY]  drm: fix race condition in radeon driver:
<fabbione>     - Add patch stolen-from-head_radeon-race-fix.dpatch.
<fabbione>     (CAN-2005-0767)
<pitti> fabbione: okay, lemme look in my mailbox for truly new crack :-)
<fabbione> pitti: ah ok
<pitti> fabbione: yeah
<fabbione> pitti: so there is a new patch for it?
<pitti> fabbione: no, just the new CAN
<pitti> fabbione: ah, you already had it? sorry
<mako> http://www.ubuntulinux.org/wiki/DraftHoaryRCAnnouncement
<fabbione> no i just added it to the changelog :)
<pitti> ok
<pitti> Hi mako
<fabbione> pitti: i am faster than realtime with you :)
<mako> mdz et al: have nuts with that ^^
<mako> pitti: greetings!
<mdz> mako: cheers
<fabbione> mdz: i386 install if GO here. (excluding the I/O error but that's not the CD's fault)
<mako> i am going to collapse, i haven't slept in a day :)
<fabbione> the rest of the installation is ok
<mako> g'night all
<fabbione> night mako
<fabbione> sleep tight
<pitti> fabbione: you have mail
<pitti> night mako!
<fabbione> pitti: got it
<lamont> pitti: so should I be able to choose an american keyboard with Japanese?
<pitti> lamont: actually yes
<fabbione> pitti: interesting.. 
<lamont> because I press the keys, and it gets me to either serbia or lithoania
<pitti> lamont: -> smurfix :-)
<lamont> doh
<lamont> smurfix: you around?
<lamont> pitti: sorry
<pitti> no worries :-)
<mdz> I think the layout discovery is supposed to be independent of the language selection
<smurfix_proxy> hello world
<fabbione> hahaha
<mdz> you have a us layout and it isn't detecting it?
<lamont> is my vaio - rebooting to choose american and walk through the keyboard chooser there
<Mithrandir> doko: you commented (in 7404) that the next ooo build will have kde support.  That's ooo2, not ooo1, right?
<lamont> Lithoanian.  Hrmpf
<lamont> of course, there's some question of whether that final question is saying '1' or 'l'
<lamont> which bytes of the hex dump does he need, I wonder
<Fablive> yay
<Fablive> livecd i386 is go here
<lamont> mdz: I'm 2 for 2 here
<lamont> mdz: on the bright side, almost all US mapped keyboards are going to just hit return to 'American English'
<Burgundavia> I have seen that with a previous live cd as well
<Mithrandir> why is firefox too stupid to download and display a .diff.gz inline?
<Mithrandir> (but only if it's over ftp)
<lamont> Mithrandir: because gnome knows you really want to unpack it
<lamont> ??
<lamont> and it appears that the final '1' vs 'l' question actually involves a UTF 8 character
<daniels> bob2: err ... i'll check it out
<Mithrandir> uhm, isn't memtest86 in the default install any more?
<lamont> memtest86+?
<Mithrandir> the package name is memtest86, isn't it?
<lamont> ii  memtest86+     1.30-1         A thorough real-mode memory tester
<lamont> memtest86 is like, so, um, ancient.
<lamont> memtest86+ has a '+' in the name, so you know that it must be better
<lamont> :-)
<Mithrandir> bah
<Mithrandir> :P
<Mithrandir> thanks
<Mithrandir> both maintained by the ever-so-inactive Yann Dirson
<Mithrandir> elmo: please un-PaS memtest86+
<lamont> smurfix-proxy... err, pitti:  wanna tell smurfix that  'y q / [ # 1' is what I told it, and it decided lithanian instead of american english
<lamont> ?
<pitti> okay
<Mithrandir> lamont: are you _sure_ you have an US english keyboard? ;)
* Mithrandir hides
<lamont> Mithrandir: heh
<torkel> I think the merged memtest86 and memtest86+ (and then forked the + version again)
<lamont> Mithrandir: does memtest86+ build on amd64 now?
<Mithrandir> lamont: built fine here, at least
<pitti> lamont: I tell him when I catch him, it's on my todo now
<lamont> pitti: thanks
<Mithrandir> lamont: apart from the Architecture line, but that shouldn't matter?
<lamont> Mithrandir: uh, how about the debian version?
<lamont> Mithrandir: ISTR that memtest (or was that grub...  hell) wanted to be 32-bit mode, and the amd64 tools wouldn't let it.
<Mithrandir> seems to build with -m32 here
<lamont> and do you want memtest86+ and memtest86 unPaSed, or just memtest86+?
<Mithrandir> just memtest86+
<lamont> and that should build for debian too?
<lamont> that is, if they had amd64?
<Mithrandir> but will the build fail due to the Architecture line in debian/control being buggered up?
<lamont> yeah
<lamont> but I'm not so worried about that
<Mithrandir> I don't see why it shouldn't.  It's a different upstream version, but barring regressions..
<lamont> it's more one of, is there anything that needs to change in their toolchain to make it work?
<Mithrandir> (we're at memtest86+ 1.30, Debian's at 1.51)
<Mithrandir> give me a sec and I'll check
* lamont twiddles thumb s
<mdz> install-amd64 successful
<daniels> hooray
<Mithrandir> lamont: debian/control still needs to be adjusted in Debian, but that's a minor thing.  Seems to build fine, at least.
<doko> Mithrandir: 1.1.3-8ubuntu1 does have kde support (openoffice.org-kde), but AFAIK it's in universe
<lamont> committed.  elmo: 1.552 has the change
<Mithrandir> doko: ok; I'm going to ignore that for now, lest mdz and elmo wanting to kill me in gruesome ways.
<Mithrandir> mdz: ok to upload new memtest86+ with the Architecture line changed from i386 to i386 amd64?
<mdz> doko: universe? it's part of the kubuntu desktop seed
<mdz> Mithrandir: after RC perhaps
<Mithrandir> mdz: ok
<Mithrandir> doko: you _so_ owe me beer if I have to make an ia32-libs-kde.
<mdz> Mithrandir: I think that would necessitate metapackage/seed/debootstrap changes
<doko> mdz: ok, it was universe until two days before ...
<Mithrandir> mdz: nothing ought to break, but let's wait to be sure.
<mdz> Mithrandir: talk to Kamion about it when he wakes up
<Mithrandir> sure
<pitti> argh, keyboard selector still spits out this nasty error message...
<pitti> smurfix: ping
<Burgundavia> lamont: ping
<lamont> Burgundavia: yo
<Burgundavia> lamont: never mind, problem sorted
<Burgundavia> lamont: was a possible issue on #ubuntu
<stone> where do I report bugs (xvncviewer package ( -listen option))?
<mdz> ok, I have 3x3 successful installs with the current candidate
<mdz> good night
<fabbione> night mdz
<Burgundavia> stone: to the bugzilla
<smurfix> lamont: *sigh*. Can you tell me the keycodes of those keys on your keyboard?
<lamont> smurfix: sure
<lamont> from xev, yes?
<smurfix> lamont: nope
<smurfix> lamont: different keycodes :-/
<lamont> y==29, q==24, |==shift-51, /==61, [==34, #==shift-3==12, l==46, 1==10 (although that last prompt appears to be all utf-8 chars)
<lamont> bhah
<lamont> from where then?
<smurfix> lamont: console. "showkey". Discard bytes with the high bit set.
* smurfix will put that into the syslogged output ASAP
<lamont> that'd be really cool.. :-)
<lamont> booting a box to look at...
<lamont> smurfix: yq|\[#l1== 15,10,2b,35,1a,04,26,02
<lamont> although I should doublecheck that
<smurfix> lamont: looks the same as my guess
<smurfix> lamont: (not having an US keyboard)
<pitti> smurfix: the error message after the keyboard selector is still not fixed
<lamont> smurfix: confirmed
<smurfix> pitti: which error message?
<pitti> smurfix: i. e. press the keys for autodetection, then you come back to the small menu (with the layout name on top), press enter over the layout name and get a big red error
<pitti> smurfix: you can continue installation, and it doesn't happen any more after this, but it's scary
<smurfix> pitti: I don't get that
<lamont> so running showkey from an xterm is bad... :-)
<pitti> smurfix: besides, originally my layout was called "Deutsch", after the detection it is called "de-latin1-nodeadkeys"...
<pitti> smurfix: 1. choose autodetection
<pitti> smurfix: 2. press the few keys
<pitti> 3. you land back in the keyboard menu
<pitti> 4. the topmost entry shows "de-latin1-nodeadkeys" and is selected by default
<pitti> 5. press enter
<pitti> BOOM
<smurfix> pitti: which keys did you press
<pitti> smurfix: reproducible on 5 machines
<pitti> smurfix: ugh, the right ones...
<pitti> smurfix: the detected layout is correct, BTW
<pitti> smurfix: it's just the cosmetic, but scary error message
<smurfix> pitti: not reproducible here, will rsync the current CD and test with that
<pitti> thanks
<pitti> smurfix: btw, that happend already one or two weeks ago
<pitti> also this seems to be rather platform independent
<smurfix> pitti: I think I know where it comes from, but need to verify
<pitti> smurfix: also, is it possible to display a more friendly layout name? i. e. "Deutsch" instead of de-latin1-nodeadkeys?
<smurfix> pitti: Please do tell me which keys you usually press when you reproduce that problem ;-)
<pitti> smurfix: okay, as soon as my ppc installation is finished, I try the live CD
* tausq waves. can anyone here help with an oo.o packaging question?
* tausq is trying to figure out where mozlibs comes from and how to create it for a new port
* lamont heads to bed
<fabbione> night lamont
<lamont> see y'all in 5-6 hours
<tausq> bye lamont, thx for your help :)
<smurfix> pitti: OK, uploaded kbd-chooser_1.09ubuntu16 which should fix the red screen
<pitti> cool, thanks
<smurfix> (kamion was faster with a translation update)
<smurfix> I'll figure out what's missing in the US keymap ... again
<pitti> mdz: ppc/install is fine
<pitti> mdz: the only flaw is the DRC setting in the mixer
<smurfix> Now why did this morning's X update ask all the f*cking X setup questions .. again ... three times?
<smurfix> (as did the one before. and the one before.)
<sabmoc> hi smurfix, sounds like your not having a good day :(
<pitti> smurfix: erm.. "Press one of these keys: q"
<pitti> smurfix: this is more funny: "| /"
<fabbione> ehehe
<pitti> smurfix: neither of these two I can enter without shift
<smurfix> pitti: OK, I'll add rudimentary counting abilities
<pitti> smurfix: does it really need the q for keycode checking?
<smurfix> pitti: So? just press the key it's printed on
<pitti> smurfix: I don't mind s/one of these keys/the key/
<pitti> smurfix: ah, so without shift?
<smurfix> pitti: It needs the Q figure out whether you're French or Dvorak or whatever
<smurfix> pitti: it does tell you when you press shift not to do that
<pitti> argh
<smurfix> pitti: though the wording could conceivably be cleared up
<pitti> now I get the error message immediately after I pressed the last key
<pitti> n d q | [ = z
<xuesheng> by the way, we're still missing a decent X keymap for azerty ibooks....
<smurfix> pitti: Yeah, there's an internal table overflow. As I said, fixed in ubuntu16
<pitti> ok
<smurfix> pitti: That "n" basically isn't, it's some kind of UTF8 glyph which happens to look like "n", so I accept that key via my ugly lookalike table
<smurfix> pitti: I may be able to tweak the heuristics so that's somewhat less likely to happen
<pitti> oh, if it's required, I don't mind
<smurfix> need to figure out where lamont's Lithuanian map comes from, first
<smurfix> pitti: Well, I could have chosen something that doesn't look like something else, which would shorten the decision path
<smurfix> xuesheng: So write one ..?
<smurfix> bah
<pitti> mdz: ppc/live is go
<pitti_live> mdz: i386/live is go
<sabdfl> morning all
<mvo> morning sabdfl 
<smurfix> Bah, found the US map problem. The alias map doesn't have an 1 / l-lookalike entry, and what the decision tree wants to proceed to the US keyboard is the cent sign
<smurfix> Fortunately that's easily fixable
<pitti> smurfix: any idea why the i386/live doesn't offer nodeadkeys to me?
<pitti> that works fine on ppc/install and ppc/live
<smurfix> pitti: can't think of anything that's different
<pitti> okay, nevermind
<smurfix> I've now found 40 characters looking like 1/l/I. *Grumble*
<thom> mdz: meh. they're certainly all running
<pitti> daniels_: ping
<infinity> Morning, thom.
<thom> yo
<thom> infinity: how goes it?
<infinity> I goes in a reasonable fashion.  You?
<thom> can't complain
<infinity> I can always complain, I suppose I'm just more creative. ;)
<thom> well, i'm sure i could if i think hard, but in general ;-)
<thom> infinity: yeah, but you're a whiney yank ;P
<infinity> Heh.
<infinity> My only big complaint is that daniels and I still haven't found a place.
<thom> heh. it's not hard. there are these things called "houses" or "appartments". They have a sign outside saying "to let". You go to the estate agent, say "ug. me want see biggum house" and they show you the house. you give them "money" and they give you the keys
<infinity> Neat theory, but you left out the part where only 1 in 40 of these "houses" look like they haven't been previously inhabited by "serial killers", and the ones that are decent have several dozen "applicants" all fighting for them.
<pitti> fabbione: this CAN-2004-1073 is a beast
<thom> infinity: see, you should aim the "serial killers" at the "applicants"
<pitti> fabbione: I have the exploit, I modified it according to the mail, it core dumps, but I absolutely cannot find any trace of the setuid program in the core
<fabbione> pitti: how bad?
<pitti> fabbione: the vuln is that you have a setuid program that is executable, but not readable
<pitti> fabbione: the exploit is supposed to core dump, and the dump should contain the setuid program
<fabbione> yes i could understand that
<pitti> fabbione: so that you can read it after all
<pitti> but I don't find the program in the core
<pitti> fabbione: I try the warty kernel now
<fabbione> pitti: that we fixed with all the other patches?
<fabbione> while other distro didn't?
<pitti> fabbione: i. e. the original one (unpatched) and the latest security updaate
<pitti> fabbione: I think there was a general misunderstanding and there has never been a patch for CAN-2004-1073
<fabbione> pitti: ok, if you need me to build and test, please send me the poc
<pitti> fabbione: the reporter can use the exploit even on 2.6.11
<pitti> fabbione: chinstrap:~pitti/can1073.c
<fabbione> ok
<pitti> fabbione: start it with a chmod 4751 program as parameter
<pitti> fabbione: and enable core dumps before
<fabbione> pitti: in a sec...
<pitti> fabbione: don't worry, I try it on an old kernel first
<fabbione> pitti: is that one the modified or original poc?
<pitti> fabbione: this is the modded one
<pitti> brb
<fabbione> ok
<pitti> fabbione: I'm on an unpatched Warty kernel now, go and hack me :-)
<fabbione> pitti: ehhehe will do :)
<fabbione> ok i got the poc and a test program
<fabbione> i can't remember how to enable coredump tho :)
<pitti> ulimit -c hard unlimited
<fabbione> 12 -rwxr-x--x  1 root root 11474 2005-03-30 10:57 hello
<fabbione> that's just Hello World!
<pitti> you need a 4751 program
<pitti> i. e. the user can setuid-root execute it, but not read it
<pitti> fuck, it still doesn't work
<fabbione> strings hello |grep Hello
<fabbione> Hello world!
<fabbione> strings core |grep Hello
<fabbione> Hello world!
<fabbione> works here
<pitti> yeah, now it works for me too
<pitti> on 2.6.8.1 pristine Warty
<pitti> fabbione: you tried on hoary?
<fabbione> yes
<pitti> fuck
<pitti> it didn't work for me on the hoary kernel
<pitti> I try again with the most recent warty kernel
<fabbione> with Version: 2.6.10-31
<pitti> brb
<fabbione> ok
<pitti> fabbione: okay, for me it works on warty pristine, warty-security, but not hoary
<pitti> fabbione: but if it works for you on hoary, too, then we are completely doomed :-)
<fabbione> pitti: on what arch did you test it?
<pitti> fabbione: i386
<fabbione> same here
<pitti> fabbione: I doubt that the assembler code runs on ppc
<fabbione> pitti: i did just grep for the string inside the core
<pitti> Moins seb128
<pitti> fabbione: me too
<pitti> fabbione: I did chmod 4701 /usr/sbin/ddcprobe
<fabbione> pitti: ok
<pitti> fabbione: and used the exploit on this
<seb128> hi
<mvo> hey seb128 
<seb128> who broke my xfree ? Instead of my 1280 (75hz?) I've 1024 now
<fabbione> pitti: i just wrote hello world :)
<pitti> fabbione: strings core revealed some ddcprobe strings on warty, but none on hoary
<seb128> (60hz)
<pitti> seb128: hey, my flatmate has the same problem
<seb128> s/xfree/xorg even
<pitti> fabbione: okay, it's not the worst bug in the world, so let's see what the kernel gurus say to this
<seb128> rahh, I hate this resolution
<fabbione> pitti: yes i agree. it's not the worst i have seen
<fabbione> but we should get a patch for it 
<seb128> anybody with an idea to fix my xorg before I start downgrading ?
<seb128> daniels_: !!
<fabbione> seb128: dpkg-reconfigure xserver-xorg
<pitti> seb128: the funny thing was that dpkg-reconfigure xserver-xorg after this detected the correct resolution again
<seb128> lemme try
<mvo> ping jdub 
<mvo> quick poll: how do you like http://people.ubuntu.com/~mvo/update-notifier-panelicon.png ?
<seb128> hum, better :)
<smurfix> mvo: If that's supposed to be an exclamation mark it needs to be more distinct
<seb128> thanks guy
<mvo> smurfix: good point
<smurfix> Do US keboards have the  (Cent) sign printed on them?
<thom> smurfix: the one US keyboard i have does not 
* smurfix feared as much
<Treenaks> no US keyboards I have have a  on them
<HiddenWolf> Just the dollar. (me is still looking for the euro sign)
<fabbione> pitti: got the mail..
<smurfix> OK, I'll teach the thing to avoid it
<Treenaks> HiddenWolf: right-alt + 5
<fabbione> pitti: i have -32 ready for upload as soon as RC is out
<smurfix> HiddenWolf: Here it's +e
<fabbione> pitti: i think we will have to wait for an USN to fix that bug if there is no patch yet
<fabbione> pitti: i need to go out 20 minutes and i will be back
<pitti> sure
<fabbione> daniels_: ping???
<mvo> smurfix: better now? http://people.ubuntu.com/~mvo/update-notifier-panelicon.png
<pitti> mvo: cool :-)
<smurfix> mvo: Better, though I think the exclam's dot should have a separate outline
<HiddenWolf> How long untill RC is out? I'm holding off to install a new rig here. 
<mvo> HiddenWolf: did you got my mail about #7517?
<HiddenWolf> mvo: I haven't seen the bug recently. Perhaps it was already fixed in gksu
<mvo> HiddenWolf: ok, thanks
* HiddenWolf isn't totally happy to upgrade now, to check, since he'd have to download 99 updates including kernel, evo and x
<mvo> HiddenWolf: please let me know if you see it again
<HiddenWolf> mvo: ofcourse, but I'll move to amd64 as soon as RC is out. 
<dholbach> hai
<mvo> hey dholbach 
<dholbach> hey mvo :-)
<pitti> Hi dholbach 
<Jeeves_>  * Handling repository: rsync://archive.ubuntu.com/ubuntu/
<Jeeves_> @ERROR: max connections (15) reached - try again later
<Jeeves_> Argh.
<Treenaks> again?
<Jeeves_> Jups. 
<Jeeves_> Why is the limit only 15 btw?
<dholbach> hey pitti
<Jeeves_> Treenaks: btw, why do I want to become 'nl.archive.ubuntu.com' ?
<thom> Jeeves_: because rsync *hurst* servers
<Treenaks> Jeeves_: because you're nice, and you have heaps of unused bandwidth?
<Jeeves_> Treenaks: Ow, really? :)
<Treenaks> Jeeves_: well, at least the last part
<Jeeves_> Treenaks: Perhaps, but the question is, when is my boss going to send me bills? :)
<Treenaks> Jeeves_: I can't answer that for you ;)
<sPoof_> mdz: 'morning. Have you had a look at the MoinMoin package(s)?
<Jeeves_> Anyways, the mirror box has enough bandwidth. But I can't keep the mirror up to date when the master is unreachable. :)
<sPoof_> Anybody knows what hours mdz can be expected to be active here?
<Kamion> sPoof_: he's in the Western US; roughly working hours + some
<sPoof_> Kamion: Thanks.
<sPoof_> Anyone interested in testing new MoinMoin package on ubuntu (or should I ask somewhere else?)?
<Jeeves_> Lunch!
* Kamion starts his install CD test cycle
<Treenaks> try #ubuntu-motu
<HiddenWolf> Kamion: did you fix that amd64 daily breakage?
<Kamion> HiddenWolf: yes, ages ago
<Kamion> (time dilates during these release things)
<HiddenWolf> Kamion: what was it?
<pitti> Kamion: hi
<pitti> Kamion: is the ia64 CD okay now? or still too big?
<pitti> Kamion: I don't see it any more in daily/
<Kamion> HiddenWolf: same thing it was diagnosed to be from the start :)
<Kamion> HiddenWolf: an archive-copier segfault
<seb128> pitti: we don't build ia64 for hoary IIRC
<mvo> Kamion: i386 installed fine today
<Kamion> pitti: right, what pitti said, mdz asked me to stop building it
<pitti> ok
<Kamion> HiddenWolf: 1 in 4096 chance depending on the combined sizes of the Packages files on the CD, which is why we'd never seen it before - it wasn't amd64-specific
<Kamion> pitti: er, s/what pitti said/what seb128 said/ of course :)
<pitti> Kamion: I know :-)
<seb128> :)
<fabbione> hey Kamion 
<HiddenWolf> Kamion: ok, cool - I'll go and wait patiently for my amd64-install RC then. :)
* thom jigdos
<fabbione> Kamion: btw.. this morning i found a "problem" with archive-copy
<fabbione> either my media are crap or the cd-reader is not that good
<fabbione> but basically there were problems copying the debs to the hd
<fabbione> and there was no error reported from archive
<fabbione> going into phase2 the installer correctly asked for the CD again
<fabbione> but imho archive-copier should inform of these problems 
<fabbione> otherwise you don't get to see the issue with broken media until that point
<Kamion> yeah, I saw your comment - I'm confused though, 'cos archive-copier already does have pretty paranoid error checking
<Kamion> it's set -e throughout
<Kamion> and
<Kamion>     cp -a "$cdromfile" "$cachefile" || \
<Kamion>         die archive-copier/copy-failed \
<Kamion>             "'cp -a \"$cdromfile\" \"$cachefile\"' failed with code $?"
<Kamion> which should log an error, present a priority critical note, and exit
<fabbione> hmmm weird....
<fabbione> i can reproduce the problem almost always
<Kamion> but send me /var/log/installer/syslog and I'll take a look
<fabbione> ok
<fabbione> i will as soon as i will reinstall again
<fabbione> food time..
<fabbione> i am starving :)
<Kamion> jdub: mozilla-firefox home page is still a local file from ubuntu-artwork talking about 4.10 and warty
<Kamion> jdub: hope that's on your queue to fix before final
<thom> i *really* need a kvm
* thom digs under his desk for the second monitor cable
<pitti> Argh, I'm stupid
<pitti> >>> "2.9.10-0ubuntu1" >= "2.10.0-0ubuntu2"
<pitti> True
<haggai> lamont: please requeue kdesdk/i386 when you wake up
<mirak> hi
<mirak> I have seen that ubuntu have is own UMS mounting rules. I am interested in having a smaller cache for async transfers, I wanted if it's customisable or if it's depends of the kernel fat32 module 
<Treenaks> UMS?
<mirak> usb mass storage
<mirak> I ask here but I shoul ask in the other channel I gues
<mdke> anyone home here? I would like to know how to post a bug on a universe package?
<pitti> "Use malone, Luke"
<pitti> :-)
<mdke> ok
<mdke> thanks pitti 
<pitti> https://launchpad.ubuntu.com/malone/
<pitti> mdke: that is our crack-of-the-day bugtracking system that is now used for universe bugs :-)
<mdke> right
<fabbione> Kamion: is dmidecode available within d-i?
<toresbe> what is ".desktop"?
<seb128> what is ".png" ?
<Treenaks> what is ".so"?
<pitti> d00des!
<pitti> seb128: I now have a fix
<seb128> pitti: cool
<pitti> seb128: I stole a Debian version class from sourcerer
<seb128> :)
<mdke> k thanks pitti
<mdke> filed
<toresbe> oh, it's a file estension
<toresbe> extension!*
<toresbe> sheesh
<seb128> pitti: python-apt has a apt_pkg.VersionCompare() though
<pitti> oh, neat
<seb128> /usr/share/doc/python-apt/examples/versiontest.py
<seb128> for an example
<seb128> >>> apt_pkg.VersionCompare("2.9.10-0ubuntu1", "2.10.0-0ubuntu2")
<seb128> -1
<seb128> >>> apt_pkg.VersionCompare("2.10.1-0ubuntu1","2.10.0-0ubuntu2")
<seb128> 1
<pitti> cool, thanks seb128
<seb128> np
<pvanhoof>  How come there isn't a  "/lib/modules/2.6.10-5-686/build" ?
<pvanhoof>  and which package would provide it, or, how can I build it from source?
<seb128> Kamion: the "Choose language" title in the installer seems to be not translated in french but the po file has:
<seb128> msgid "Choose language"
<seb128> msgstr "Choisir la langue/Choose language"
<Treenaks> pvanhoof: linux-headers-`uname -r`
<seb128> Kamion: is the current i386 install CD supposed to have updated translations ?
<pvanhoof> ok
<pvanhoof> looks like that is working indeed
<Kamion> seb128: yes; it wouldn't be translated, the installer still thinks you're in English at that point remember
<Treenaks> pvanhoof: it's better to ask "support" type questions in #ubuntu or #ubuntu-nl
<Kamion> fabbione: there's a dmidecode-udeb I think, can't remember if anything uses it
<pvanhoof> Treenaks, yes, well.. here they (you) actually answered the correct solution :)
<fabbione> Kamion: ok thanks. we might need it for multiseat
<Kamion> seb128: if you go back to the main menu you should see the French version
<thom> Kamion: laptop-detect does
<Kamion> thom: dmidecode-*udeb*?
<seb128> Kamion: the description is translated on the same screen ...
<Kamion> dmidecode-udeb doesn't appear to be in main at the moment
<seb128> Kamion: that's the screen to selection the geographic area
<seb128> after the language selection
<thom> there's a laptop-detect udeb isn't there? (or did we decide not to go down that path?)
<Kamion> seb128: oh, it maybe just doesn't remember to reset the dialog title
<thom> Kamion: there's a laptop-detect udeb, but i don't know if anything uses *that*
<Kamion> would require some hairy code in localechooser I guess
<seb128> k
<Kamion> seb128: it'll work in Debian because they're still using separate language/country choosers
<pvanhoof> A few weeks ago I posted a proposal for the quickcammes module, which adds support for Logitec Quickcam messenger, tot he mailinglist. Did somebody picked this up? I've wrapped the module in an easy-to-build build environment and did some bugfixes to it. You can find more information here: http://freax.be/wiki/index.php/Quickcam_Messenger_Linux_kernel_2.6_driver (please forward it to a kernel-packager, it would be nice if it was support 
<pvanhoof> and a few people already asked for packages)
<Kamion> seb128: one of your countrymen is responsible for the combined localechooser ;)
<Treenaks> pvanhoof: try that on #ubuntu-motu (they maintain universe)
<Treenaks> pvanhoof: which driver is this btw? (original url)?
<haggai> Kamion: did another kubuntu test install.  It did use packages off the CD, so that's ok.  Although it did go to the net without asking me for secu updates and the langpack
<seb128> Kamion: who ? :)
<Kamion> haggai: just apt-get update, or actual packages?
<Kamion> haggai: oh, and did it install kde-i18n-*? (ignore this question if you did an English install)
<Kamion> seb128: bubulle
<Kamion> haggai: if actual packages, could you mail me /var/log/base-config.log?
<pvanhoof> Treenaks, it's linked on that page
<pitti> Kamion: will you build a new set of CDs for the RC for any reason?
<Kamion> pitti: it's still possible, but I hope not
<pitti> Kamion: ok
<pvanhoof> Treenaks, there's a package for normal Quickcams in ubuntu, however, a) it requires that you still build it (some wieerd way of installing itusing source packages) and b) it doesn't support the messenger (which is slightly different)
<Kamion> pitti: why?
<haggai> Kamion: ok you're right it was only an apt-get update
<pitti> Kamion: I fixed a stupid bug in langpack-o-matic that caused old translations to be included in some cases
<Kamion> haggai: ok, I can cope with that
<pitti> Kamion: but it's not a real showstopper, I think
<Treenaks> pvanhoof: the quickcam upstream people should agree on a module name and merge, or disagree on it and completely split
<Treenaks> pvanhoof: and then put ALL resulting source in the mainline kernel
<pitti> Kamion: what about uploading them? Shall I do this after RC release, or right now?
<Kamion> pitti: yeah, people installing the RC will get that fix in updates anyway
<Treenaks> pvanhoof: in the mean time, I think providing build instructions is the easiest we can make it
<haggai> Kamion: I did a UK lang install and it had a brief error msg about the kde-i18n package
<Kamion> pitti: can you hold off for an hour or two until I know what's happening?
<pitti> Kamion: "them" == new langpacks
<Kamion> haggai: yeah, it's known-broken for en
<pitti> Kamion: sure
<pvanhoof> Treenaks, I'm not yet going to clean it up (I lack the time). But will in a near future, and propose it to the kernel mailinglist
<haggai> Kamion: k
<Treenaks> pvanhoof: also, the "originial" official site is http://home.mag.cx/messenger/source/
<Kamion> haggai: figured it wasn't too much of a showstopper because American English is comprehensible
<haggai> Kamion: righty
<pvanhoof> Treenaks, also .. I don't think the original developers are still working on it atm. and since I needed it asap I decided to do some quick-hacks first. but sooner or later it got in a usable state
<Kamion> haggai: (basically I need to make it try both kde-i18n-$LL and kde-i18n-$LL$CC without spewing too many annoying error messages
<pvanhoof> so I've put it on a wiki-page .. and now people start asking for packages :) thats the story
<Treenaks> pvanhoof: I mailed the mag.cx guy for a while when we were debugging my camera
<pvanhoof> ok
<Kamion> haggai: might still be able to fix that for final though
<Kamion> mdz,sabdfl: my test installs here are 3/3; I'm go for RC
<pitti> seb128: it affects gedit, glade-2.0, libgnomeprintui, libgtop, update-notifier, gnome-session, base-config, eog
<Kamion> pitti: I hope it doesn't affect base-config :)
<pitti> Kamion: wrt. outdated translations
<pvanhoof> well, for inclusion in the kernel .. all those ifdefs should or become if's (to let one driver support all logitecs), or be removed (don't try to support old kernels, don't try to support all logitec devices since they are different anyway, etc)
<pitti> oh right, we don't strip it
<Kamion> pitti: base-config is supposed to be blacklisted
<Kamion> yeah
<pvanhoof> atm the code is rather .. well, ugly :)
<pvanhoof> I mainly polished the build environment
<Treenaks> pvanhoof: it should be cleaned up
<pvanhoof> it's okay and it works .. but indeed, ugly
<Treenaks> pvanhoof: so the "similar" logitechs are in one driver I guess
<pvanhoof> and there's one little bug: you need to rmmod and modprobe after booting your kernel (else you get a black screen)
<Treenaks> pvanhoof: another benefit of a driver being in the mainline kernel is "less breakage on api changes"
<pitti> seb128: btw, does the live CD give you a correct resolution? That worked for m
<pitti> seb128: me
<pitti> Hi elmo
<elmo> hi pitti
<pvanhoof> yes, well.. but I need time to merge it .. or clean it up (as a separate module), take a look at the current logitech module and check whether this device can easiliy be supported using that, etc etc
<elmo> Kamion: ?
<pvanhoof> it's something I have on my agenda :). But if you want to join me , perhaps I'll move that agenda-item forward :)
<pitti> dholbach: btw, how does malone perform so far?
<Kamion> elmo: yo?
<ogra_live> fabbione, around ?
<fabbione> ogra_live: yes
<elmo> Kamion: hmm, nm, it's a stupid question - there's no reason to stop d-i dailies yet
<ogra_live> fabbione, psmouse.c: TouchPad at isa0060/serio4/input0 lost sync at byte 1
<ogra_live> i have a lot of this in my dmesg...
<Treenaks> pvanhoof: just tell me how/what I can do
<pitti> Hi ogra_live 
<fabbione> ogra_live: meh.. if the mouse work it's harmless
<ogra_live> hi pitti 
<ogra_live> ok
<Kamion> elmo: no, indeed we're probably going to need them still
<pitti> seb128: odd, the build log says "Publishing chroot-hoary/build/buildd/gdm_2.6.0.7-0ubuntu7_translations.tar.gz for rosetta.", but the tarball isn't anywhere
<ogra_live> the new login option should dissapear from the menu on the live cd
<pvanhoof> Treenaks, well, atm it looks like the make install step is installing the .ko binary in an incorrect location (it's standard kbuild). I'm not understanding why
<pvanhoof>  make -C $(KSRC) SUBDIRS=`pwd` modules_install
<seb128> pitti: not tried the liveCD yet, I'm playing with the i386 install atm
<pvanhoof> so thats make -C /lib/modules/2.6.10-5-686/build SUBDIRS=`pwd` modules_install
<ogra_live> if i end gdm after Applications->System Tools->"new login" my screen is locked....missing a password i cant unlock....
<Treenaks> pvanhoof: let's continue on some other channel :)
<pvanhoof> ok :)
<pvanhoof> privmsg? -motu?
<Treenaks> pvanhoof: see invite
<pvanhoof> ok
* tausq thanks haggai :)
<Kamion> sabdfl: BTW, yesterday I did that pre-release publish to .pool thing you asked for - though http://releases.ubuntu.com/.pool/ doesn't actually show it yet
<Kamion> elmo: did you manage to trigger maswan?
<cc> ogra_live: i'd say reboot, and it usually disappears. thats the synaptics just gone wonky. it happens sometimes (and truthfully, its kernel interface related)
<maswan> Done at Tue Mar 29 22:59:04 MET_DST 2005
<maswan> last releases sync
<maswan> wrote 588 bytes  read 3806792168 bytes  1356903.50 bytes/sec
<maswan> Kamion: seems to have worked
<Kamion> maswan: wonder why you don't have hoary-rc-install-i386.iso etc.
<maswan> .pool/hoary-rc-install-i386.iso
<maswan> it was synced in
* Kamion doesn't see it
<maswan> http://ftp.acc.umu.se/ubuntu-releases/.pool/
<maswan> it's there
<maswan> just not linked in
<Kamion> oh, nm, I was looking at releases.ubuntu.com, I thought that was still you
<maswan> ah, no, elmo pointed that back. we're back to se.releases.u.c only again
<Kamion> elmo: in that case, any clue why releases.u.c/.pool/ is out of date?
<elmo> Kamion: no, frei reckons there's nothing to rsync?
<Kamion> elmo: odd
<elmo> what's missing?
<Kamion> it's definitely missing hoary-rc-*
<elmo> err?
<Kamion> and indeed the MD5SUMS file is out of date
<elmo> archvsync@frei:/srv/releases.ubuntu.com/www/releases/.pool $ ls -l hoary-rc-*
<elmo> -rw-rw-r--    1 archvsync archvsync 646940672 Mar 30 02:49 hoary-rc-install-amd64.iso
<sabdfl> Kamion: excellent, thanks!
<pitti> ogra_live, dholbach: I reviewed the CAN db yesterday; there are a bunch of packages that are vulnerable in hoary, but fixed in Debian
<elmo> oh, boggle
<sabdfl> so basically there's a seed, hidden away, and on the day the rsync can be minimal
<elmo> we seem to have ended up with two trees
<sabdfl> cool
* toresbe conciders running a Ubuntu AMD64 hoary livecd
<pitti> ogra_live, dholbach: shall I write them down, and you want to sync them?
<ogra_live> pitti, that would be nice
<Kamion> sabdfl: right - it remains to be seen how frequently releases.u.c mirrors sync in practice, I guess
<elmo> Kamion: fixed, resyncing now
<ogra_live> cc, its always there
<Kamion> sabdfl: I've changed the .pool filenames so they reflect the state of the release (hoary-rc-*, hoary-release-*, whatever) so that we can have multiple of them at once - only drawback is that that'll cause disk space usage spikes just before a release, but I don't think there's anything to be done about that
<Kamion> elmo: thanks
<pitti> ogra_live: okay to sync ethereal? this is the most urgent issue, I think
<pitti> ogra_live: what about your freeze status?
<ogra_live> yup
<pitti> elmo: please sync ethereal
<ogra_live> pitti, we freeze a minute before release ;)
<ogra_live> pitti, as late as elmo allows :)
<pitti> ogra_live: since universe does not touch any CDs or our main archive, it shouldn't matter much :-)
<ogra_live> right :)
<sivang> hey all
<sivang> fabbione: do we have a problem with kernel-headers-2.6-686-smp ? it seems uninstallable
<fabbione> sivang: not that i know off.. i have all the headers installed here
<sivang> fabbione: hmm
<fabbione> ah kernel!
<fabbione> no
<fabbione> kernel -> univers
<ogra_live> universe
<fabbione> linux-headers-2.6-686-smp <-
<sivang> universe?
<sivang> wow
<sivang> since when ? :-)
<ogra_live> always
<fabbione> sivang: since warty?
<sivang> fabbione: meaning -smp is not officially supported? I don't understand, sorry.
<pitti> sivang: linux-headers, not kernel-headers
<ogra_live> sivang, kernel not officially supported
<sivang> pitti: ah ok, thanks
<sivang> that was a name mismatch, thanks folks
<sivang> :-)
<ogra_live> :)
<thom> Kamion: current daily on ppc looks good here, btw
<Kamion> thom: cool
<thom> should pxeboot ever play ball, i'll let you know how that goes
<Kamion> I think we're just waiting for mdz to wake up and say go
<thom> nod
<thom> (and dear god my ppc brings whole new meanings to the word slow. even the ia64 is faster! :P)
<dholbach> re
<dholbach> pitti: would be too charming if you gave us your list
<dholbach> pitti: malone still encouters backend problems (afaik); bradb wanted to give us the green light at some stage, so we can unleash the users
<bradb> word-of-mouth is still the preferred way to let people know about it
<bradb> if it's announced to ubuntu-users, i wouldn't be surprised if it ended up on slashdot not long after, and then we'd be in trouble :)
<dholbach> ok
<pitti> bradb: would be a good test, though :-)
* Treenaks posts a link on slashdot
<pitti> argh
<pitti> thom: here?
<bradb> i don't think it'll help anybody if it hits slashdot before we have 24-hour admin availability
<thom> pitti: yo
<pitti> thom: I started to import the CAN database into http://people.ubuntu.com/~pitti/ubuntu-cve.html
<pitti> thom: please have a look at the "Unfixed issues in main", section "warty"
<pitti> :-(
<thom> pitti: mostly moz*?
<pitti> yeah
<pitti> and that's not even everything, I just started
<thom> ouch
<pitti> elmo: please sync unace
<elmo> pitti: done
<pitti> thanks
<pitti> ogra_live, dholbach: so are you okay if I request syncs directly rather than giving you a list?
<dholbach> pitti: should be ok... if you encounter trouble, we'll look it up for you - thanks :-)
<pitti> elmo: please sync maxdb-7.5.00, dillo, and squirrelmail as well
<elmo> pitti: doing
<pitti> ogra, dholbach: for breezy it might be considered to not stop the automatic Debian sync of universe as early as for main
<pitti> ogra, dholbach: as long as nobody really cares for the packages, they might as well get at least Debian love
<ogra> great, but we will also be more MOTUs then 
<dholbach> yeah... :-)
<pitti> Mithrandir: gah, we really need tbird 1.0.2, unless you want to start a patching hell...
<Mithrandir> pitti: sorry, I forgot to talk to mdz. :(
<Mithrandir> mdz: approval for thunderbird 1.0.2?
<jani> elmo, re yesterdays ruby1.8 in main, from what I see librdf-ruby ( redland-bindings ) is in universe so it's only libswig that depends on libruby1.8, am I right?
<seb128> Kamion: the "Time zone configuration" is not translated here with an iso uploaded this morning. The translations should be uptodate ?
<elmo> jani: redland-bindings b-d's on ruby which means it has to be in main
<elmo> build-depends count as much as depends, for determining main vs. univerness
<thom> Kamion: pxeboot i386 looks good
<ajmitch> ogra: 10x as many, I'd think ;)
<jani> elmo oh ok I looked with apt-cache rdepends. What tools do you use to query ? I'll gladly RTFM :)
<elmo> jani: I use the output of germinate
<jani> is it accessible to us?
<elmo> which is, err, somewhere under people.ubuntu.com/~cjwatson/, I think
<elmo> if you google the wiki, for 'germinate' it should tell you
<jani> ok thanks, is this ubuntu specific or just not yet made into the debian toolset?
<jani> got it nevermind
<fabbione> pitti: most of the CAN that are "Unchecked" are actually fixed
<pitti> fabbione: yeah, I'm currently walking down this list and mark them in my db
<pitti> fabbione: this list is the outcome of my filtering from yesterday
<pitti> fabbione: so far I only threw out CANs that don't affect Debian and Ubuntu at all
<Kamion> seb128: the translations are up to date, it's a bug in the way locales aren't set up in time for the questions pulled back to the first stage; I mentioned it yesterday and hope to fix it post-rc
<Kamion> jani: Ubuntu-specific, at least for now
<Kamion> jani: free software though
<fabbione> pitti: yes, but some of them have been fixed nevertheless
<seb128> Kamion: k, thanks
<pitti> fabbione: I know, these are the ones I mark now
<fabbione> ok
<fabbione> i also think that you didn't forward to me some of them :)
<fabbione> like 0867
<pitti> fabbione: this list will be useful after I finished reviewing it
<fabbione> right
<pitti> fabbione: 867 is on my list
<Kamion> seb128: (if you run 'chroot /target localedef -i fr_FR -c -f UTF-8 -A /etc/locale.alias fr_FR.UTF-8' while archive-copier's running, you should get the correct translations; the fix will be to do something like that automatically
<Kamion> )
<fabbione> pitti: ok.. let me know when you have finished your review
<pitti> fabbione: so far this is the only issue I didn't yet forward
<fabbione> pitti: this evening there is a kernel team meeting
<fabbione> and we can take a look at the issues all together
<pitti> fabbione: if you have some time, maybe you can look at the SuSE patch for 867?
<fabbione> pitti: also 0916 (for ia64)
* Kamion goes off to relax for a bit; if mdz's looking for me, I expect to be back around 1400 UTC
<pitti> fabbione: uh, I'm currently at -299
<pitti> will still take a while...
<fabbione> ehehe ok
<fabbione> pitti: i guess i need to get SUSE sources to find the patch....
<pitti> yeah
<pitti> there haven't been patches at the ML
* fabbione sighs
<pitti> these suckers.. :-)
<fabbione> they do...
<seb128> Kamion: nice, thanks
<fabbione> pitti: i need a break before i can start to work on this right ahead
<fabbione> pitti: i will work with them together with the kernel team immediatly after RC
<fabbione> pitti: i am afraid most of this stuff will land in a USN
<fabbione> elmo: if you have time can you kill 2.6.11 from universe?
<mdke> jdub, ping
<fabbione> linux-source-2.6.11
<trulux> fabbione: hey
<pitti> elmo: please sync ethereal, firehol, wu-ftpd, armagetron, horde2
<fabbione> hi trulux
<trulux> fabbione: do you plan to get the networking hooks for any -subrelease?
<trulux> for 2.6.10
<fabbione> trulux: no. it will be breezy business
<trulux> ok
<trulux> great anyways
<pitti> elmo: ipsec-tools sync as well, please
<Amaranth> Have any of your read "Improving Application Performance Through Space Optimizations" from Red Hat?
* pitti has to go for an hour
<elmo> pitti: done
<pitti> thanks
<elmo> pitti: err, not done
<elmo> ethereal is ubuntu modified - okay to override?
* pitti looks
<Amaranth> wait, i think i remember someone in #ubuntu-motu doing a lot of work on that
<Amaranth> it might have been ethereal-dev
<pitti> elmo: hmm, that needs a merge
<pitti> ogra, dholbach: can one of you (or a delegate) please merge the new ethereal version from Debian? It fixes ~ 5 CANs
<dholbach> pitti: will do
<pitti> thanks
<pitti> dholbach: this tool is very famous, so it should be fixed for Hoary
<dholbach> pitti: working on it
<Amaranth> now to remember who was working on it :)
<dholbach> pitti: so i grab the sid version?
<pitti> dholbach: and merge the Ubuntu changes
<dholbach> ok
<pitti> dholbach: http://people.ubuntu.com/~scott/ongoing-merge/ethereal/ethereal_ubuntu.patch
<pitti> dholbach: however, this seems to be out of date
<pitti> dholbach: there is a 0.10.4-3ubuntu2 which is not in the ubuntu patch
<pitti> dholbach: please ask Keybuk to update it
<dholbach> pitti: yeah i'll use that one, no need for keybuk to worry
<pitti> okay, really gotta go now. back in an hour or so
<dholbach> *wave* pitti*
<elmo> release.u.c is going down for a couple of minutes
* fabbione goes and crashes - be back in a hour or so
<elmo> iz back
<dholbach> should i be able to upload a signed source package to upload.u.c with any ftp program? (i need to restrict it to 12k/s to not break my connection with 7.5Mb upload)
<dholbach> (dput is afaik not able to)
<spiv> dholbach: trickle would probably solve that.
<dholbach> spiv: *having a look* thanks
<seb128> i386 install goes fine
<jani> dholbach or wondershaper
<dholbach> jani, spiv: i'll give trickle a go... thanks :-)
<elmo> ARGH
<elmo> PITTI
* maswan hands elmo a 3.5 kg sledgehammer
<thom> Kamion: amd64 looks good to go too for me :-)
<elmo> WOO
* thom wonders what elmo's broken now
<maswan> http://www.acc.umu.se/images/archive/20000712-Nodstopp/index.html?view=DSC00007.JPG <- like that, to implement a "data retention policy". :)
<elmo> we are now out-of-date clean, uninstallable clean, rene clean, anastacia clean
<seb128> thom: grumpf, I get this crasher on a fresh i386 install
<seb128> the gtk/fileselec one
<thom> seb128: hurrah!
<seb128> nop, not hurry
<thom> seb128: well, at least you can reproduce it now
<seb128> the bt is crap, full of "??" even with the -dbg packages
<thom> are you only seeing it with firefox?
<seb128> no, I don't run that stuff
<seb128> gedit
<thom> Kamion: huh. "The hardware clock says the time is now ." that seems like a regression; definitely used to work
<thom> seb128: hrmph
<zul> hey
<Kamion> thom: yeah, missing /dev/rtc or whatever it is in /target
<Kamion> elmo: w00t
<zyga> hey
<mvo> hey zyga 
<zyga> mvo: hey
<zyga> mvo: you were telling me about new features for breezy yesterday
<zyga> mvo: BTW: I've made l10n improvement for update-manager, dates are now printed according to current locale - will send patch later
<mvo> zyga: nice, thanks
<Mithrandir> hm, is there any sane way to get php4 for apache1 in hoary?
<zul> compile it from source? :)
<Mithrandir> apart from that, obviously. :P
<zul> heh
<pitti> ogra: darn, Ubuntu's security reputation will suffer from this: http://www.heise.de/newsticker/meldung/58038 :-)
<zul> pitti: in english?
<pitti> zul: CAN-2004-1073 is not fixed although we claimed so ("we" = all Linux distros)
<pitti> zul: but they mention my name in the article...
<zul> heh
<ogra> pitti, wow, they wrote it as if ubuntu discovered it....
<Treenaks> ogra: didn't we? :P
<ogra> dunno, pitti, did we ?
<pitti> ogra: no
<ogra> thats what i thought, but on first sight the report looks like :) 
<ogra> great promotion...
<dholbach> brb
<srbaker> the new ubuntu theme looks excellent
<dholbach> pitti: done
<srbaker> i still don't like the shit brown choice of colour, but it's better than before
<pitti> dholbach: ethereal?
<pitti> oh, I see it on -changes
<elmo> pitti: dude, ipsec-tools is in main
<mdke> is the copy -> close program -> can't paste issue known?
<Amaranth> yes
<mdke> phew
<mdke> that is megaserious
<Amaranth> not an ubuntu bug, it's a GTK/X thing
<Amaranth> it's been like that as long as i can remember
<mdke> its not like that in warty i don't think
<Mithrandir> it is, and it'll be fixed, but not now
<mdke> cool
<Amaranth> wouldn't be the first time my memory failed me :P
<Mithrandir> I think you can work around it by using a clipboard manager.
<mdke> just couldn't find it in bugzilla
<Mithrandir> it's probably in the gnome bugzilla
<Amaranth> someone tried to explain the work that would go into making it work properly and i went crosseyed
<mdke> Amaranth, uhoh
<Amaranth> take copying from gnumeric, for example
<Amaranth> depending on where you copy to it'll end up in any number of formats
<Amaranth> do you want to store all that in RAM? :)
<Amaranth> every format of the copied data would have to be loading into the clipboard manager to make sure you don't lose anything
<mdke> hmm
<mdke> how does windows do it?
<Amaranth> Good question.
<mdke> maybe just dumps it in ram as you suggest
<Amaranth> no, from the sound of it this would be gigs of data
<Amaranth> they probably don't have as many formats
<Amaranth> i can see it being the format it started as and text
<Amaranth> with MS Office of course having it's own techniques for handling it's formats
<mvo> ping Riddell 
<Riddell> mvo: hi
<mvo> Riddell: I'm just looking at #7395 (no desktop file for synaptic in kde). I guess there is something like gksudo for kde? I think I will add a extra desktop file for kde and it would be nice to have the kde aquivalent of gksudo in it
<Riddell> mvo: add this to the .desktop file
<Riddell> X-KDE-SubstituteUID=true
<fabbione> re
<Amaranth> hey, my menu editor got it's own section on ubuntuforums.org
<ross> Amaranth: in windows if you copy lots of data and close the application it checks if you want to take up huge amounts of memory on the clipboard
<mvo> Riddell: ok, thanks. 
<Amaranth> ross: hmm, i think i remember MS Office doing that
<Amaranth> other apps never did though
<ross> Amaranth: what windows does with the clipboard is well documented, there are two totally different methods in windows
<ross> office just used the new (decent) and old api, other apps only used the older crap api
<fabbione> mdz: around?
<fabbione> hey daniles
<daniels> fabbione: !!!
<daniels> wassup
<fabbione> nm..
<seb128> hi daniels 
<fabbione> and you+
<fabbione> daniels: i had to upload xorg -7 yesterday
<daniels> fabbione: yeah, I saw that, thanks
<seb128> daniels: you broke my xorg dude, that's not the moment to start breaking configs :p
<fabbione> daniels: there is only one line fix in postinst.in
<fabbione> seb128: iz gtk buz
<seb128> ah ah
* seb128 slaps fabbione 
<Mithrandir> daniels: got my X config stuff?
<daniels> Mithrandir: yeah, thanks
<daniels> fabbione: yeah, did you get that off the deb I made for mdz on davis, or did we both just come up with the exact same fix? :)
<fabbione> daniels: no, i used the message on the mailing merged with the stuff on davis to understand where to apply the change
<daniels> cool
<elmo> Kamion: ?
<Kamion> elmo: yo?
<elmo> Kamion: one more mirror to trigger: 'durville.ubuntu.com'
<elmo> kamion: if this sounds crazy, I've updated /etc/rsyncd.conf on little, so you can see what's actually mirroring what
<elmo> kamion: + pls ;)
<pitti> elmo: the next bunch: phpmyadmin webmin prozilla drupal mlterm wine (TIA)
<elmo> pitti: did you see my comments about ipsec-tools?
<pitti> elmo: erm, no?
<pitti> Ubuntu changes?
<Kamion> elmo: done
<elmo> pitti: it's in main :-/
<elmo> kamion: thanks
<pitti> elmo: argh
<pitti> elmo: okay, then it wanders on my todo
<elmo> pitti: too late, it's done
<elmo> but I'm so snitching on you to mdz
<pitti> hrm, f**k
<Kamion> it's not on the CD at least
<elmo> pitti: anyway, syncing that lot now
<pitti> mdz: ping
<pitti> daniels: my flatmate experienced the xorg bug too (for the records) :-)
<daniels> pitti: yeah, I've already fixed it
<pitti> daniels: cool
<daniels> purging xserver-xfree86 (rather than removing) should fix it
<mvo> Riddell: what do I need to do to make kde re-build it's K-Menu (reread the desktop-files)?
<fabbione> Riddell: did you see that kdesdk is still FTBFS?
<fabbione> Riddell: wouldn't be an option to at least try to build the packages in a clean chroot before upload?
<pitti> fabbione: it seems that CAN-2005-0916 doesn't affect us
<fabbione> pitti: it seems or it doesn't? ;)
<pitti> fabbione: IA64 and PPC64 only
<_mvo_> Riddell: hrm, network touble. did you answered about the dekstop-file reread?
<fabbione> pitti: meh.. we have ia64
<pitti> fabbione: but not as an official release arch
<fabbione> i know.. still..
<pitti> fabbione: I don't mind if you want to fix it :-)
<fabbione> pitti: send me the patch and i will fix i
<fabbione> it
<pitti> http://linux.bkbits.net:8080/linux-2.6/cset%404248c8c0es30_4YVdwa6vteKi7h_nw
<fabbione> pitti: danke
<pitti> fabbione: gern geschehen :-)
<fabbione> pitti: that looks so familiar with.. hmmm an ABI change?
<pitti> YAY
<fabbione> i will look at it after RC, if it changes the ABI we can sneak it later, if we will hit a more serious problem with same effect
<smurfix> fabbione: looks like it's all #defines, not an ABI change
<ogra> ouch
<pitti> but the #define is in a .h file
<pitti> it might be used from outside
<smurfix> pitti: so?
<fabbione> smurfix: i still prefer to double check stuff :)
<smurfix> pitti: that'd be an API change then, but the binary would still work
<fabbione> smurfix: the ABI checker is free
<smurfix> fabbione: true
<pitti> smurfix: hmm, right
<ogra> pitti, hwdb has 637 submissions since yesterday, i already found 5 of them not using ubuntus hal version (dmidata, processor and lsb_release are missing) heh
* ogra damns the sid crossgrading....
<pitti> nice 
<pitti> ogra: that cries for stricter dependencies
<trukulo> ogra, graveman offically is in sid now (yesterday)
<pitti> ogra: I fix the dependencies after RC
<ogra> yep
<Kamion> pitti: is it actually a dependency, though?
<Kamion> or just some missing information?
<ogra> pitti, me too, hwdb depends on hal, but not versioned yet
<Kamion> trying to declare a strict dependency on Ubuntu's version of something will bite you
<ogra> i'll do a >=
<daniels> ogra: won't help if debian gets a newer version
<Kamion> no, that doesn't help. e.g. if you depend on foo (>= 0.1ubuntu1), as soon as foo 0.2 exists then that will still satisfy it
<pitti> Kamion: I thought about a >=, but well, Debian's version may be newer
<daniels> 0.9.7-1 >> 0.9.6-2ubuntu1
<Kamion> this is why we need feature deps
<Kamion> in the meantime it's best to keep dependencies light
<ogra> trukulo, ok, i'll put it on my sync list...
<smurfix> damn
<Kamion> anyway simple dependency structures make the whole system more robust
<smurfix> the new version of the keymap tree will ask *ten* "do you have that key" questions for people with US keyboards
<trukulo> ogra, have you seen gnome-menu-editor?
<smurfix> I know how to fix that, but it's definitely a post-release solution
<ogra> trukulo, Amaranths version he currently develops ? or the CVS snapshot on gnome.org ?
<pitti> elmo: okay, this is the last round: ltris dnsmasq smail smarty (all universe :-) )
<pitti> elmo: I finished the review, so I won't bother you any more. Thanks so far :-)
<trukulo> ogra :) i mean upstream on gnomefiles, forget it, you seem better informed than i am
<trukulo> http://gnomefiles.org/app.php?soft_id=867
<elmo> pitti: done
<pitti> great
<pitti> universe is in a good condition now :-)
<trukulo> Amaranth, have you seen that url?
<Amaranth> I'm sunk. ;)
<Amaranth> Mine still looks better. :D
<_mvo_> Riddell: can you please /msg me when you around?
<trukulo> Amaranth, yours is in python, and that's really good in my opinion
<ogra> thanks pitti 
<Amaranth> the only feature he has that i don't have and care about is moving menu entries between menus
<Amaranth> which technically should work right now but i've honestly never tried :)
<trukulo> Amaranth, but the other needs patchs on menu, yours?
<Amaranth> on gnome-menus?
<Amaranth> mine just needs pyxdg 0.9 which is in hoary (my patches go upstream :)
<doko> mdz, Kamion: ok to upload the python 2.4.1 final release?
<Kamion> doko: we haven't finished with the RC yet
<fabbione> doko: mdz will send an email out when we are allowed to upload again to main
<doko> ok, thanks
<doko> uploads to universe should be ok?
<pitti> lamont: ping
<mdz> morning
<mdz> pitti: pong
<thom> mdz: morning
<mdz> fabbione: here
<fabbione> doko: probably yes
<pitti> Morning mdz
<thom> mdz: what problems were you having with the bittorrent stuff?
<mdz> Kamion: ready to go?
<mdz> thom: "connecting to peers" forever, as if there was no seed
<fabbione> mdz: http://kernelplanet.org/ <- look at the entry of the 29th of March about memset
<pitti> mdz: today I asked for a couple of universe syncs to fix security bugs (blessed by ogra/dholbach); unfortunately I also asked for ipsec-tools, which is in main
<fabbione> mdz: we could fix all the crap in a batch upload.. or almost
<trukulo> Amaranth, his program needs patching on gnome-menu : http://manny.cluecoder.org/packages/gnome-menu-editor/README
<pitti> mdz: it's a new upstream version all all that, shall I revert this immediately (with a funny version number) or do you want to keep it?
<pitti> mdz: sorry
<lamont> pitti: ack
<thom> mdz: huh. when i tried this morning it took about a minute when there was no-one else on the seed, then worked
<mdz> pitti: does it build and install?  can you test it?
<elmo> mdz: it built
<pitti> mdz: happened only a couple of minutes ago, I'll test it ASAP
<fabbione> meh, can't we stop it from enter the archive?
<Kamion> mdz: yep
<pitti> lamont: http://people.ubuntu.com/~lamont/buildLogs/g/gdm/2.6.0.7-0ubuntu7/gdm_2.6.0.7-0ubuntu7_20050329-0036-i386-successful claims that chroot-hoary/build/buildd/gdm_2.6.0.7-0ubuntu7_translations.tar.gz is published; however, the tarball is not there
<Kamion> mdz: ok to publish?
<elmo> fabbione: no, it happened hours ago
<fabbione> elmo: ah ok
<mdz> Kamion: CD images, yes; I didn't get as far as testing the DVD images
<mdz> pitti: does it have any open bugs in Debian that we closed NOTWARTY, e.g.?
<HiddenWolf> mdz: yay! Been waiting for em!
<Kamion> mdz: nor did I
* fabbione burns a DVD too
<daniels> mdz: as a heads-up, new xorg version about to land (another debconf oneliner, affects warty upgrades)
<Riddell> fabbione: kdesdk looks to have build ok
<mdz> daniels: we also have keymap fixes to make
<fabbione> Riddell: hmm after another kick back.. sorry i was looking this morning
<mdz> daniels: but if you have a version ready, let's get that in first
<elmo>  [TXT]   hoary_outdate.txt       30-Mar-2005 17:06  140
<elmo>  [TXT]   hoary_probs.html        30-Mar-2005 17:06  242
<elmo> mdz: just to counter all the negativity! ---^ ;-)
<Kamion> meh. er, nobody run sync-mirrors on little for a bit, please
<trukulo> Amaranth, your menu-editor doesn't seem to work here (deleting entries)
<Kamion> fortunately I took a backup
<mdz> elmo: and empty anastacia output :-)
<daniels> mdz: i have a version ready to go now (well, it's building -dbg as we speak), and then i can do -9 tomorrow/friday with keymap fixes (hr/nl)
<Amaranth> trukulo: Can you run it form a terminal?
* mdz does a little jig
<Amaranth> err, from
<trukulo> Amaranth, of course
<mdz> daniels: smurfix made a list for us, of all the keymaps which are likely to have this problem
<Amaranth> trukulo: I need to know if Python spits out any errors.
<daniels> mdz: oh.  where's that?
<mdz> daniels: so that we can apply the same fix to all of them preemptively if we want to
<mdz> daniels: scrollback about a day
<pitti> mdz: no, bugs are okay
<trukulo> no output in terminal
<Kamion> yay for cp -al
<pitti> mdz: I test the package now
<trukulo> no errors
<mdz> Mar 29 11:50:44 <smurfix>       mdz: The list is: am ar bg by dz el il ir iu jp
<mdz> lo mk ml mm mn ru th tj ua uz
<daniels> mdz: got it
<daniels> yeah
<Amaranth> trukulo: btw, the guy working on the other menu editor seems to be a little "passionate". :)
<smurfix> daniels: Actually there may be an alternate solution, but I don't think it's appropriate to try it at this time
<daniels> smurfix: now is not really the time to be trying new things, i'd imagine
<smurfix> daniels: exactly
<trukulo> Amaranth, could be, i just want give you a hand on this
<trukulo> :)
<smurfix> daniels: if you want to have a look, it's at /etc/X11/xkb/rules/xorg -- just uncomment the definition of $nonlatin
<trukulo> i didn't tried the other program
<Amaranth> trukulo: So no errors from Python when you try to delete?
<daniels> smurfix: ah, cheers
<smurfix> that also has a more exhaustive list than then one I collected
<trukulo> Amaranth, exactly, no error, with and without sudo
<Amaranth> :/
<trukulo> it writes on .config/menu/applications.menu
<trukulo> i use hoary updated from yesterday
<Amaranth> Is it deleted in the editor but not in the GNOME menus?
<trukulo> no, not deleted in editor neither
<Amaranth> What is it?
<trukulo> it's not deleted in any place
<trukulo> don't know
<Amaranth> No, what are you trying to delete?
<trukulo> kde programs
<trukulo> kooka, kcalc, ark...
<trukulo> installed by kubuntu-desktop
<Amaranth> Those shouldn't show up anyway. :/
<smurfix> daniels: I'd recommend you use the union of these lists for now, and we test whether enabling $nonlatin works post-hoary
<trukulo> they show on gnome menus in my system
<daniels> smurfix: sure, thanks for the pointer
<trukulo> and editor shows them
<Amaranth> trukulo: It's a bug that they won't delete but it's also a bug that they show up at all. KDE .desktop files should have an OnlyShowIn line that hides them in GNOME.
<mdz> Kamion: hmm, so what about kubuntu?
<Riddell> Amaranth: why?
<trukulo> Amaranth, it's possible, let me check
<Amaranth> Riddell: Because they're KDE programs? :) Unless they do something a GNOME app doesn't I don't think they should show up.
<Kamion> mdz: I have no idea where to put those on releases.u.c
<lamont> pitti: interesting...  no traces of it on the build machine either.
<Kamion> instinct suggests they should not be on releases.u.c at all, in fact
<haggai> Kamion: was there not talk of renaming the images too?
<trukulo> Amaranth, i'm trying with gdesklets, and doesn't work either
<Kamion> although releases does have the benefit of mirroring
<Riddell> Amaranth: if they're installed they should show up, they have no way of knowing if there is a similar gnome app installed or not.  if gnome wants to not show KDE applications is can specify as much in it's applications.menu
<Kamion> haggai: not enough to push me into actually going to the effort of figuring out how to do it
<haggai> Kamion: ah :)
<Kamion> I could do it for releases slightly more straightforwardly, although that script is already a nightmare
<trukulo> umm, there's something very strange here, Ark is in gnome-menu, but it's not on /etc/xdg/bla-bla
<mdz> Kamion: when I did kubuntu preview, I nearly clobbered the Ubuntu preview :-)
<Kamion> mdz: yes, I noticed :P
<mdz> clickclickOHSHITclicketyclickety
<Kamion> in fact you did partially clobber it
<Amaranth> trukulo: It'd be in /usr/share/applications/ or ~/.local/share/applications/
<elmo> giggle
<mdz> but then thom put it back, yes?
<Kamion> just one of the torrents I think
<mdz> so it was a near-clobber
<elmo> ubuntu, kubuntu.. it's all good - the users will never know the diff
<thom> mdz: i did, and then it apparently got clobbered again much later
<Kamion> thom put some of it back, then I put the rest of it back when thom told me about it the next day
<thom> not a huge amount of fun, that one
<trukulo> Amaranth, it's un /usr/share/apps/
<Amaranth> Isn't that a legacy directory?
<mdz> I'm holding the announcement until kubuntu is published
<trukulo> Amaranth, i don't know
<Kamion> um, ok then, where should kubuntu go?
<mdz> Kamion: any preference for installer problem reports: ubuntu-devel, ubuntu-users or bugzilla?
<Kamion> mdz: bugzilla
<mdz> Kamion: if releases is a problem, cdimage is fine
<elmo> cdimage is less good for me
<Kamion> releases.u.c/kubuntu/*?
<elmo> kamion: I reckon
<Kamion> ok
<mdz> elmo: are there any cdimage mirrors which we can trigger?
<Kamion> I'll make it have the same structure. Fractal filesystem layouts, yay
<elmo> mdz: no
<haggai> Kamion: if it isn't too much effort to change the name for the kubuntu release it might be a good idea
<Kamion> haggai: to what?
<haggai> Kamion: something including kubuntu
<mdz> elmo: so none that I can add to the announcement?
<Kamion> kubuntu-hoary-rc-install-i386.iso?
<elmo> mdz: most don't have space for 160Gb of rarely used stuff
<elmo> mdz: not if it goess to cdimage
<haggai> Kamion: looks good
<mdz> elmo: what about releases?
<zul> brb
<elmo> mdz: you can add se.releases.ubuntu.com 
<mdz> the ubuntu and kubuntu URLs will be separate
<Kamion> haggai: I'll see what I can do
<Kamion> it's kind of nightmare-filename-tastic
<elmo> mdz: unfortunately, triggers are still being setup for the others
<mdz> sweden, yes?
<elmo> yes
<haggai> Kamion: thanks
<trukulo> Amaranth, i'm trying to delete xsane, wich is on /usr/share/applications , and menu-editor didn't work, nor in menu, nor in menu-editor
<mdz> Kamion: HEADER.html still says preview?
<mdz> oh, the filenames do too. it's not mirrored yet?
<Kamion> mdz: it's not finished publishing yet because I screwed up to start with and had to restore from backup
<HiddenWolf> kamion, is RC up yet?
* fabbione boots DVD live
<Amaranth> trukulo: I need more info. Post your ~/.config/menus/applications.menu file in a new thread on http://ubuntuforums.org/forumdisplay.php?f=67
<Kamion> HiddenWolf: please stop the "are we there yet"
<Kamion> I'm working on it
<mdz> elmo: any chance we can get either a trigger, or someone to throw the switch for a us.releases.ubuntu.com for final?
<Kamion> I will mention it when it's ready, I won't just wander off for a beer
<trukulo> Amaranth, ok
<pitti> mdz: okay, I tested ipsec-tools 0.3.3-5 with 0.3.3-5, 0.3.3-5 with 0.5-5 and 0.5-5 with 0.5-5 (with authentication and encryption) and querying with setkey; works fine
<HiddenWolf> kamion :#
<elmo> mdz: I've been trying to contact shane for a while now
<elmo> he mirrors every 3 hours tho, I think.. lemme check
<mdz> the archive, he does, but not cd images
<elmo> no, that's cdimage
<elmo> but it's not 3 :( it's every 9
<elmo> for us.releases
<mdz> so we need to time it just right :-)
<Kamion> RC syncing to mirrors
<Kamion> now I have to go munge some scripts in order to do kubuntu
<mdz> Kamion: let me know the URL when it's ready
<Kamion> yep, will do
<Fab-DVD-Live> mdz: guess what?
<Fab-DVD-Live> :)
<trukulo> Amaranth, http://ubuntuforums.org/showthread.php?p=110295#post110295
<Kamion> wow, even my cdimage arch commit messages are getting bitter
<trukulo> Amaranth, file as i posted, without break lines on last line
<svenl> hi.
<svenl> building cdrecord with the DVD patch applied fails for one easy hunk not applying.
<svenl> i removed the hunk (which changes the warning message at cdrecord start) and it now builds.
<Amaranth> trukulo: I need to go for a bit, I'll have to look at it when I get back.
<trukulo> Amaranth, ok, see you
* _mvo_ is away for ~2h
<daniels> mdz: uploaded
<mdz> svenl: growisofs in dvd+rw-tools works much better for DVD
<daniels> Kamion: (don't worry about -8 for rc; it's a minor debconf fix that only impacts upgrades from warty -- clean installs/live cds are fine)
<mdz> Kamion is so far beyond worrying about that for RC ;-)
<mdz> sabdfl: morning
<daniels> heh
<daniels> morning sabdfl
<fabbione> mdz: DVD live is ok, i can't test install tho
<fabbione> mdz: we need to fix the syslinux .txt files for the DVD. They are misleading
<elmo> repinged shane
<fabbione> and they lack the option for live
<mdz> fabbione: please file a bug so that we don't forget
<svenl> mdz: well, growisofs hanged my box, so ...
<svenl> mdz: i didn't do an upgrade in ages, so i am doing this now to try again though.
<mdz> svenl: I use it many times every day, and it works well for me. cdrecord fails to write anything on the same system, even CDs
<mdz> fabbione: thanks for testing
<svenl> mdz: i am on amd64 though.
<mdz> fabbione: maybe after the initial wave dies down, we can publish some DVD images
<elmo> it's a bit unfortunate we're stuff kubuntu on releases for the first time, but meh
<fabbione> mdz: no problem.. i just need to find an extra hd to test dvd install
<mdz> elmo: an extra 3.6G here, an extra 3.6G there
<Kamion> elmo: yeah
<elmo> 3.6? meep
<Kamion> mdz: also it completely obviates the speed gain from pre-publishing
<daniels> 'meep'?
* daniels drops an ACME anvil on elmo.
<mdz> elmo: that's the size of the kubuntu preview
<fabbione> AHHHH
<fabbione> daniels: want the bad or the good news?
<mdz> Kamion: what does?
<daniels> fabbione: neither :P
<Kamion> mdz: publishing kubuntu on releases at the same time as switching over the hoary/ symlinks
<Kamion> but hey
<elmo> kamion/mdz: if you don't want to do kubuntu on releases, that's ok for me too, I don't have enough working+tested triggers for it to matter
<Kamion> elmo: I've written the code now
<elmo> I'll just round headless chicken style getting a second cdimage machine going in the background
<fabbione> daniels: ok the good news is that the AGP/PCI hang happens only with the binary drivers.. the bad news is that we clearly lose 3D acceleration on the machines...
<Kamion> and releases do really kind of belong there - I just feel it should be vhosted to releases.kubuntu.com or something
<fabbione> daniels: and apparently it is enough to initzialize the AGP ONCE to make it working forever
<daniels> fabbione: i think 3d acceleration is totally and utterly worthless if it means we have to play some bullshit roulette with the bios to get a basic screen up
<daniels> fabbione: hmmmm
<fabbione> daniels: i am going to retest it again...
<fabbione> daniels: i just need a few more minutes
<daniels> sure
<fabbione> daniels: i also noticed a little bug in gdm.conf. the -sharevts should never be associated to the primary head.
<fabbione> daniels: in our case is always the one with the lower PCI bus id
<fabbione> if not forced differently in the bIOS
<fabbione> not sure if we can really detect that
<trulux> just as I've done in -motu:
<trulux> I'm trying to apply for membership and maintainer"-ship", and I've been told to ask for those who know on my contribution to write something in my wiki page
<daniels> fabbione: not the primary head, but the first server started
<daniels> fabbione: else you're switching on to some random uninitialised vt that won't have graphics mode
<daniels> or just using the current vt
<daniels> the non-sharevts one has to come first, then the rest
<daniels> fabbione: but yeah, if you look in the current multiarse package on chinstrap:~daniels, that uses pcibustype to work out which card should be the lowest, and always sorts that last
<trulux> pitti: hey
<pitti> Hi trulux 
<trulux> pitti: I'm applying for membership, mako told me to ask those who know on my contrib. and work to write something on my wiki page
<svenl> Kamion, fabbione: is the current hoary kernel mkvmlinuz ready finally ? 
<trulux> pitti: You may be one of those who know it better, if you have time to do so, I'll appreciate it a lot ;)
<Kamion> svenl: I'm buried in publishing a release and ignoring all unrelated questions, just FYI :)
<svenl> Kamion: hehe.
<mdz> thom: I'm having exactly the same problem I described earlier, with the RC torrents
<mdz> thom: is it only me?
<svenl> will check and find out for myself.
<daniels> g'night all
<mdz> thom: ah, the tracker is actuall yrejecting it as not authorized; btlaunchmany hides the error
<elmo> mdz: try one more time?
<mdz> [08:58:06]  rejected by tracker - Requested download is not authori 
<elmo> what's your IP?
<elmo> (same as IRC?)
<mdz> 68.66.78.251
<mdz> also tried from 129.21.60.152
<trukulo> Amaranth, i know one of the problems, localisation
<elmo> there's absolutely nothing helpful in the log.  sigh.  go torrent
<trukulo> Amaranth, and kde problem related, too, it's because it's on a subdirectory
<mdz> elmo: does it work for you?
<elmo> er, dunno, not really in a position to try
<elmo> I'm messing with the seeders
<mdz> it's something we should sort out before we announce
<elmo> ah, hmm, one sec
<mdz> I think not authorized -> tracker needs restarting
<mdz> of course thom swore that this was all automated now :-P
<elmo> right, I've brutalised it
<elmo> one more try?  and I'll look at working out how to run it myself so I can test too
* fabbione imagines thom throwing peanuts to an elmo closed in a cage inside the DC.
<mdz> [09:13:00]  rejected by tracker - Requested download is not authori
<elmo> mdz: what is it you're trying to download?
<mdz> elmo: btdownloadcurses http://releases.ubuntu.com/hoary/hoary-rc-install-amd64.iso.torrent
<elmo> shouldn't that, err, be torrent.u.c ?
<mdz> no
<elmo> or is that in the .torrent file?
<mdz> yes
<elmo> ok.  sorry, my ignorance of torrent is showing in embarassing ways] 
<trukulo> mdz, do you want me to try to download it?
<mdz> trukulo: I'm quite convinced at this point that the problem is server-side
<trukulo> mdz, ok
<elmo> mdz: ok, at least I iknow what the problem is now
<elmo> Kamion: are you pulsing orcadas?
<elmo> if so, as what user?
<Kamion> elmo: yes, as torrent@
<Kamion> it's what thom told me, and it's not giving me any errors at least, so I assumed that was ok
<mdz> Kamion: there were ssh host key mismatch errors in the logs, for the runs under my uid anyway, until I fixed my known_hosts
<elmo> james@little:/srv/cdimage.no-name-yet.com/www/torrent $ find . -name hoary-rc-install\*
<Kamion> mdz: mismatch, or just not known yet? the latter always happens when new hosts get added
<elmo> james@little:/srv/cdimage.no-name-yet.com/www/torrent $ 
<elmo> that's the problem
<Kamion> mdz: and one host key did change
<Kamion> elmo: uh. fuck.
<Kamion> I see the problem
<Kamion> elmo: does orcadas care at all about the structure of that tree
<Kamion> ?
<Kamion> if I can lay it out any way I like, it's easier to fix
<elmo> Kamion: doesn't look like it does, no
<lamont> smurfix: any reason that the ppc live disk calls it 'lt' instead of Lithuanian?
<Kamion> that's a general problem on powerpc, it's picking the AT names for some reason rather than the mac-usb-* names
* lamont wonders how long and iMac G3 should take to configure the panel
<lamont> livecd, that is
<Kamion> mdz: ok, fix in progress I think
<mdz> without DMA on the CD, 5-7 seconds or so
<lamont> finally finished, it appears...
<lamont> pivotroot happened
<mdz> oh, you said G3. they're slow.
* lamont suspects the CD reader is not 100% happy too, but can't prove that
<mdz> Kamion: say when
<lamont> then again, it could have been the first victim when the writer died...
<lamont> x-splash
<lamont> mdz: G3 _SLOW_, not 'slow'. :-)
<T-Bone> lamont: depends on the model
<lamont> T-Bone: well, that and how much RAM it doesn't have
<T-Bone> lamont: but in general imacs g3 are *S.L.O.W* :)
<T-Bone> true
<lamont> still have blank desktop with a bar across top and bottom (blank bars, mind you_)
<smurfix> lamont, Kamion: "at" and "usb" keymaps are distinct; since kernel 2.4 there's no longer any good reason for that AFAIK
<smurfix> these should probably be unified. *After* sarge/hoary. :-/
<lamont> smurfix: definitely after
<smurfix> heh
<HiddenWolf> smurfix: after sarge, or after hoary? ;)
<smurfix> HiddenWolf: Both, if possible.
<Kamion> smurfix: mac-usb keymaps are physically quite different from the corresponding AT keymaps though
<Kamion> the misnaming is in associating Mac with USB, not in having distinct Mac keymaps
<smurfix> Kamion: Hmm, yeah, you're right
<smurfix> Kamion: still, the distinction doesn't work
<smurfix> HiddenWolf: For more arguing, I refer you to http://wiki.debian.net/?LetUbuntuReleaseForUs
<Kamion> smurfix: and on powerpc keymapper should never be picking AT keymaps, since kbd-chooser wouldn't do that and doesn't have the translations for them
<Kamion> mdz: mirrors are syncing now; I'm not quite sure when orcadas will be done, though
<HiddenWolf> smurfix: I'd rather stay clear of sarge and the touchy feelings around it. But thanks. (I'll be silent now, this is OT)
<fabbione> mdz: are we go for uploads?
<mdz> fabbione: yes
<smurfix> Kamion: People do connect standard USB keyboards to their powerpc machines
<mdz> Kamion: ok
<mdz> Kamion: kubuntu is on cdimage, right?
<fabbione> mdz: thanks.. new kernel on the way
<pitti> fabbione: cool
<Kamion> smurfix: regardless, kbd-chooser *does* *not* have AT keymaps
<Kamion> and now is not the time to mess with that; it can have bad unintended effects
<lamont> hrm... warty live apparently automounted NTFS partitions that it found.. hoary doesn't.  annoyed brother wants it to mount automatically...
<Kamion> mdz: yeah, hence the delay
<Kamion> mdz: http://cdimage.ubuntu.com/kubuntu/releases/hoary/rc/
<fabbione> pitti: can you pass by at the Kernel Team meeting this evening?
<pitti> fabbione: depends on when my gf arrives
<mdz> elmo: can you confirm that the torrents are spooling up?
<elmo> mdz: I'm watching the log
<Kamion> smurfix: hmm - actually I take that back, it does have AT keymaps
<fabbione> pitti: well.. it's at 20:00 UTC
<pitti> fabbione: uh
<fabbione> pitti: it shouldn't take too long
<pitti> fabbione: okay, I'll try to convince her :-)
<fabbione> pitti: and we want to discuss the last bits of security for hoary
<fabbione> pitti: question of a few minutes
<Kamion> smurfix: which makes kbd-chooser's behaviour almost weirder - doesn't it need to be able to tell which type of keyboard you're using from the start so that it can select from the right set of keymaps?
<fabbione> pitti: after that we will start with breezy...
<pitti> fabbione: you mean procedural or about concrete vulns?
<fabbione> pitti: a bit of everything
<pitti> fabbione: okay, I try to keep the computer running :-)
<smurfix> Kamion: Depends which method you use for key selection. Selecting from the full list uses a two-step approach; the architecture is a low-prio question
<fabbione> pitti: thanks
<elmo> okay, orcadas is freaking me out
<Kamion> smurfix: kbd-chooser already has code to figure out which keymap arch you're on though
<elmo> the bittorrent clients all have future-start dates
<mdz> torrents look good
<mdz> on the client end
<pitti> lamont: btw, any news wrt the missing gdm tarball? was this a one-time or a permanent problem?
<elmo> mdz: ok, i'll leave well enough alone then
<Kamion> smurfix: when selecting from the full list, it picks the correct default for that question; so when selecting using detect-keys, it should use that code to find the keymap architecture, too
<mdz> I have 4/9 live
<mdz> usually it takes a few minutes for the seed to scan all the files
<lamont> pitti: no clue whatsoever, but elmo is going to take the machine out and shoot it in the head.
<pitti> hmm, very subtle solution...
<mdz> elmo: hoary-rc-install-i386 and hoary-rc-install-powerpc are ok, but I get nothing from hoary-rc-install-amd64
<mdz> still only the same 4 are working
<smurfix> Kamion: detect-keys doesn't work at all well (yet) when you have a keyboard that's not in the decision tree, so currently there's one combined tree and an occasional not-translated keyboard name
<Kamion> smurfix: it's not occasional on powerpc AFAICT
<lamont> ok.  for the record: booting the hoary livecd on a 64MB G3 iMac is not something that should be even suggested...
<lamont> finally gave up and booted the install cd instead
<Kamion> it always selects AT keymaps on my powerbook
<mdz> elmo: where is thom hiding anyway?
<elmo> mdz: I think he ran off screaming about how torrent sucked and how he'd make them all pay
<mdz> elmo: right, so what you're saying is that I should call him
<HiddenWolf> elmo: lol
<Kamion> I think the tree on little is correct now
<Amaranth> trukulo: Still here?
<elmo> I'm not sure if torrent is still syncing up or not
<elmo> I do remember it taking a while
<trukulo> Amaranth, yes
<smurfix> Kamion: I had to drop some keymaps: mac-usb-de-latin1 and mac-us-ext fr_CH1 are indistinguishable from their AT equivalents
<trukulo> i wrote about bugs on forum
<HiddenWolf> elmo: torrent for amd64 is live. No peers/seeds tho
<Amaranth> trukulo: Ok, what were you saying about localization?
<mdz> elmo: not a single new one has gone live since the first batch
<smurfix> Kamion: One solution might be to use the mac versions for ppc
<HiddenWolf> mdz: Where it was saying "rejected by tracker" previously, it now says 'connecting to peers'
<Kamion> smurfix: mac-usb-uk is the one I notice all the time
<trukulo> Amaranth, i'm using [es]  (spanish)
<Amaranth> trukulo: I'm pulling the <Name> info from the .directory file. GNOME and/or Ubuntu has it translated for you so that shouldn't be it.
<elmo> ugh, :6969 says "Internal server error"
<Amaranth> elmo: tracker is screwed?
<trukulo> and menu-editor uses spanish names of menus, that don't work on Excludes
<mdz> HiddenWolf: yes
<trukulo> Amaranth, wrong, in english it works, not in spanish
<Amaranth> trukulo: Ok, I'll make it ignore locale info for .directory files then.
<smurfix> Kamion: Is that the name you're seeing in the kbdchooser main window?
<trukulo> Amaranth, ok
<Amaranth> trukulo: btw, you posted in one of the threads :/ I asked to have it in a new thread on the menu editor forum.
<Kamion> smurfix: I'll have to try another test install to be sure, but last time I remember it happening, it initially said "British English", and then after I ran through detect-keys, it just said "uk"
<Kamion> smurfix: that also matches the reports we get here fairly frequently from Mac users
<trukulo> Amaranth, ups, sorry, i didn't read, only post on sticky post
<Amaranth> trukulo: I have my own subforum now. :) http://ubuntuforums.org/forumdisplay.php?f=67
<smurfix> Kamion: Ah. I'll run a diff between these keymaps then.
<trukulo> Amaranth, i wrote there, on sticky post
<trukulo> you want me to start a new thread?
<smurfix> Kamion: That should be fixable easily, at least for the standard cases
<Amaranth> trukulo: Not now, I already know the issue. But now that I have my own forum I'm trying to get people to report bugs in new threads.
<trukulo> Amaranth, ok, i'll note that
<trukulo> Amaranth, also, i know problem with kde entries
<Amaranth> trukulo: Makes it easier for people to see if their bug is already known and it makes it easier for me to read them.
<Amaranth> trukulo: Oh?
<trukulo> it's because kde apps are on a subdirectory
<trukulo> are on /applications/kde/
<Kamion> smurfix: I'm not sure I understand the bug as well as I thought I did though
<trukulo> and exclude don't work with subdirectorios
<trukulo> s/subdirectorios/subdirectories
<Kamion> smurfix: because "uk" is indeed translated in console-keymaps-at, which is included in the powerpc cdrom initrd
<Amaranth> trukulo: Oh, because I use <Filename>
<trukulo> Amaranth, yes
<Kamion> smurfix: are you sure cdebconf does the translating in the way you said in the kbd-chooser 1.09ubuntu5 changelog?
<Lathiat> Amaranth: looking good
<Lathiat> Amaranth: 0.5 ui is definately better than how it is in 0.3 :)
<lamont> lamont/gcc-3.4_3.4.3-9ubuntu3_hppa.changes
<lamont> gah
<elmo> happier?
<mdz> they all stopped downloading
<mdz> if you restarted the tracker or something, it's probably waiting to reconnect or something
<mdz> btlaunchmany does a good job of hiding errors
<elmo> yeah, I did
<elmo> the tracker's actually running now, which will probably help
<HiddenWolf> mdz: use btlaunchmanycurses, works better
* Mithrandir gets a measly 1MB/sec down.
<Amaranth> trukulo: Looks like I'll have to use full paths for <Filename>, I don't see any other option.
<mdz> HiddenWolf: I am
<mdz> that's what I said
<trukulo> Amaranth, that would be correct, i think
<HiddenWolf> mdz: you didn't say curses
<elmo> that btdownloadcurses url you gave me earlier seems to be working for me anyhow
<mdz> hmm, I didn't even realize there was a plain 'btlaunchmany'
<mdz> elmo: once I can confirm that the other 11 are working I'll send out the announcement
<HiddenWolf> mdz: there is
<mdz> anyway I'm using curses, and it doesn't display error messages the way btdownloadcurses does
<mdz> HiddenWolf: is it working for you now?
<HiddenWolf> mdz: Not yet. I'll restart and see what it does
<HiddenWolf> mdz: connecting to peers (0.0%) 
<elmo> mdz: can you figlet "USE TORRENT" at the top of the announce, pls?
<mdz> same here
<elmo> ugh, you're kidding, it's still broken?
<elmo> what are you running?
<HiddenWolf> elmo: btlaunchmanycurses --minport 6881 --maxport 6999 --max_upload_rate 20 
<Mithrandir> elmo: worksforme
<elmo> HiddenWolf: what URL?
<Mithrandir> though, only install-ppc, live-amd64 so far.
<HiddenWolf> elmo: amd64-install
<elmo> that's working for me
<HiddenWolf> <mdz> elmo: btdownloadcurses http://releases.ubuntu.com/hoary/hoary-rc-install-amd64.iso.torrent - that url
<elmo> that too
<smurfix> Kamion: It does, the problem might be that it's actually checking the wrong table. Can you tell me which keys you're pressing in detect-keys, and their keycodes?
<elmo> both those now work
<elmo> (for me)
<Kamion> smurfix: will do next time I'm doing an install
<HiddenWolf> elmo: not here. Connecting to peers only
<elmo> HiddenWolf: what's your IP?
<smurfix> Kamion: I'll trace what the code does. My kids will have to forego their Mac for a bit ;-)
<HiddenWolf> elmo: 217.77.136.166
<lamont> Kamion: archive copier should not be the default on G3's. :-(  this ones opinion only, of course...
<elmo> mdz: is it still broken for you too?
<Kamion> damn, I meant to make the Kubuntu CDs kubuntu-hoary-rc-* rather than kubuntu-hoary-*
<Kamion> oh well, too late now, I'm not renaming them all
<Kamion> elmo: 8/12 have started up here
* lamont lunches unless someone screams
<lamont> right. lunch.
<Treenaks> unless or until? :P
<HiddenWolf> lol@treenaks
<mdz> elmo: I have 8/12 live
<Mithrandir> where are the kubuntu torrents?
<mdz> kubuntu-hoary-install-amd64, kubuntu-hoary-install-i386, kubuntu-hoary-live-i386 and kubuntu-hoary-live-powerpc are not working
<mdz> Mithrandir: http://cdimage.ubuntu.com/kubuntu/releases/hoary/rc/
<Kamion> mdz: yeah, same here
<HiddenWolf> mdz: ubuntu-amd64 install does it for you?
<mdz> hoary-rc-install-amd64 is fine
<HiddenWolf> mdz: what's the link to the torrent, I'll re-download to make sure
<mdz> HiddenWolf: http://releases.ubuntu.com/hoary/
<elmo> uh
<elmo> why does torrent.ubuntu.com:6969 have same name, different md5sum entries?
<elmo> oh, the dailies, meh
<mdz> because we create many different torrents with the same filenames
<HiddenWolf> mdz: no luck, no peers
<mdz> it's OK on the server side, install-amd64 works fine for me
<pitti> fabbione: I really like your kernel release names :)
<fabbione> pitti: ehehe
<jani> elmo, any reason for a sync from debian not making it to hoary-changes? I cannot seem to find darcs announced there even if you synced it, but I got confirmation email
<mdz> elmo: kubuntu-hoary-install-amd64 just started working
* Kamion goes off for a bit; SMS me if it's urgent
<pitti> fabbione: I hope there are enough vegetables for the future
<fabbione> pitti: they are not just mine tho.. we vote for them :)
<mdz> k-h-live-i386 and k-h-live-powerpc still idle
<mdz> elmo: hey, they're all working now
<mdz> 12/12
* Mithrandir is seeding at 1.3M/s, all are working.
<Mithrandir> downloading at ~8.8MB/sec.
<elmo> ok, yay
<Mithrandir> that's fairly decent
<fabbione> pitti: we will find them.. don't worry :) we have for at least another 6/8 releases
<HiddenWolf> mithrandir: you're making me jealous
<Mithrandir> I'm actually maxing out my 100Mbit now.
<Mithrandir> fun.
<HiddenWolf> elmo; what port is the torrent/tracker on?
<mdz> announcement is away
<elmo> HiddenWolf: the default
* ..[topic/#ubuntu-devel:mdz] : Ubuntu Development | #ubuntu for support and general discussion | #ubuntu-love for getting involved | http://www.ubuntulinux.org/wiki/DeveloperResources | http://www.ubuntulinux.org/wiki/HoaryGoals | Kubuntu on #kubuntu-devel | Hoary release candidate: http://releases.ubuntu.com/hoary/
<ogra> yeah
<Mithrandir> mdz: approval for m-t 1.0.2?  Security fixes; recommended by pitti
<mdz> Mithrandir: ok
<Mithrandir> (probably something more than security too, described by pitti as "backport nightmare" :/
<pitti> Mithrandir: I mean the security fixes, there are heaps of them, and pretty intrusive ones
<Mithrandir> pitti: ah, ok.
<sPoof_> mdz: Hi, did you receive my mail about MoinMoin?
<mdz> sPoof_: yes, thanks
<pitti> mdz: congrats for the release :-)
<mdz> sPoof_: we published the Ubuntu 5.04 release candidate today
<fabbione> mdz ++
<mdz> sPoof_: so I have been busy
* fabbione -> food
<mdz> elmo: gah, the torrents just fell over
<sPoof_> mdz: oh, didn't know that. Sorry.
<mdz> kubuntu-hoary-live-powerpc.iso.torrent died 6 times, added to dead list
<elmo> mdz: WHAT?
<mdz> elmo: ^^ for 8/12
<mdz> is it only me?
<sPoof_> dmz: So I didn't make it in time, then :-(
<Mithrandir> the torrents have almost died down for me.
<HiddenWolf> mdz: still no torrent here either.
<Mithrandir> pushing ~70-ish kB/s.
<mdz> the ones where I have a complete copy are still alive
<mdz> the others died
<mdz> sPoof_: not necessarily
<sPoof_> Congratulations with the release, everyone!
<mdz> sPoof_: the final release is in 9 days, so we have some time to get moin in
<mdz> since it is an alternative and not a replacement, the risk is low
<sPoof_> mdz: I see.
<sPoof_> mdz: Then tell me again - what happened today if not the release?
<mdz> sPoof_: "release candidate"
<sPoof_> mdz: grand freeze?
<sPoof_> mdz: thanks. I am slow...
<mdz> <mdz> sPoof_: we published the Ubuntu 5.04 release candidate today
<elmo> mdz: I dunno what to suggest, I didn't touch it, I can still see people using it
<mdz> elmo: never mind, I think I ran out of disk.  yay btlaunchmanycurses for hiding more errors
<sPoof_> mdz: the new packaging is equal for Ubuntu and Debian (and Woody backports but haven't tested that yet),
<HiddenWolf> elmo: still nothing here. Do you have any idea what can cause that?
<elmo> god damn it the torrent software is evil
<mdz> HiddenWolf: firewall
<HiddenWolf> mdz: not so for other torrents, and I d/l a lot
<Kamion> doko: should be ok for uploads now BTW
<sPoof_> mdz: What to do now? I'd be happy to throw it at some testers if need be (and testers are there).
<mdz> sPoof_: I believe the next thing is for elmo to set it up on our server
<mdz> meanwhile I'll get it uploaded
<mdz> actually I think I'd like for elmo to look over it before I upload it
<elmo> mdz: I thought you wanted me to sync it?
<sPoof_> mdz: I'd like that too.
<mdz> elmo: that's fine too
<sPoof_> elmo: sync? Is that another thread than MoinMoin or...?
<mdz> is there a new URL?
<mdz> the package at http://debian.jones.dk/hykrion/pool/ubuntu/moin/ is still called 'moin'
<sPoof_> mdz: Same URL. I can remove the old parts if that disturbs you.
<mdz> sPoof_: we agreed by mail that the package should be named differently, so as not to replace moin 1.2.x
<mdz> so that they can coexist in the archive
<sPoof_> mdz: Oh - I get it (stupid me) you want a different _source_ name off course.
<mdz> source and binary
<sPoof_> mdz: binaries have changed. Source won't take me more than 10 minutes to change.
<sPoof_> mdz: I'll do it right now! (how embarrassing!)
<mdz> sPoof_: there is still a binary named 'moin' also
<mdz> oh, I see, that is for the old version
<mxpxpod> is beagle going to be in the next ubuntu release?
<zul> heh
<sPoof_> mdz: Should be correct now: http://debian.jones.dk/hykrion/pool/ubuntu/moin/
<mdz> elmo: ^^ please sync if you're happy with it
<sPoof_> mdz: Removed old stuff. Added debian dir from source package if interested in a quick look.
<HiddenWolf> mdz; elmo; I can get the torrent going with gnome-btdownload, but not with btlaunchmanycurses....
* smurfix 'd start a torrent seed on my hosted machine if he had free bandwidth :-/
<smurfix> s/my/his ;-)
<mdz> mako: speaking of free bandwidth
<mdz> mako: can you get a seed going?
<mako> mdz: sure :)
<seb128> mdz: are we in upload freeze ?
<mdz> seb128: no
<seb128> k, I've some uploads to do
<seb128> I've a fix for the gtk fileselector crasher
<mdz> yay
<mdz> is there any word on the gamin bug?
<seb128> mdz: waiting on pitti 
<josue> guys, i've got some 600-700GB available in my server, and want to help if possible, but i've never setup a seed.
<mdz> pitti: ping
<smurfix> josue: Just download the .torrent files and tun btdownload* on each of them
<smurfix> s/tun/run
<josue> alright, where can i find the torrent for the rc?
<mako> mdz: i'm on both of the i386 torrents
<josue> sorry, brb
<mdz> mako: both? there are 4 i386 torrents :-)
<mvo> re
<mako> rc install and rc live and ??
<mdz> mako: ubuntu install, ubuntu live, kubuntu install, kubuntu live
<ups> josue: http://releases.ubuntu.com/hoary/ :)
<mako> ahh.. i'm not doing kubuntu yet
<mako> i can do that too
<mako> i'm getting about 1MB/second down on each torrent 
<mako> but less than 100KB/sec up
<mako> actually 2MB/second down
<HiddenWolf> mako: you're making me damn jealous
<mako> HiddenWolf: i downloaded an ISO in under 3 minutes once :)
<helio7> mdz I got the listserv email today & updated my torrents so I'm getting 12 torrents for seeding (kubuntu X6 and ubuntu X6) all hoary; do you think I should stop seeding Warty at this point?
<HiddenWolf> mako: please, don't be cruel. I
<mdz> helio7: Warty is still the current stable release, and many people still want to download it
<HiddenWolf> I'm maxing out my conn and will have to wait 2:45 for it.
<helio7> ok thanks
<smurfix> mako: *grumble* *envy*
<maswan> mako: that's two minutes too much. :P
<zyga> geez my LAN is slower :P
<zyga> mvo: ping
<mvo> zyga: pong
<zyga> mvo: who is responsible for the artwork?
<zyga> pretty cd + globe icon
<mdz> zyga: which artwork?
<zyga> make that: pretty ubuntu cd + globe icon
<zyga> the icon from update-manager
<mvo> zyga: in update-manager?
<mvo> zyga: michiel (Mitario) created it 
* zyga wonders about possibility of adding package-specific icons to update manager
<mvo> zyga: you may want to have a look at gnome-app-install for that :) 
<maswan> mako: well, assuming it isn't a full-sized dvd iso, then it is pretty impressive
<mvo> it uses the icon information from the .desktop files for that
<Amaranth> gnome-app-install is like a weak attempt at a menu editor :P
<zyga> mvo: good idea :-)
<lamont> Kamion: so that archive copy I was bitching about an hour ago is 64% done.  libostyle1
* lamont suspects that he needs to add more RAM
<Amaranth> it uses PyXDG, makes it really easy
<mvo> Amaranth: a interessting characterisation
<Amaranth> mvo: It doesn't actually remove the apps, it just include and excludes them from the menus
<mvo> Amaranth: oh, it does remove the apps (and installs them)
<mvo> Amaranth: if not, you have found a bug
<Amaranth> err
<Amaranth> this must not be gnome-app-install then
<Amaranth> because it doesn't even run with sudo
<Amaranth> no, it's the right app
<zyga> hmm
<zyga> does freedesktop.org specifies how to lookup correct icon file?
<Amaranth> zyga: are you using Python? :)
<zyga> Amaranth: that depends ;] 
<zyga> Amaranth: currently - yes, in general - no
<Amaranth> python-xdg makes it all very simple
<jani> elmo ping
<zyga> Amaranth: interesting
<zyga> Amaranth: that's a separate library I assume
<Amaranth> yeah
<fabbione> Kernel Team meeting on #ubuntu-meeting will start in 10 minutes
<Amaranth> fabbione: mind if i watch?
<zyga> is there any way to check if it's present before trying to load it?
<zyga> I'd like not have to depend on it
<fabbione> Amaranth: everybody can watch and partecipate, but stay on topic
* zyga is still python novice 
<Amaranth> zyga: It's in main
<mdz> mako: can I ask in advance for a Hoary final release announcement?  I think sabdfl will want to review and revise as well
<Amaranth> zyga: it's even a part of ubuntu-desktop, iirc
<zyga> Amaranth: I've just looked it up
<zyga> Amaranth: thanks that's going to be very interesting :)
<elmo> jani?
<jani> elmo, can you add my GPG key to the ring please?
<jani> Jani Monoses
<jani> I did an upload but seems it was ignored so I supposed I have no permission yet
<fabbione> Kernel Team meeting on #ubuntu-meeting will start now
<lamont> hrm.. red on magenta is hard to read.
<lamont> really should fix that connector
* lamont tries to remember if the preview image had inotify disabled
<lamont> hrm.. easy enough to check in a few.
<elmo> jani: what's your key id?
<jani> a moment
<jani> C5AA2301
<HiddenWolf> Ugh. I'm guessing you can't install from the livecd?
<Amaranth> nope
<HiddenWolf> fuck, then I've been downing the wrong ISO
<elmo> smurfix: ?
<elmo> jani: ok, one sec
<elmo> smurfix: nm
<smurfix> elmo: !
<pitti> night everybody
<HiddenWolf> elmo; mdz; if you want people to use the torrents if they can, you should consider linking the bolded links in the wiki to the torrent, rather than the iso
<mdz> HiddenWolf: what bolded links in the wiki?
<elmo> doko: err, "-0" ?
<doko> hmm, yes, will change it, but it's the correct package.
<lamont> woot... 90 minutes into archive-copier, and 70% done.
<lamont> so if I rip 90% of these locales out of /etc/locale.gen, and regen, will the next lang-pack update recreate them, I wonder???
<Mithrandir> yes, and it's a bug and pitti has been made aware of it
<fabbione> mdz: ping?
<lamont> daily*/current are the RC bits, yes?
<jani> elmo, if you have time today https://www.ubuntulinux.org/wiki/MOTUToSync, second row, the xfce4.2 upgrade, thank
* mvo goes to bed now
<lamont> any ppc-netboot literate folks awake?
#ubuntu-devel 2006-04-03
<KaiL> you had somebody, whose key didn't get saved? bug 36651 is another
<Ubugtu> Malone bug 36651 in network-manager "Network Manager does not remember WEP key" [Normal,Unconfirmed]  http://launchpad.net/bugs/36651
<Pygi> KaiL: bah, 3 same bugs
<Pygi> I already marked 1 as duplicate
<Pygi> KaiL: care to find which one, and mark this one as well?
<KaiL> maybe, it's quite anoying? ;)
<KaiL> 36708 is j^ 
<j^> KaiL 37071 why would one need a rescan button? NM updates the information all the time
<KaiL> j^, 0.5 was sometimes not the fastest with that
<KaiL> is that now fixed?
<Pygi> you can mark it duplicate of this as well
<Pygi> https://launchpad.net/distros/ubuntu/+source/network-manager/+bug/35225
<Ubugtu> Malone bug 35225 in network-manager "Wireless WEP connection ask for password when the network goes down and returns" [Normal,Confirmed]  
<Pygi> so much duplicates
<KaiL> bug 31286 something related?
<Ubugtu> Malone bug 31286 in network-manager "network-manager suspend gnome-keyring problem" [Normal,Needs info]  http://launchpad.net/bugs/31286
<Pygi> yes, related
<Pygi> also, read this 
<Pygi> "i have installed, but i don't know why (:P)"
<Pygi> joy :P
<KaiL> lol
<mdz> LaserJock: I'm not sure what you mean?  a new package or a new version of a package?
<KaiL> 36710 - something with patch (from j^)
<LaserJock> mdz: new package
<mdz> LaserJock: how can a new package be a bug fix?
<LaserJock> mdz: we are missing a package that makes other package fail ;-)
<mdz> LaserJock: anyway, new packages in universe/multiverse are fine with me during feature freeze
<LaserJock> mdz: ok, ogra ok'd it but I just wanted to be clear
<ajmitch__> mdz: that clarification would have been good to have earlier, since we've been working on the freeze assumption since UBZ
<Pygi> KaiL: bug 37079
<Ubugtu> Malone bug 37079 in network-manager "network-manager" [Normal,Needs info]  http://launchpad.net/bugs/37079
<mdz> ajmitch__: I've said this to dholbach before
<mdz> ajmitch__: as far as I'm concerned, MOTU is free to make that decision itself
<Pygi> KaiL: also, please make sure you give comment why you changed status, especially if you reject
<KaiL> Pygi, wpasupplicant is in main (at least for the master server)
<j^> its right about the VPN part
<dholbach> mdz: ok, I must have misunderstood you and taken it for "updates only"
<Pygi> KaiL: k, will fix ^_^
<ajmitch__> dholbach: so we use the uvf team to approve new packages as well? :)
<j^> packages for the vpn plugins can be found at http://bootlab.org/~j/NetworkManager/
<Pygi> Kail: do you comment why you change status? I saw you rejected one bug report
<HrdwrBoB> j^: awesome, I've been manually restarting openvpn
<KaiL> bug 23380 << fixed with 0.6
<Ubugtu> Malone bug 23380 in network-manager "nm-applet doesn't provide an interface for configuring WPA networks." [Wishlist,Unconfirmed]  http://launchpad.net/bugs/23380
<dholbach> ajmitch__: i'll be delighted, I think so, yes.
* KaiL rejected one? and that wasn't one, I opened myself?
<Pygi> KaiL: K, great 
<ajmitch__> dholbach: great, I'll start filing bugs soon
* dholbach sees endless "please review xyz on REVU" bugs coming
<ajmitch__> dholbach: some rules have to be laid down about it then
<dholbach> right... but not tonight
<dholbach> i'm off to bed now.... see you guys!
<Pygi> night dholbach
<LaserJock> dholbach: ok, so should I hold off on the upload I was going to do?
<ajmitch__> night dholbach 
<dholbach> LaserJock: if it was approved, go ahead
<ogra> LaserJock, its fine ... 
* Pygi hasn't sleeped for 3 days already :'(
<Pygi> KaiL: we need to get rid of some bugs
<Pygi> most are duplicates or already resolved
<KaiL> yes
<KaiL> and there are several "my system with totally screwn up config confuses nm"...
<KaiL> bug 36975 I can confirm, but is it really a bug? for me the icon looks like an rj45 plug
<Ubugtu> Malone bug 36975 in network-manager "nm-no-connection icon looks like a mouse" [Normal,Unconfirmed]  http://launchpad.net/bugs/36975
<Pygi> bah, lemme see
<Pygi> you can confirm, but say it's not really a bug
<KaiL> nm-applet 0.6 tells you, if the LAN is WEP or WPA while asking the PW?
<Pygi> yup, it should
<mroth> sladen: filed with the info you wanted attached as bug 37082
<Ubugtu> Malone bug 37082 in hotkey-setup "thinkpad-keys not loaded on Thinkpad X60s" [Normal,Unconfirmed]  http://launchpad.net/bugs/37082
<mroth> sladen: also, is expected behavior in the current version for the BroswerForward / BrowserBack keys to be mapped to anything?
<Pygi> KaiL: any progress? :P
<KaiL> with what?
<KaiL> 40 open bugs now, we startet with 45 or 48
<Pygi> yup, I know 
<Pygi> we solved some tho
<Pygi> KaiL: so much new bugs coming right now
<Pygi> bug 37084
<Ubugtu> Malone bug 37084 in network-manager "network-manager crashes" [Normal,Unconfirmed]  http://launchpad.net/bugs/37084
<Pygi> I'll shoot myself :P
<KaiL> ...I loke crashes without a way to reproduce them
<KaiL> live..
<KaiL> eh love :)
<Pygi> :-X
<trappist> what to do about a (confidential) security-related bug where I'm the only subscriber?
<pitti> trappist: please subscribe ubuntu-security
<trappist> gotcha
<Pygi> pitti: there is a serious wpasupplicant security issue
<trappist> is that security@ubuntu.com?
<pitti> trappist: roughly, yes
<trappist> thanks
<pitti> trappist: oh, not in LP
<trappist> doh
<pitti> trappist: that's a valid email address, but in LP that's a team
<pitti> ubuntu-security is the team ID
<trappist> yeah, Ubuntu Security Team
<trappist> so, Ubuntu Security Team is the correct team, or no?
<crimsun> https://launchpad.net/people/ubuntu-security
<Pygi> KaiL: will you shoot me, or should I shoot myself? :P
<KaiL> for what?
<Pygi> bah, for a lot of things ;)
<trappist> this looks like a yes.  should ubuntu-security maybe get auto-subscribed to confidential bugs?
<KaiL> 37070?
<Pygi> not sleeping, people wrongly interpreting my words, etc :P
<trappist> or is there a non-security reason to make a bug confidential?
<Pygi> KaiL: also, look at this now 37084
<Pygi> resolve this issue pls
<Pygi> KaiL: this is a serious issue as well, yes ;)
<Pygi> pitti: can you please look at 37070? that needs to be fixed ASAP
<Pygi> or else, I'll vote not to include wpasupplicant (not that my vote counts, but still :P )
<crimsun> um, wpasupplicant has already been promoted to main. Why wasn't this addressed prior?
<KaiL> crimsun, to many people having syslog linked to /dev/null?
<crimsun> KaiL: I'm referring to the security-sensitive one
* KaiL too
<crimsun> keep in mind I can't access #37070
<KaiL> remembers me of some bug in breezy, which had some very had press...
<pitti> trappist: yes, there's a Malone bug about that
<Pygi> crimsun: because we didn't know about it or somethin' ? :-/
<pitti> Pygi: EPERM
<pitti> Pygi: you need to subscribe me
<KaiL> Pygi, looking at syslog, messages and the output dpkg gives, would always be a good idea ;)
<Pygi> pitti: I think KaiL reported 
<Pygi> KaiL: please subscribe me and pitti to the bug
<Pygi> KaiL: also, bug 37091 is duplicate of somethin' we had just a few moments ago it seems :-/
<Ubugtu> Malone bug 37091 in network-manager "nm 0.6.1 crash (dapper)" [Normal,Unconfirmed]  http://launchpad.net/bugs/37091
<KaiL> same crash as 37084?
* j^ wonders if the dapper nm packages work for anyone, i still use my own 0.6.2 ones
<KaiL> j^, well, it works for 2 100Base-T-Connections here :)
<Pygi> KaiL: yes, most probably
<Pygi> j^: they do work, they just have issues that we need to solve
<Pygi> we'll see if we can pull 0.6.2 for dapper
<Pygi> can you send me your 0.6.2 on a mail?
<Pygi> j^: send me a 0.6.2 package on a mail pls?
<Pygi> mario dot danic at gmail dot com
<Pygi> most probably that is my mail
<Pygi> mail*
<j^> Pygi http://bootlab.org/~j/NetworkManager/
<Pygi> pitti: still here?
<pitti> about to go to bed
<Pygi> ah, ok, night then
<Pygi> we'll talk later
<Pygi> j^: I'll look into those packages ^_^
<Pygi> I hope you are a good packager :-)
<sivang> night pitti !
<pitti> night everyone
* Pygi is expecting j^ to say "yes, I am a good packager" ;)
<Pygi> j^: you alive? ;)
<KaiL> maybe that fixed some of my problems too - let's see
<KaiL> of you you think more, it's an wpasupplicant-problem?
<Pygi> KaiL: wpasupplicant has a lot of problems
<Pygi> much much much more then n-m itself
<KaiL> 37069 is here the special one..
<Pygi> bug 37069
<Ubugtu> Malone bug 37069 in network-manager "network-manager doesn't set WLAN-Config at all" [Normal,Unconfirmed]  http://launchpad.net/bugs/37069
<Pygi> lemme see
<Pygi> hm :-/
<Pygi> I don't see how can we reproduce this
<KaiL> I can here - better than I like too :/
<Pygi> KaiL: please post comment then
<KaiL> that IS my system ;)
<Pygi> ah, joy :-S
<Pygi> sorry
<Pygi> me sleepy :)
<Pygi> you are dabear? ;)
<KaiL> hm?
<Pygi> nothing, sorry, just sleepy, and a lot of people report bugs :P
<Pygi> KaiL: I'll look into that bug
<Pygi> KaiL: can you please assign me to that security related bug?
<KaiL> done
<j^> KaiL it crashes for you too? if you have anythin other than lo in /etc/network/interfaces, can you try without that?
<KaiL> j^, nop, no crash
<Pygi> j^: and why don't you respond to me? :P
<Pygi> KaiL: thanks
<KaiL> only can't connect (which is really a bit complicate, as it doesn't set any iwconfig-values)
<Burgwork> Seveas, nice way to "misinterpret" the words of Charlie about Nexenta there
<j^> Pygi as good questions and i will respond
<Pygi> j^: well, I said that I hope the packages are good ^_^
<Pygi> j^: have you applied patches that are currently applied to official version?
<KaiL> something off-topic: kubuntu has a tool to configure the X-Server, ubuntu doesn't even has something in universe for that?
<ogra> Burgwork++ :)
<j^> Pygi just look at it, and as i said before, its upstream orig + debian from 0.6.1 + hostap patch
<KaiL> j^, as you say hostap - something for you maybe: bug 6369
<Ubugtu> Malone bug 6369 in network-manager "Does not work with hostap driver" [Normal,Unconfirmed]  http://launchpad.net/bugs/6369
<Tonio_> j^: are you the uploader if this : http://revu.tauware.de/details.py?upid=2222
<Tonio_> ?
<Tonio_> hello everyone :)
<Pygi> hi Tonio_
<j^> Tonio_ yes
<Tonio_> Pygi: knetworkmanager works with vpn :)
<Tonio_> j^: same news for you :)
<Pygi> Tonio_: congrats
<Tonio_> Pygi: the problem is that vpn component provides lots of gtk dependancies
<Tonio_> but anyway, that works :)
<Tonio_> I couldn't test with vpnc, only openvpn
<Tonio_> j^: if any help required on vpn nm packages, plz ask :)
<KaiL> bug 37098 can not be reproduced here - somebody can?
<Ubugtu> Malone bug 37098 in network-manager "when nm-applet quits it's space on the notification area isn't recovered" [Normal,Unconfirmed]  http://launchpad.net/bugs/37098
<j^> Tonio_ not right now, but if issues come up on revu, i might, thanks for the offer
<Tonio_> j^: I will try to take time to revu your uploads quickly, to earn time
<Pygi> KaiL: it can be confirmed, altought I think it's gnome-panel issue
<KaiL> imho the icons only stay apard, if they are set to have a gap in panel config
<KaiL> so no real bug, only some "we didn't know, that you want it to move closer"..
<Pygi> yup
<KaiL> https://wiki.ubuntu.com/UbuntuMainInclusionQalculate that's meaned as a joke, or? ;)
<Pygi> o joy
<Pygi> KaiL : :P
<KaiL> compared to that tool a TI89 is easy to understand
<Pygi> lol
<KaiL> bah, HTML mail :p
<Pygi> Kail, j^: can I go to sleep now? ;)
<Pygi> KaiL: ah, yes, I know :p
<Pygi> a lot of people complain because of HTML :P
<Pygi> ok, I really have to go to sleep now
<Pygi> bye all ;)
<dAndy> is there a guide anywhere on the correct way to rebuild mini.iso with additional kernel modules? (I got 90% there, except after Iso linux loaded and it loaded the initrd, I just got black screen)
<jdub> mjg59: ping
<mjg59> jdub: Hi
<jdub> mjg59: seen this?
<jdub> Setting up acpi-support (0.66) ...
<jdub> Installing new version of config file /etc/acpi/prepare.sh ...
<jdub> Installing new version of config file /etc/acpi/resume.sh ...
<jdub> Installing new version of config file /etc/acpi/sleep.sh ...
<jdub> Installing new version of config file /etc/init.d/acpi-support ... * Checking battery state...
<jdub> cat: /sys/class/net/eth1/device/power/state: No such file or directory
<jdub> /usr/share/acpi-support/state-funcs: line 10: test: : integer expression expected
<jdub> 
<jdub> hrm, which n-m packages are the ones to be testing atm?
<jdub> j^'s or the ones on kubuntu.no-ip.org?
<mjg59> jdub: Nup
<mjg59> sladen: ^
<jdub> mjg59: ahr - thanks
<ogra> jdub, not 0.6.something from the archive ? 
<jdub> ah, the no-ip ones appear to be crack, and j^'s ones appear to be 0.6.2 upgrades based on what's in the archive
<ogra> jdub, you didnt happen to follow the automatix thread on -users today, did you ? 
<jdub> ogra: no - anything interesting?
<ogra> yep
<ogra> jdub, arnieboy stepped in to the discussion through the forums gateway
<jdub> j^: i think you need to update your packages to reflect the libnl1 -> libnl1-pre6 change
<jdub> ooh, NetworkManager sig11s
<ogra> jdub, https://lists.ubuntu.com/archives/ubuntu-users/2006-March/071765.html
<jdub> oh man
<jdub> ogra: thanks
<ogra> jdub, the problem is the forums portal 
<ogra> we wouldnt be able to lock out arnieboy
<jdub> that is not the problem :-)
<ogra> nomeata, indeed
<ogra> grmbl
<ogra> no indeed
<ogra> but its an additional one as long as the myth "the CoC doesnt matter for the forums" goes round
<hendry> is there a known issue with X in dapper? my X screen is garbled
<ogra> hendry, not here and not on my 2 testinstalls i did today
<ogra> (ati on ppc and nvidia on amd64, both with free drivers)
<hendry> my other machine is a pretty generic T30
<hendry> oh well, i'll look the logs
<Amaranth> do you have the ubuntu4 xserver-xorg-driver-ati package?
<j^> jdub uploaded new build against libnl1-pre6 
<jdub> from n-m in main:
<jdub> 
<jdub> Mar 29 11:51:53 localhost NetworkManager: <information>^Istarting...
<jdub> Mar 29 11:51:54 localhost NetworkManager: <WARNING>^I main (): nm_data_new: Setting up dbus filter
<jdub> Mar 29 11:51:54 localhost NetworkManager: <WARNING>^I nm_signal_handler (): Caught signal 11.  Generating backtrace...
<jdub> Mar 29 11:51:54 localhost NetworkManager: ******************* START **********************************
<jdub> Mar 29 11:51:54 localhost NetworkManager: (no debugging symbols found)
<jdub> Mar 29 11:51:54 localhost NetworkManager: Using host libthread_db library "/lib/tls/i686/cmov/libthread_db.so.1".
<jdub> Mar 29 11:51:54 localhost NetworkManager: (no debugging symbols found)
<jdub> Mar 29 11:51:54 localhost last message repeated 5 times
<jdub> Mar 29 11:51:54 localhost NetworkManager: [Thread debugging using libthread_db enabled] 
<jdub> Mar 29 11:51:54 localhost NetworkManager: [New Thread -1211435328 (LWP 8526)] 
<jdub> Mar 29 11:51:54 localhost NetworkManager: (no debugging symbols found)
<jdub> Mar 29 11:51:54 localhost NetworkManager: (no debugging symbols found)
<jdub> Mar 29 11:51:54 localhost NetworkManager:
<jdub> Mar 29 11:51:54 localhost NetworkManager: (no debugging symbols found)
<jdub> Mar 29 11:51:54 localhost last message repeated 7 times
<jdub> Mar 29 11:51:54 localhost NetworkManager: 0xffffe410 in __kernel_vsyscall ()
<jdub> Mar 29 11:51:54 localhost NetworkManager: ******************* END **********************************
<jdub> 
<jdub> ^ full of awesome
<infinity> Pretty awesome that is auto-backtraces itself.
<infinity> Shame that it's such a useless trace.
<jdub> i might build n-m with debug
<jdub> symbols
* infinity reboot for great kernel testing justice, and to see what the new NM does when he comes back...
<infinity> s/reboot/reboots/
<HrdwrBoB> I'm not sure if network manager ate my mpi350
<HrdwrBoB> or if the drivers are broken, but it's .. not working very well
<crimsun> if you have no problems using wpasupplicant directly, then it's more than likely n-m
<jdub> testing n-m on my laptop is pretty pointless anyway, because it has an atheros blob on it
<jdub> (which doesn't let you maintain a connnection and scan at the same time)
<jdub> what's the DEB_BUILD_OPTIONS thing to keep debug symbols? just debug?
<crimsun> nostrip
<HrdwrBoB> crimsun: mp ot
<HrdwrBoB> s kist we[
<HrdwrBoB> er it's just WEP
<HrdwrBoB> works perfectly on an unencrypted network
<HrdwrBoB> http://kaos.vicnet.net.au/dmesg.txt
<jdub> http://ubuntu.pastebin.com/627963
<jdub> ^ uh. gee, thanks!
<Amaranth> canonical hosts the forums?
<infinity> Score!
<infinity> Mar 29 12:14:48 localhost NetworkManager: <WARNING>^I nm_dbus_get_network_data_cb (): nm-dbus-nmi.c:404 (nm_dbus_get_network_data_cb): a message argument (trusted) was invalid.
<infinity> And then nm-applet tells me there are no valid devices.
<infinity> (This was after NM logged about finding and controlling both my devices)
<infinity> Rck.
<infinity> Rock, too.
<infinity> Hrm, my machine got a lot more orange again.
<Burgwork> jdub, should I move the wikipedia article from Ubuntu Linux to Ubuntu (Linux)?
<jdub> Burgwork: that'd be really cool :)
<Burgwork> jdub, will do
<Burgwork> jdub, can you ping henrik to get him to change the page name to Ubuntu, not Ubuntu Linux?
<jdub> Burgwork: that might not be done for SEO reasons
<Burgwork> jdub, can it be "Ubuntu - Linux for Human Beings"?
<jdub> Burgwork: possibly
<`anthony> jdub: or call it "Ubuntu Linux <font color="white">Linux Redhat Gentoo Linux Linux Linux</font>" for SEO reasons?
<Burgwork> ok, cleaned up wikipedia
<OgMaciel> jdub, excuse me... do you have 1 minute, please?
<infinity> Riddell: Around?
<Riddell> infinity: hi
<infinity> Riddell: Did you look at the debtags FTBFS?
<yves> hmm is python-support borked?
<infinity> (Yes, I know you've been busy clogging up the buildds with a new KDE version)
<Riddell> infinity: I did, it'll need a copy of libapt-front to be included with debtags
<Riddell> since debtags and adept don't currently use the same version
<infinity> The debtags version in Debian won't work with it?
<Riddell> no, it needs libapt-front 0.3.8
<infinity> Statically linking in another copy if libapt-front sound like the Wrong Solution.
<Riddell> and adept needs 0.3.7
<Riddell> liapt-front is a static library only anyway
<infinity> I take it that porting adept to libapt-fron 0.3.8 is too much effort?
<Riddell> it breaks feature freeze
<Riddell> and upsets the adept development cycle, which is all planned (and bountied)
<infinity> Fair enough.
<infinity> Then whatever needs to be done to get debtags happy (as long as it still work with the rest of the world, however it's meant to) is fine by me.
<Riddell> I'll take a look at it when I wake up
<Riddell> by which time hopefully you'll have poked all of KDE to compile :)
<infinity> It looks to be going well this time around, so it should be okay..
<infinity> Anything in here that will be binary NEW?
<Riddell> nope
<infinity> Then if it's all buildable, it should be smooth sailing.
<infinity> Hrm, qt-x11-free is stuck in NEW.
<infinity> And kerry.
<infinity> qt-x11-free-dbg is NEW.
<Riddell> ah yes, there is that
<Riddell> kerry is a MOTU job, kamion was waiting on them uploading a FHS compliant version which they should have now
<infinity> Kay, the -dbg package should head to universe for now, I assume?
<bddebian> qt-x11-free SUCKS.. :-(
<infinity> Riddell: ?
<Riddell> yes, universe is fine
<infinity> Alrightr.  Doing.
<Riddell> bddebian: why?
<bddebian> Riddell: PATH_MAX :-)
<Riddell> qmake is interesting
<bddebian> I have been fighting with qt-x11-free on and off for months for GNU/Hurd for shit I know will never get in Debian anyway :-(
<slomo__> bddebian: what's the problem with PATH_MAX on hurd?
<ajmitch__> slomo__: there is none
<ajmitch__> ie, no PATH_MAX
<bddebian> slomo__: We don't define it because theoritically we have no limit
<bddebian> Same for MAXHOSTNAMELEN
<ajmitch__> not that it really matters for us until some crazy person decides to make an ubuntu gnu/hurd
<slomo__> bddebian: why don't you just define them to be the same as INT_MAX somewhere as a workaround?
<bddebian> slomo__: It's not my call in Debian.  If I make an Ubuntu/Hurd I will define them all and use a true /usr dir
<slomo__> fabbione: hi... i'm currently testing mono 1.1.13.6. would you mind porting the sparc patches to 1.1.13.6 when it's working fine and get a UVF exception? one doesn't apply cleanly... and do you have any patches pending?
<infinity> slomo__: How not cleanly are we talking? :)
<infinity> slomo__: Since Fabio's not around, I can help you get the patches ported.
<infinity> slomo__: (Assuming you think the UVF exception will be granted)
<slomo__> infinity: 2/3 hunks rejected in one of the 4 patches he added
<infinity> slomo__: Sure, but did you look at the rejects?  Probably just a tiny bit of broken context.
<slomo__> infinity: and i think the UVF exception will be granted as it's a bugfix-only release
<infinity> slomo__: If you give me your current test packages, I can quickly forward-port the patches.
<slomo__> infinity: not yet, i'll do it after some testing... and ping you when i can't get it done myself :)
<infinity> slomo__: Kay.
<trappist> I just read a blog complaining about the lack of out-of-the-box mp3 support in ubuntu and that only artsplay would play mp3s.  I verified that it does on my box, compiled with --disable-libmad, but I have libmad etc. installed. 
<HrdwrBoB> there's no outofthebox mp3 support in any distribution
<trappist> HrdwrBoB: there's not supposed to be, but at first glance it looks like artsplay might accidentally support it out of the box.
<HrdwrBoB> yeah
<slomo__> infinity, fabbione: looks good, the rejected patches were applied upstream... infinity, could you run a testbuild on sparc?
<slomo__> infinity: http://go-mono.com/sources/mono-1.1/mono-1.1.13.6.tar.gz http://slomosnail.de/~slomo/temp/mono_1.1.13.6-0ubuntu1.diff.gz http://slomosnail.de/~slomo/temp/mono_1.1.13.6-0ubuntu1.dsc
<infinity> slomo__: Remind me again after all the kde backlog is done building. :)
<slomo__> infinity: ok :)
* infinity runs off for some lunchtime goodness.
<bur[n] er> I have a small request of anyone with website control... could someone make bugs.ubuntu.org and bugs.ubuntu.com point to https://launchpad.net/distros/ubuntu?  It's tricky to find bug reporting when most are used to bugs.gnome.org bugs.xfce.org bugs.mozilla.org bugs.debian.org bugs.kde.org etc. etc.
<bur[n] er> I couldn't find where to "bug report" this to in launchpad, so I figured I'd try here since it's an easy fix
<Burgundavia> bur[n] er: can you email henrik@canonical.com ?
<infinity> bur[n] er: Not really a launchpad bug anyway, since LP doesn't control the ubuntu DNS.
<bur[n] er> gotcha... I'll email that person, thanks
<freeflying> bug3 35758
<freeflying> bugs 35758
<freeflying> bugs #35758
<infinity> s/s//
<freeflying> bug #35758
<Ubugtu> Malone bug 35758 in xinit "startx leaks .serverauth.???? files" [Normal,Unconfirmed]  http://launchpad.net/bugs/35758
<freeflying> infinity: thx
* infinity finds another ReducingDuplication candidate and bumps it off.
<wasabi> Dapper update results in Begin: Waiting for root filesystem on boot... =/
<wasabi> Never happened, timeout, drop to busybox
<wasabi> init-premount looks silly.
<wasabi> what happened to this?
<infinity> That logic got removed from udev and moved to init-premount.
<infinity> In theory, it works better.
<infinity> For everyone except you.
<wasabi> Well it does't look like it takes into consideration evms
<wasabi> I don't suppose anybody has considered explicitly passing the driver as a kernel arg? heh.
<wasabi> Sounds "easier".
<infinity> Err, s/init-premount/local/ even.
<wasabi> I think I'm timeing out in scripts/init-premount
<wasabi> In the SCSI case...
<Rotund> Has anyone considered putting a "failsafe" xorg.conf in case GDM doesn't come up correctly?
<wasabi> init-premount/udev I mean
<infinity> wasabi: init-premount/udev doesn't have that "Waiting for root filesystem" stuff anymore...
<infinity> wasabi: If yours does, you need to upgrade again.
<wasabi> Hmm. I might be slightly out of date.
<insites> what is the desired behavior of mounting fat32 and ntfs partitions these days? should they be automounted? and if not and they are mounted using disks-admin should the mountpoint "stick" through a restart?
<wasabi> Hey so, I just came up with the "pass drivers as kernel args" idea... and it sounds pretty decent.
<wasabi> Or something. =/
<wasabi> I've seen at least 100 different "lets auto detect the root device driver" hacks pass thru initramfs it seems
<wasabi> I see. Could be timing out simply because evms is missing.
<pitti> Good morning
<Rotund> wasabi: The evms does take quite a while to startup
<desrt> funny you should say
<wasabi> looks like evms-activate wasn't being called.
* desrt is customising a livecd just now and hacked lvm/evms out of the startup for this very reason :)
<wasabi> I am guessing, though i am probably wrong...
<wasabi> evms has no prereq for udev
<wasabi> lvm and md do...
<wasabi> yup that was it.
<wasabi> local-top/evms needs a prereq on udev
<wasabi> evms gets called first, fails as there are no devices, then the devices appear!
<pitti> infinity: imlib2 porting> not so far
<pitti> I just asked him whether it was possible
<infinity> Ahh, kay.
<infinity> I think he tried, but failed. :)
<infinity> (Well, "tried", by changing the includes, and it FTBFSd)
<infinity> Anyhow, it'll need some serious API porting, I think, to make it happen, which is a shame, cause it's the only thing holding imlib in main.
<pitti> infinity: do you have any opinion about php-sqlite?
<infinity> pitti: Yeah, my opinion is that I should break it out of the tree, build a php5-sqlite (that still uses sqlite0) and send that to universe, and build php5-sqlite3 for main.
<infinity> pitti: Just need to find a bit of time to make that change.
<infinity> pitti: Will have to be after Flight-6, probably, since I have much "is the archive buildable and installable?" and "Hey, the livefs stuff is kinda goofy right now" stuff to sort.
<pitti> infinity: sounds good; also, I'll try to get rid of gtk1.2 with seb
<infinity> And launchpad has stopped talking to me.  Feh.
<infinity> Ahh, there we go.
<Burgundavia> I need an apt expert, to vet a paragraph I am writing
<infinity> How expert?
<infinity> Most of us should be expert enough, unless you need mvo's internal knowlege of the scary C++.
<Burgundavia> not mvo expert, but familiar with most of what it does
<Burgundavia> infinity: can you receive messages?
<wasabi_> man, caching mime types in xattrs does not seem like a bad idea, to me. 
<desrt> wasabi_; do not hold your breath
* desrt has had a patch for this idea in gvfs bugzilla for about 3 years
<wasabi_> What the hell is keeping it?
<desrt> lack of attention and alex saying that it's a bad idea
<desrt> someone told him that doing an xattr lookup takes a long time
<wasabi_> It makes perfect sense for me for mime types to be saved from the browser too.
<desrt> (which is insane, of course, if you compare with (for example) content sniffing)
<desrt> ya.  i mention that in my report, i think :)
<wasabi_> browser gets image/jpeg from server, should save in xattr.
<wasabi_> Should just be a basis. A test can still happen.
<spacey> its probably best to properly check the content at least once
<desrt> heh
<spacey> not really trustworthy what the browser gets:p
<desrt> i filed the bug in 2003
<wasabi_> I dunno. I think it's perfectly reasonble for the type to be seperate from the contents.
<desrt> http://bugzilla.gnome.org/show_bug.cgi?id=129792
<wasabi_> Weither it's trustworthy or not.
<kagou> hi
<Ubugtu> Gnome bug 129792 in MIME and file/program mapping "linux extended attributes support for gnomevfs mime types" [Enhancement,New]  
<wasabi_> heh
<wasabi_> the sniffing is just icing on the cake.
<wasabi_> and for fixing stuff where the type doesn't move properly.
<wasabi_> but two gnome users, emailing a file to each other? Pssh.
<wasabi_> me->bed
<desrt> really, gnome user receiving mail from anyone
* desrt reminds wasabi_ what MIME stands for :)
<wasabi_> sure, but it's of course obvious that not all files come with the right mime type
<infinity> Images are infamous for having incorrect mime-types from a web server.
<carlos> pitti: hi, did you have time to test the languagepacks?
<pitti> hm, is it just me, or is LP slooooooow ATM?
<pitti> carlos: I didn't so far; if they are good now, I'll happily take a look at them
<ajmitch> pitti: yeah, something is wrong
<carlos> pitti: still have problems with the exported .pot files and we are missing kde.
<spacey> gnome didn' like my latest dapper update, brb
<carlos> pitti: just test it when you have sometime, don't worry. Just want to be sure we don't miss anything before you need to use them :-P
<pitti> carlos: no problem, I can throw your tarball on top of mine, so that we have KDE
<pitti> carlos: how many non-KDE packages were imported so far?
<carlos> doko: openoffice.org is still being imported... it's taking more than 16 hours to get it imported... wow
<carlos> pitti: I think most of them are already imported
<carlos> perhaps I need to do some manually imports to have a full import, but KDE's .po files were just imported and we got 35000 new entries....
<carlos> I need to finish the special handling of KDE language packs to import them automatically before I can check that all entries are imported now
<Treenaks> can't the KDE langpacks get their own -changes list? ;)
<desrt> pitti; hear about hal's solution to the spawn-privileged-processes problem?
<desrt> davidz wrote a kernel module... it exports a character device that when you open it and write a magic string to it it changes the euid of the current process to 0
<desrt> the idea is that hal can run as a normal user and when it needs to do a callout it forks, the child opens and writes to this device and then execs what it needs to
<desrt> pretty spiffy
<ajmitch> sounds crackful
<mjg59> Why not just have a suid helper?
<pitti> desrt: what's wrong with the current hal-runner daemon?
<desrt> sigh.
<desrt> nobody understands my jokes :(
* pitti deletes his line which started to rant about this crackful idea and hugs desrt
<pitti> :)
<mjg59> Your jokes need a kernel helper
<ajmitch> desrt: the problem is it's all too possible :)
<desrt> pitti; i guess you've come to expect a certain behaviour from the hal devs... :)
<pitti> desrt: well, that would have been yet another level
<pitti> desrt: but it's not so far fetched; look at CAP_SETPCAP and what jack wants to do with it :)
<desrt> the device would be called /dev/beanstalk :)
<desrt> what is SETPCAP?
<desrt> the capability that allows a process to change its own capabilities?
<pitti> desrt: it allows processes to raise the caps of other processes
<desrt> that makes a lot of sense
<pitti> no, it doesn't :)
<desrt> explain to me why we have a CAPS system at all
<desrt> afaik, in your average linux install, they're all basically just hardwired to the predicate (uid==0)
<pitti> desrt: more fine grained privileges
<pitti> desrt: no, to the contrary
<pitti> desrt: the kernel (almost?) never checks the uid any more
<pitti> just capabilities
<desrt> i know
<desrt> but the caps themselves are as follows:
<desrt> root: has all caps
<pitti> desrt: i. e. we can have our dhcp client running as normal user with just CAP_NET_ADMIN
<desrt> everyone else: nothing
<desrt> how does it get that?
<mjg59> desrt: There's no good way to grant specific privileges to processes, but it's uesful for dropping all unneeded privileges
<pitti> desrt: or, in warty, hal was a normal user with CAP_NET_RAW (or so), so that it could do link detection on ethernet cards
<desrt> right.  how do i give caps to processes? (serious question - i'd like to know)
<pitti> desrt: prctl( PR_SET_KEEPCAPS, 1, 0, 0, 0 ); setgid(); setuid(); cap_set_proc()
<pitti> desrt: the first one will not drop your caps on setuid
<desrt> that's pretty nice
<pitti> desrt: and after switching to the low-priv user, you drop all caps you don't need
<desrt> well, actually, it has a very very evil race
<pitti> desrt: download the dhcp3 sources and look at debian/patches/droppriv.dpatch
<pitti> desrt: it has a generic drop_privileges(user, group, caps) function
<desrt> between the point of setuid() and cap_set_proc() it's ptraceable by other processes of the same uid
<desrt> and has full caps
<pitti> desrt: no, it's not
<pitti> desrt: the kernel doesn't allow you to ptrace processes with nonzero caps
* desrt raises eyebrow
<desrt> oh.  sweet :)
<pitti> desrt: some Unixes even go further - they have kind of a 'pink bit' in the proces
<pitti> so that you can't even trace processes which *ever* had root
<pitti> and just keep an open fd to a privileged file
<pitti> no idea whether linux does that as well
<desrt> well
<desrt> if a process has priv
<desrt> ... hmm, actually
<desrt> it's totally sane to say "keep priv that i need to open this file and drop it as soon as i can"
<desrt> openvpn does this for /dev/tun
<pitti> yep, some hal helpers do that as well
<pitti> desrt: or the dhcp server - start as root, open priv'ed port, drop to normal user
<Burgundavia> pitti: how crackful is pygame?
<pitti> dhcpd@donald:~$ gdb /usr/sbin/dhcpd3 5610
<pitti> Attaching to program: /usr/sbin/dhcpd3, process 5610
<pitti> ptrace: Operation not permitted.
<pitti> desrt: yay ^ pink bit :)
<desrt> i'm afraid i don't get it
<desrt> every process on earth used to be root
<desrt> "was owned by a non-zero uid at time of fork()" is no measure
<pitti> desrt: not after my derooting rave in the warty time :)
<desrt> nor "exec"
<desrt> since you can have fds live across execs
<ajmitch> which really can be a bad thing
<pitti> desrt: of course, we can't deprive processes of the privs they actually need :)
<pitti> desrt: *of course* you can send bad dhcp responses to other clients if you manage to break the dhcp server
<pitti> desrt: likewise you can spam /var/log/kern.log if you break klogd
<pitti> desrt: the point is that you can't do anything else
* desrt gets angry at 'the other ta'
<pitti> desrt: 'ta'?
<desrt> teaching assistant
<pitti> ?
<desrt> i'm a ta in a course right now... i teach, create the assignments, etc
<desrt> the other ta marks the assignments
<desrt> i don't like his marking very much
<neuralis> desrt: what class?
<desrt> x86 assembly language
<desrt> oldschool style
<pitti> brb, I need to restart my X
<neuralis> desrt: neat.
<ajmitch> pitti: I remember a RH dev telling about how bad things could happen when dhclient inherited or didn't close fds properly
<ajmitch> since the scripts it ran also get those fds
<pitti> ajmitch: our's can't be worse than anyone else's which run as root, can it?
<infinity> Kamion: Around?
<ajmitch> only found when they caught it via selinux :)
<neuralis> desrt: where is this, if you don't mind me asking?
<desrt> neuralis; mcmaster university
<desrt> neuralis; hamilton, ontario
<neuralis> desrt: cool. not many universities (still) offer low-level programming classes, sadly.
<desrt> i have a riot teaching it
<desrt> it's really oldschool stuff.
<desrt> like TSRs and modifying the realmode IVT to install the IRQ handler for your hardware driver
<neuralis> desrt: +1. if more places taught things like assembly, maybe we'd be graduating fewer java monkeys who call themselves programmers.
* desrt checks out the assignment svn to discover that someone has checked in a very large divx file
<desrt> i can only assume this is a screencast?
<desrt> 120megs and still downloading....
<Simira> huh. Didn't Mithrandir realize he's offline yet?
<desrt> neuralis; heh.  if they were even _good_ at java, i'd be happy
<spacey> ah i lost all my epiphany bookmarks+settings (after an crash and an upgrade)
* Fjodor quite likes the fact that we are taught java, but it is only natural at my uni. It has a strong OO tradition, and even had Christer Nygaard as a guest professor for quite some years before he died
* infinity cracks open a beer as he marvels at how long OpenSSL takes to build..
<Mithrandir> Fjodor: Kristen, not Christer.
<Fjodor> Sorry
<Fjodor> But you did know of whom I spoke :-)
<Simira> oh, he's Danish...
<Fjodor> Norwegian
<Simira> I am bored... I suppose noone here knows TikiWiki exceptionally well...?
<Simira> Fjodor: I was talking about you ;)
* ogra knows TiddlyWiki :)
<Fjodor> Ah :-)
<Fjodor> Very much so, yes
<Simira> ogra: did you just volunteer? :)
<dholbach> hellas!
<Simira> dholbach: what, are you reading HP in Greek now?
<ogra> Simira, TiddlyWiki != TikiWiki :)
<Simira> ogra: sorry, I misready
<dholbach> Simira: not really... :-)
<Simira> dholbach: not yet, you mean?
<Simira> ;)
<robitaille> humm...the recent network-manager upgrade on Dapper has killed my wireless...
<Simira> hm, I have a meeting. Hurrah.
<dholbach> yeah, probably... I really need to visit greece again
<Simira> I'd like to go there too... only been to Cyprus
<Mithrandir> UI sprint is over now, isn't it?
<mvo> Mithrandir: oh yes :)
<dholbach> heya seb128
<Simira> was that in Greece?
<seb128> hi dholbach
<Simira> morning seb
<dholbach> Simira: unfortunately not, it was in London
<seb128> hi Simira
<dholbach> I'd be all for Greece :)
<Simira> dholbach: I like London :D
* dholbach should move there
<dholbach> ... in the rain
<Simira> Greece in June would be nice :)
<Simira> but... meeting. 
* ..[topic/#ubuntu-devel:Mithrandir] : Ubuntu Development (not support, even with dapper) | #ubuntu for support and general discussion | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/DeveloperResources | http://wiki.ubuntu.com/HelpingWithBugs | If your initramfs is broken in any way, please save a copy for infinity | Soyuz updated, report issues in LP | Flight-6 freeze - uploads to main must be authorised by infinity/Mithrandir
<Mithrandir> ogra: can you please get edubuntu live (including espresso) and install cds tested?
<Mithrandir> Riddell: can you please get kubuntu live (including espresso) and install cds tested?
<ogra> Mithrandir, sure, give me 1h :)
<janimo> Kamion, besides promoting xubuntu-meta to main is there anything else needed before building CDs?
<slomo> infinity: do you have some time to testbuild mono on sparc now? at least the sparc buildds are idle now :)
<sivang> morning all
<pitti> hi sivang
<infinity> janimo: Does xubuntu-live stand a hope of working?  If so, I can set up livefs builds for you in a few days.
<sivang> hey pitti
<infinity> slomo: Sure, point me at the source again.
<janimo> infinity: had not give the live seeds as much care as the desktop one
<janimo> but I will once install CDs are out
<janimo> in theory it should work :)
<janimo> thanks 
<slomo> infinity: http://go-mono.com/sources/mono-1.1/mono-1.1.13.6.tar.gz http://slomosnail.de/~slomo/temp/mono_1.1.13.6-0ubuntu1.diff.gz http://slomosnail.de/~slomo/temp/mono_1.1.13.6-0ubuntu1.dsc
<infinity> slomo: Looking for testsuite regressions when you're doing test builds (not that the debian build doesn't run the testsuite, cause it takes FOREVER), or are you just checking that it builds?
<infinity> s/not/note/
<slomo> infinity: just test that it builds... for sparc there are still some issues left with the testsuite according to fabbione iirc
<slomo> infinity: but i tested it here with a bunch of applications, not with the test suite... but that's a good idea ;)
<infinity> slomo: Very few issues, mind you, and I have the output from the last testsuite run. :)
* infinity is good at comparing.
<slomo> infinity: ok :) would be nice if you have some time to run the testsuite as well and look for regressions
* Mithrandir wonders if Removed nm-applet from live-i386, live-amd64, live-powerpc, live-ia64, live-sparc, live-hppa is correct
<infinity> Mithrandir: And "added network-manager-gnome"
<infinity> Mithrandir: I assume.
<Mithrandir> yup
<infinity> Then yes, it's correct. :)
<Kamion> infinity: hi
<Kamion> Mithrandir: Kubuntu needs an espresso upload
<infinity> Kamion: Hey.  No idea why I was poking you.
<Kamion> but I have something else I'm trying to sort out first, ideally
<Kamion> janimo: don't think there's anything else
<Mithrandir> Kamion: ok.  Any ETA on it?
<Mithrandir> Kamion: also, can you please disable daily builds of cd images?
<janimo> Kamion: ok. xubuntu-meta is build now with only main deps
<janimo> built
<Kamion> Mithrandir: hopefully next hour or so
<Kamion> well, on source upload anyway
<Mithrandir> Kamion: ok, I need to do an ubuntu-meta upload for the nm stuff anyway, so an hour more or less won't mean that much.
<Kamion> Mithrandir: /home/ubuntu/Desktop/ seems to be root-owned on the live CD
<Kamion> I thought we fixed that?
<Kamion> otherwise, probably need a casper upload ...
<infinity> Argh.  The part where NetworkManager appears to segv isn't good either.
* infinity didn't notice this until he'd upgraded to network-manager-gnome, since before that, nm-applet just plain didn't work with the backend.
<Kamion> Mithrandir: daily builds> done (you can do that yourself, BTW, the crontab is owned by cdimage)
<Mithrandir> Kamion: oh, ok.
<Mithrandir> (thanks)
* Kamion glares at debconf.py
* infinity gets out and pushes ia64 and hppa to finish building KDE.
<infinity> Mithrandir: livefs dailies disabled now too.
<Mithrandir> infinity: thanks
<infinity> Mithrandir: I don't recommend building ports-live.  hppa and sparc still aren't set up, and weddell (ia64) is about to -ENOSPACE, because it just loves me SOO much.
* infinity needs to sort that tomorrow.
<infinity> Mithrandir: The three release arches all look good to go, though.
<infinity> Mithrandir: Doing one ports run for install (to match whatever you happen to release for non-ports) might be nice, though.
<Mithrandir> infinity: is there anybody who are able to test the ports?
<infinity> Mithrandir: Likely not, but then again, you won't include them in your release announcement either.
<infinity> Mithrandir: Would just be nice to have a matching snapshot of "this is when we think the archive might not have sucked" to later test on sparc/hppa/ia64 boxen.
<Mithrandir> infinity: agreed
<infinity> It'll also be a couple more archive cycles for Riddell's KDE uploads to all settle again, so if he wants fresh Kubuntu Flight-6 love, there's a few hours to wait there, I'd guess.
<infinity> Oh, actually.  I lie.
<infinity> KDE should be fully up to date on all release arches as of now.  So any fresh kubuntu build will be good.
<infinity> (Lagging on ports still, that's all)
<sladen> mjg59: ta
<Kamion> grr. I hate everything.
<janimo> Mithrandir: should uploads be puton hold until flight 6 is out?
<janimo> this time I upload to main so it matters more that last time
<Kamion> janimo: uploads to main should be coordinated with Mithrandir and infinity
<Mithrandir> janimo: to main, yes, unless it's something you want into flight-6 in which case ask infinity or me (with a diff)
<janimo> Mithrandir: I have nothing for flight 6 I just remembered from last time
<Mithrandir> janimo: yup, thanks.
<infinity> s/and infinity// unless this is still going on when I wake up tomorrow.
<janimo> and saw no announcement requesting hold on the list
<infinity> I wonder if I'm sober enough to debug why NM is segfaulting on my system...
<infinity> slomo: Your mono build is FTBFS on sparc.
<slomo> infinity: nice... can you paste it somewhere?
<infinity> slomo: I'll re-run it and actually save the log this time for you. :)
<Mithrandir> Kamion: how did you disable the daily runs?  etc/crontab on little shows the entries as uncommented?
<Kamion> Mithrandir: crontab -e
<Kamion> I generally leave etc/crontab as the reference version
<infinity> This is where Mithrandir discovers he can "sudo su - cdimage" :)
<Mithrandir> infinity: indeed. :-)
<Mithrandir> infinity: given that nobody told me this before. :-P
<Kamion> heh, oops
<sladen> jdub: do you have an Asus laptop?
<infinity> Typical elmoism.  I nervously "sudo -l" on any host I have access to, to see what users I can su to. :)
<infinity> It's almost as muscle memory as typing "ls -l" randomly for no good reason.
<janimo> Mithrandir: now that Kamion promoted  xubuntu-meta I may want something in Flight 6 ;) but I assume you're busy so it can wait after that
<infinity> janimo: You may have to wait in line, but if Mithrandir manages to get Ubuntu Flight-6 out today, I can work with you tomorrow on a Xubuntu Flight.
<janimo> infinity: great! thanks
<ogra> GAH+
<ogra> Mithrandir, do you know how old my live image is ?
<Kamion> ogra: http://people.ubuntu.com/~lamont/liveLogs/
<ogra> infinity, ^^^ ?
<infinity> ogra: Which arch?
<ogra> amd64
<Kamion> look for yourself :-)
<infinity> They should all be pretty up to date.
<ogra> its outdated a week or so
<pitti> dholbach: I hacked a braindead, but working 'syncpackage.py' script and would like to do some universe syncs which also involve new upstream versions; can I do them if I make sure that they are sane?
<infinity> The only arch failing is ia64, IIRC.
<ogra> i have old artwork ...
<ogra> hrm#
<dholbach> pitti: sure
<Kamion> or, not. is liveLogs not being updated any more?
<infinity> Oh, no, edubuntu is uninstallable.  Rock.
<ogra> infinity, nope, it just has the wrong artwork 
<Kamion> if infinity tells you that the buildd thinks it's uninstallable, the buildd is probably right ...
<ogra> yeah, i see it in the logs
<infinity> ogra: It's uninstallable on amd64 and powerpc.
<ogra> grrr
<ogra> who broke kstars
<infinity> Though, that's new.  It was fine yesterday.
<infinity> So your images can't be THAT out of date.
<ogra> i fixed the artwork on the weekend ...
<Kamion> Riddell just uploaded KDE 3.5.2; it may have been a transient problem
<ogra> grmbl 
* ogra make a chroot and checks
<infinity> Probably just transient, yes.
<KaiL> spinnt ICQ rum?
<infinity> ogra: You want to update your -meta, s/nm-applet/network-manager-gnome/ and reupload anyway.
<infinity> ogra: Your nm-applet and network-manager are out of sync on the images that did succeed because of that.
<pitti> KaiL: inglisch spoken here :)
<KaiL> oops
<ogra> infinity, are you sure the 0.6 packages work at all ?
<ogra> it looked different last night ...
<infinity> ogra: Given my system's state, I'm going to go with "no", but they won't work any better with mismatched frontend and backend. :/
<Kamion> tough, if they don't work that's life
<Kamion> we don't randomly ship with older NBS binaries just for the fun of it :)
<ogra> yes, but that leaves us without network on the livecd
<Kamion> in fact, how about I go and remove nm-applet, just to make sure
<infinity> Kamion: Too late, I uploaded a new NM that builds an nm-applet transitional package.
<Kamion> ah
<infinity> Kamion: As a favour to dapper users.
<infinity> (We can remove it again later, when people have mostly upgraded from Flight-5 to Flight-6...
<infinity> )
<ogra> infinity, my chroot says kstars is installable ... so i'll need a rebiuld after edubuntu-meta has build
<infinity> ogra: Yeah, that's no problem.
* ogra updates -meta
<infinity> Kamion: How do you feel about violently removing amd64-libs-dev, and saying "tough" to the 1 or 2 universe packages still build-depending on it?
<Kamion> infinity: sure, can do, give me a minute
<Kamion> although isn't it ia32-libs-dev?
<infinity> Err, yeah, that thing.
<Kamion> although *just* ia32-libs-dev/amd64, which makes life interesting
<infinity> Ths thing making my out-of-date output all icky.
<infinity> Well, ia32-libs* on amd64 should go away eventually, as amd64 becomes fully biarch, while ia32-libs on ia64 may survive forever, since ia64 isn't really a biarch arch, it's a hack.
<infinity> (And new ia64 hardware doesn't even speak i386 anymore, so it's a niche thing there)
<infinity> slomo: Great, it failed differently the second time.  Woo.
<slomo> infinity: wonderful... i love this ;) don't tell me that there is a segfault somewhere please
* infinity tries one more build, to at least see if he can get a CONSISTENT failure.
<slomo> infinity: could you also verify that this builds fine on ia64, amd64 and ppc later?
<infinity> slomo: I can give it a sping after the Flight-6 wrangling is over.
<seb128> Kinnison: daaaaaniiiiieeeelll :)
<infinity> Okay, now my failures match.
<slomo> infinity: thanks :) but the sparc ftbfs causes me some headaches now... i hope fabbione has already a fix for it ;)
<Kamion> infinity: iz gone
<Kamion> so etherboot fakechroot x86info will FTBFS until somebody fixes them
<infinity> slomo: Or, you ported the patches wrong. :P
<infinity> Kamion: I vagely recall looking at them and deciding they were mostly broken anyway (hence why I didn't just fix them)
<infinity> slomo: http://cerberus.0c3.net/~adconrad/mono/
<slomo> infinity: i didn't port anything... there were 4 patches, two were applied upstream... the other's applied fine
<infinity> slomo: Well, we can get DaveM to look at it another time, perhaps.  For now, enjoy your build log. :)
<slomo> infinity: the buildlog makes me sad :( i think it's not possible that /proc/stat is unreadable?
<infinity> slomo: Oh, feh.
<infinity> I didn't mount /proc ... Too much beer.
<infinity> slomo: Give me those sources again?  You deleted them from your site (and I deleted them locally)
<slomo> infinity: i didn't delete them ;)
<ogra> Kamion, they FTBFSed anyway (etherboot at least)
<infinity> slomo: Again, beer.  My fault.
<Kamion> ogra: well, they'll fail harder now
<ogra> heh
<slomo> infinity: don't worry :)
<ogra> since nobody noticed until now, i think thats marginal ...
<Kamion> Mithrandir: promised espresso upload in acceptedd
<Kamion> -d
<ogra> oh ... acceptedd reminds me ...
<ogra> Kamion, can you un-NEW squeak-image ? 
<Mithrandir> Kamion: thanks.
<ogra> Kinnison, you might want to add that: http://mail.gnome.org/archives/gnome-power-manager-list/2006-March/msg00080.html
<ogra> (probably)
<Kamion> ogra: done
<ogra> Kamion, thanks a bunch in the name of our 10ppl squeak community :)
* infinity runs out for late night snacks.
<Kamion> Mithrandir: oh, CRAP
<Kamion> Mithrandir: you know my kbd-chooser upload yesterday? I never uploaded debian-installer to rebuild the initrd with it ...
<Kamion> I *hate* this lack of daily d-i
<Mithrandir> Kamion: grr, ok.  So no images until we have the new d-i in.
<infinity> I can do daily d-i, if soyuz will accept me shoving binNMUs in.
<Kamion> yeah, doing a quick no-change upload now
<Kamion> infinity: I doubt it
<infinity> It's not like getting binary uploads in is hard, but I bet the version check would fail.
<infinity> We could automate source daily-di...
<infinity> s/source/sourceful/
<infinity> Anyhow, back after food.
<Kamion> yeah, I really would rather not though
<Kamion> gets very confusing
<Kamion> much easier when I know which random enormous source tarballs I need to download and which I don't
<Kamion> (I have an archive of every debian-installer upload ever. Yes, I'm insane.)
* ogra sees Kamion in his old days running a programming-art-histrory museum 
<HiddenWolf> Kamion: any reason?
<Kamion> HiddenWolf: because I've never been successful in my repeated requests for a baz/bzr import of the relevant bits, and I need to be able to do archaeology occasionally to find out when I introduced changes
<seb128> raphink: do you try your patches sometime before uploading? :)
<raphink> seb128: sorry I had tried it but not enough *blush*
<raphink> :(
<seb128> raphink: 3 cdbs uploads to get one dir creating working ...
<raphink> sorry for that :s
<seb128> if you don't really know what you are doing maybe better to not change cdbs, no offense, but we have a load of package using it and that's not a piece of software we want to get broken
<HiddenWolf> Hey seb128, do you have any plans to upload a snapshot or 0.9.4 rhythmbox, or are we sticking to 0.9.3? (just wondering if I should file bugs)
<seb128> HiddenWolf: no way I upload a snapshot, 0.9.4 if it was here could be considered, by they changed many stuff so I doubt of it
<HiddenWolf> seb128: hm, right. I'll go checking what's broken in 0.9.3 and fixed upstream, and file a few bugs when I'm sober/awake
<seb128> HiddenWolf: looks fine, thank you
<HiddenWolf> seb128: :)
<HiddenWolf> hey, xchat-gnome was dropped from desktop?
<seb128> yeah, no need of an IRC client on the desktop
<seb128> it's rather a geeky tool
<HiddenWolf> Hm. I guess my baseline expectation differs from Average Joe
<minghua> maybe there should be a ubuntu-geek-desktop? :-)
<slomo> infinity: any news on sparc?
<dholbach> minghua: better not make decisions on what the "average geek" could like, it'll end up in flamewars and myriads of bug reports :)
<ogra> as long as vim is shipped and emacs not, all will be fine ;P
* HiddenWolf hands out helmets and gasmasks
<HiddenWolf> argh
<mjg59> Hm. Why does attempting to add a Windows printer result in it attempting to authenticate me to every Windows machine on the network?
<ogra> AD weirdness ?
<mjg59> ogra: Under Ubuntu?
<HiddenWolf> ET calling home, ofcourse
<ogra> mjg59, hmm
<infinity> slomo: I was out fetching food. :)
<ogra> https://launchpad.net/distros/ubuntu/dapper/+builds
<ogra> hmm, intresting, we have unknown buildds ?
<ogra> "Built by unknown build machine in" :)
<infinity> ogra: No, we have a half-implemented feature. :)
<ogra> :)
<infinity> ogra: Don't show "all", btw.
<infinity> ogra: It's only "superseded" builds that should show "unknown" (since they never built)
<ogra> infinity, btw, could you finally kill that xscreensaver 4.23-4ubuntu1 build ?
<ogra> we're at 4.23-4ubuntu7
<infinity> ogra: The one marked as "superseded"?
<infinity> ogra: That means it won't get tried.
<ogra> dunno, i just see it listed
<infinity> ogra: Yes, as superseded.
<ogra> oh, ah
<ogra> ok
<Kinnison> seb128: still broken?
<seb128> Kinnison: no trace on your upload on dapper-changes nor launchpad
<seb128> s/on/of
<Kinnison> odd
<seb128> if you say so
<seb128> are you sure you did upload it?
<seb128> didn't get a rejected mail?
<Kinnison> fairly
<Kinnison> nope, no reject
<Kinnison> but no accept either
<Kinnison> and I definitely signed it
* Kinnison goes to grab his laptop to check
<seb128> you are the best placed to look on what's going on I think :)
<Kinnison> seb128: indeed
* Kinnison has signed changes/dsc here, and an upload file from 16:41 UTC yesterday saying it uploaded to upload.ubuntu.com
<Kinnison> seb128: okay, worked it out, it's the classic kinni muckup only with a twist
<Kinnison> it of course failed to find 'UNRELEASED' as a distrorelease
<Kinnison> but for some reason it failed to mail me
<seb128> ah :)
<ogra> heh
<Kinnison> that's the more worrying bit
<infinity> Yeah, a reject for that would be shiny.
<Kinnison> infinity: normally it *does* reject that
<Kinnison> infinity: something has changed
<infinity> Awesome.
<infinity> Oh, I had a question for you.
<infinity> How much effort would it be to set up a pocket that publishes to a private archive in the DC?
<infinity> (For CAT/buildd use)
<Kinnison> considering currently launchpad is fully open and friendly about distros, very very hard
<infinity> Check.  I'll keep making private archives on rockhopper then. :)
* Kinnison nods
<Kamion> Kinnison: it's never mailed people on wrong-distrorelease
<Kamion> Kinnison: at least not for the last month or so
<infinity> You do this often? :)
<ogra> heh, beats me
<Kamion> no, but I look up the failures for people often
<Kinnison> Kamion: I have a mail from march 9th where it mailed me a reject for wrong distrorelease
<Kamion> Kinnison: https://launchpad.net/products/launchpad-upload-and-queue/+bug/35965
<Ubugtu> Malone bug 35965 in launchpad-upload-and-queue "exceptions in process-upload not communicated to uploader" [Normal,Unconfirmed]  
<Kinnison> Kamion: *nod* that's what I saw this time
* Kinnison cries, network-manager isn't seeing my wireless
<ogra> Kinnison, the latest (0.6.something) ?
<Lure> Kinnison: which driver?
<Kinnison> ogra: I'm just looking
<Kinnison> lure: ipw2100
<Kinnison> hmm, the wireless card associated with my network, but iwlist scan shows nothing
<infinity> Kinnison: You're lucky, it just segfaults for me right now. :)
<ogra> hmm ... 
<Lure> infinity: what segfauls - n-m or iwlist scan?
<ogra> 7me ponders if he should just release the current live image with old nm
<infinity> Lure: NM.
<ogra> at least users will have network then :)
<Kinnison> ogra: I think this is an ipw2100 issue
<Lure> Kinnison: if iwlist does not report properly it is probably driver issue
<Kinnison> okay that's very odd
<Kinnison> I reloaded the driver, and for about 10 seconds, iwlist scan showed my network
<Kinnison> then it went away again
<Lure> Kinnison: n-m does constant scans, maybe that confuses the driver (similar problem with madwifi)
<Lure> which version of ipw2100 do you have (I know ipw2200 in ubuntu is latest, but not sure for 2100)
<Kinnison> dmesg says version 1.1.4
<Lure> that is a bit old (2.5 months ;-), there is packet monitoring patch in 1.2.1 that may help and one WEXT patch (that n-m depends on)
<Lure> http://ipw2100.sourceforge.net/
<Kinnison> it was working before I upgraded
* Kinnison tries killing NM to see if it can scan then
<siretart> Kinnison: I don't know if this is the same problem, but I think I saw this yesterday on my girlfriends ipw2200
<Lure> Kinnison: another ipw2100 report with latest n-m: http://www.ubuntuforums.org/showthread.php?t=151872
<siretart> Kinnison: the solution was to disable and then reenable wired networking. then wireless was available again
<siretart> btw, is there any easy way to restart nm which does not involve /etc/init.d/dbus restart?
<Lure> siretart: not really - you can kill and start manually
<Kinnison> Lure: seems unrelated
<infinity> Run the scripts from /etc/dbus/event.d
<infinity> Or "dpkg-reconfigure network-manager", which will do it for you.
<Kinnison> infinity: *g*
<Lure> Kinnison: any strange message in dmesg?
<siretart> infinity: :) - thanks
<Kinnison> Lure: not really
<Kinnison> Lure: and since killing NM I get intermittent scan results
<Kinnison> but what's odd is that it thinks only 54Mbps is available on the router
<siretart> Kinnison: do you use wpa? you might find it interesting to have an open 'wpa_cli' with 'level 0' (this is a wpa_cli command) debugging open..
<Lure> Kinnison: strange is that there were many success reports with ipw2100 (with test packages), only one failure
<siretart> Lure: did you identify why it failed?
<Lure> Lure: I do not recall, but am just looking through archives...
<Mithrandir> Kamion: hmm, why isn't d-i 26 in the archive yet?
<Kinnison> siretart: the only security measure is MAC locking
<Mithrandir> Kamion: as in, the binaries seem to not be there yet.
<Lure> siretart: actually it was nm-applet issue causing WEP key to be lost (http://www.ubuntuforums.org/showthread.php?p=848460&highlight=ipw2100#post848460)
<siretart> Lure: oh. this would/could confirm debian bug #304087 then
<Ubugtu> Debian bug 304087 in wpasupplicant "Subject: wpasupplicant not working with ipw2100 driver" [Important,Open]  http://bugs.debian.org/304087
<siretart> Lure: I'm still waiting for ppl to confirm that this bug is valid or not
<dholbach> Kinnison: regarding bug 33820.... it'd make sense to reject it, no?
<Ubugtu> Malone bug 33820 in gnome-session "Pressing power button displays dialog, it does not switch off computer" [Normal,Confirmed]  http://launchpad.net/bugs/33820
<Treenaks> dholbach: I think it should be considered a duplicate of the 'whine-about-the-logout-dialog' bug
<Hadaka> hi! is there a list of things to consider when making a package for ubuntu instead of debian?
<Kinnison> dholbach: I was going to ask mjg59 to decide if we disable the functionality in g-p-m or reject the bug
<dholbach> Treenaks: you mean the "too many buttons"?
<Treenaks> dholbach: (the one complaining that the new Ubuntu logout dialog sucks compared to the original Gnome 2.14 ones with timeouts)
<siretart> Hadaka: we follow the debian packaging policy
<Kamion> Mithrandir: they're there now; I think you just looked while the publisher was still running / mirrors were still pulsing
<Hadaka> siretart: okay, thanks
<dholbach> Kinnison: ok
<Kinnison> seb128: I bodged my network so I could upload the metacity fix again, I'll investigate in a bit
<infinity> Kamion: Oddly enough, the manual never made it...
<infinity> Kamion: (which was what I was checking to see if the upload had)
<infinity> Kamion: Oh, we don't build the manual anymore, I guess.
<infinity> Silly me.
<Kinnison> Lure: I'll upgrade and try again
<Kamion> infinity: right, installation-guide now
<Kamion> there's a mostly empty debian-installer.deb
<infinity> Yeah, I see that now (missed it earlier)
<infinity> Stupid human parsing.
<seb128> Kinnison: cool
<pitti> Kamion: btw, when you NEW aspell-cs, can you please put it into main directly? I added an inclusion report for it (not urgent, though)
<Kinnison> seb128: can you remind me how to empty my session?
<Kamion> pitti: ok, will do
<seb128> Kinnison: empty? reset to default you mean? rm ~/.gnome2/session
<Mithrandir> Kamion: ok.  Anything else we want to get in before I roll the ISOs and we can start testing?
<Kinnison> seb128: thanks
<infinity> Kamion: I don't suppose anyone's found a fix for the "I have no menu selection in gfxboot" anymore bug that cropped up between Flight-4 and Flight-5?
<infinity> s/" anymore/ anymore"/
<_ion> Hi
* StevenK spams mdz and Kamion again.
<infinity> Ah-ha.  The NM SEGV only occurs when you have uncommented interfaces in /etc/n/i
<infinity> Mithrandir: What does the livecd's /etc/n/i look like these days?
<Kinnison> Lure: after an upgrade, nm-applet now shows my wireless but refuses to associate with it
<Kamion> infinity: er, was that bug on machines that worked fine with Flight 4?
<Mithrandir> infinity: auto lo\niface lo inet loopback\n\nauto eth0\niface eth0 inet dhcp
<Kamion> 'cos I'd assumed it was another instance of "we need to switch to 640x400"
<infinity> Kamion: So it claimed...
<Mithrandir> infinity: (repeat for each interface)
<Kamion> infinity: bug#?
<infinity> Mithrandir: Crap.  Let me test that here.
<infinity> Kamion: Looking.
<Kinnison> Lure: It whinged about failing to execute wpa_supplicant
<Kinnison> Lure: despite me not using wpa
<Mithrandir> infinity: nm-applet and NetworkManager{,Dispatcher} running happily on my live box.
<infinity> Kamion: https://launchpad.net/distros/ubuntu/+source/gfxboot-theme-ubuntu/+bug/34592
<Ubugtu> Malone bug 34592 in gfxboot-theme-ubuntu "dapper flight 5: install menu never comes" [Critical,Confirmed]  
<infinity> Kamion: "I've never seen this problem with any earlier release i installed before, certainly not with any dapper flight release up to and including flight-4."
<Kinnison> Lure: http://users.pepperfish.net/dsilvers/for_lure.txt is an excerpt from daemon.log
<Lure> Kinnison: 0.6 has to have wpasupplicant installed and you seem to have old wpasupplicant
<Lure> please remove it and reinstall (it has moved from /usr/sbin/ to /sbin with official package)
<Kinnison> Lure: I had *no* wpasupplicant installed
<Lure> Kinnison: know issue - n-m recommends it, but it should require/depend on it
<Lure> please install and try again
<Lure> there is already bug in Malone
<Kinnison> Lure: I'll try now
<ogra> Lure, it doent work at all without wpasupplicant ? 
<Kinnison> Lure: you are the win
* Kinnison hugs lure
<Kamion> infinity: could be a display problem, could be an infinite loop somewhere in gfxboot-theme-ubuntu. I've followed up to try to narrow it down.
<Lure> ogra: yes, I think wpasupplicant is also used for scanning
<Mithrandir> infinity: apart from nm claiming I don't have a network connection, that is.
<Lure> in 0.6
<infinity> Mithrandir: Ahh, kay, the bug is much narrower in scope (and probably easier to find as a result)
<ogra> Lure, evil ...
<infinity> Mithrandir: The way the livecd is setup works fine.  Mine segfaults as soon as I add any wireless* options to the iface stanza.
<infinity> Mithrandir: Bullet dodged for now.  I'll chase up this segv tomorrow.
<Mithrandir> infinity: thanks.
<siretart> Lure: are you serious about that nm_0.6 will not work in any case without wpasupplicant?
<Mithrandir> Kamion: you don't need anything more in the live cd?
<Mithrandir> Kamion: or install cd
<Mithrandir> if so, I'll spin ISOs
* ogra twiddles thumbs waiting for -meta to hit the archive
<Kamion> Mithrandir: not urgently, as far as I know
<Mithrandir> Kamion: ok, thanks.
<infinity> Mithrandir: We may want to add wpasupplicant to the live seed, but too late for this run. :)
<infinity> Mithrandir: If this run is broken, we can consider it. :)
<janimo> Mithrandir: sorry. I forgot and made an upload to main (xfwm)
<Mithrandir> infinity: yup, sure.
<infinity> Err, wait.  It's still in minimal?
<janimo> hope I did not cause any trouble
<Kamion> infinity: unless somebody moved it ...
<Mithrandir> what is still in minimal?
<infinity> Not that anything depends on minimal anyway, so monimal isn't on the livecd.
<infinity> Oh, -base depends on minimal, and -base is on the livecd.
<infinity> Nevermind, then. :)
<infinity> wpasupplicant is on the livecd.
<infinity> Serendipity.
<Riddell> Mithrandir: you're building new daily CDs?
<Mithrandir> Riddell: yes.
<Mithrandir> infinity: it is?  Not on my (upgraded) live cd, AFAICT
* ogra kicks LP
<Riddell> Mithrandir: can you do new kubuntu ones too?  or let me know when little is free to do so
<Mithrandir> Riddell: sure, I'll spin you those.
<infinity> Mithrandir: Hrm.  I don't see it in "apt-cache show ubuntu-minimal", but I sure as heck see it in the minimal seed..
<infinity> I wonder if there's some sort of disconnect there...
<Mithrandir> infinity: I don't see it in 104 of ubuntu-meta I uploaded.
<infinity> germinate still angry about it being in universe (but it's been moved for a while now)?
<Mithrandir>      0.4.8-0ubuntu2 0
<Mithrandir>         500 http://archive.ubuntu.com dapper/main Packages
<infinity> Anyhow, you should get on with CD building and testing.  I can figure this out async.
<infinity> If wpasupplicant doesn't end up on the livecd, no big loss.
* ogra kicks LP again
<Kamion> infinity: nobody's uploaded ubuntu-meta since I promoted it to main
<infinity> Ah-ha.
<infinity> minimal/i386: Skipping package wpasupplicant (package not in debootstrap)
<infinity> Kamion: No, "minimal" is just thpethial.
<Kamion> oh, right
<Kamion> infinity: I can't change priorities at the moment, so nothing gets into minimal at all
<infinity> Rockin'.
<infinity> S'ok, I'm still questioning why it was put there anyway.
<ogra> why is it in minimal ? 
<StevenK> Kamion: All Soyuz stuff?
<ogra> its a dependency of a desktop app /me thinks ...
<Kamion> StevenK: yes
<j^> infinity if wpasupplicant is not on the livecd WEP/WPA wireless networks will not work with NM
<StevenK> Geez. 
<infinity> ogra: Well, no, it can be used to configure a WPA network independantly of the desktop.
<ogra> infinity, but we dont use it that way currently ...
<infinity> So, much like wireless-tools, it has a place in minimal.  But I'm still not positive on that.
<StevenK> What about standard?
<StevenK> It
<StevenK> It's not minimal, but it isn't optional either. :-)
<Kamion> I think the reasoning is that ifupdown is minimal
<infinity> And wireless-tools.
<infinity> And other such things.
<Kamion> right
<Kinnison> j^: In fact, if my experience today is anything to go by, non-WEP/WPA won't work either
<Kamion> ogra: we don't, but a user can by editing /etc/network/interfaces
<j^> Kinnison which wireless driver?
<ogra> yep, i understandf
<ogra> -f
<Kamion> Mithrandir: hmm, do we want metacity 1:2.14.1-0ubuntu3?
<Kamion> I think we might
<infinity> j^: Kinnison's right, I just tested.
<infinity> Kinnison: That's clearly a bug in the packaging, not a feature.
<infinity> Mithrandir: Your broken NM on your Live system is due to wpasupplicant being missing. :/
<infinity> Mithrandir: I'll seed it to live and do another meta upload, on the off chance you may feel the urge to regenerate images later for some other reason.
<infinity> Mithrandir: If that other reason never arises, you can list it as errata.
<Kinnison> j^: ipw2100
<j^> current version of network-manager only recomends wpasupplicant but has to depend on it
<infinity> j^: By "has to", you mean "is broken, and should be fixed"
<j^> infinity yes, along those lines
<infinity> j^: There's no reason why it should NNED wpasupplicant for WEP or unsecured networks, it just appears to unconditionally try to spawn it anyway (and fails when it's not there)
<HiddenWolf> moken?
<HiddenWolf> whoops
<Treenaks> can't you use wpasupplicant for wep too?
<infinity> Treenaks: Probably, but you can also use the WEXT WEP extentions, which NM has happily done until 0.6 (and may still be able to do, if someone asks it nicely)
<Mithrandir> Kamion: hmm.
<siretart> infinity: wpasupplicant can also connect to WEP secured and even unsececured networks. this makes it somewhat a generic roaming daemon replacement, given that wpasupplicant supports 'action scripts' which are called whenever it looses or reconnects to some AP
<infinity> siretart: So, you're arguing we should just always have it installed as an NM dependency and deal with the added bloat?
<mjg59> siretart: That doesn't sound like a good reason for network-manager always using it, though
<siretart> infinity: I don't know how NM actually uses wpasupplicant. I just wanted to point out that wpasupplicant CAN be used that way. 
<infinity> siretart: It appears that it IS using it that way right now, but I'm arguing that's wrong. :)
<Kinnison> It has an installed size of a half-meg
<Kinnison> and the .deb is 186k
<_ion> Is anyone working on n-m 0.6.2?
<_ion> I.e. upgrading the Ubuntu package
<j^> _ion http://bootlab.org/~j/NetworkManager
<infinity> Updating the Ubuntu package to 0.6.2 is simple.  Fixing the current bugs/issues we have with the implementation of 0.6.x is more important.
<siretart> on a side note: I currently work on an integration of whereami to wpasupplicant. but it isn't there yet
<_ion> j: Cool.
<_ion> There's also a bug in the current Ubuntu package: the binaries contain a different PIDfile path from the one in the d-bus scripts.
<_ion> The 0.6.1 package i used to work on contained a patch that fixed it.
<infinity> _ion: Ahh, is that why restarting it leaves a NetworkManagerDispatcher running (I had 5 before I noticed)?
<_ion> infinity: Yep.
<infinity> Easy enough fix.
<_ion> The binaries: /var/run/foo.pid, the scripts: /var/run/NetworkManager/foo.pid
<infinity> Mithrandir: Do you care enough about NM to put the world on hold, or are you happy with errata?
<_ion> My patch changed the path in the source, but one might as well modify the d-bus event scripts instead.
<infinity> _ion: Or both.  Neither of those paths looks "right" to me.
<j^> _ion what about adding --pid-file= than starting the daemon?
<infinity> _ion: Should be /var/run/<packagename>/<binaryname>.pid (so, /var/run/network-manager/NetworkManagerDispatcher.pid)
<_ion> That's one possibility. :-)
<ogra> grmbl ...
<ogra> edubuntu-meta built 1h ago and is still not in the archive ...
<Mithrandir> infinity: I'd like to have it in the live images, but I guess we can test the install images.
<Mithrandir> Riddell: kubuntu images spinning
<Kinnison> ogra: it'll be there at the end of this cycle
<infinity> Mithrandir: Alright, well, turnaround time on seed changes or packaging changes being more or less the same, I'll upload NM instead with a hard dependency on wpasupplicant since (for now) it seems to need that.
<infinity> Mithrandir: We can beat Keybuk about later to fix that.
<ogra> Kinnison, i'm sure it will be there at the end of *something* :)
* Kinnison tickles ogra
<Mithrandir> infinity: thanks.
* ogra giggles
<janimo> when are uploads expected to be allowed again?
<ogra> janimo, uploads are fine for everything that doesnt touch any CDs :)
<infinity> _ion: Do you have that path patch handy?
<_ion> infinity: Yep, a moment...
<janimo> ah, ok. then xfce stuff is ok I assume.
* Kinnison lunches, ciau
<ogra> janimo, since i doubt xfce stuff is on any of the CDs yet, you should be fine
<janimo> just wanted to make sure. I don't know what a cd making entails, it may be copying the archive from one place to another :)
<infinity> _ion: Nevermind, found the offending code.
<_ion> Here it is anyway. http://johan.kiviniemi.name/tmp/nm-pidfile-location.patch
<infinity> Danke.
<Kamion> janimo: that's part of it, yes ...
<Kamion> Mithrandir: mind if I upload tzsetup? my change only touches the espresso module (to select a sensible default timezone in all cases), and I don't mind if that change isn't in Flight 6
<ogra> YAY
<ogra> infinity, edubuntu-meta is ready for a new livefs
<Mithrandir> Kamion: sure, please do.
<Mithrandir> ogra: you don't need the new NM?
* _ion wishes ubuntu-artwork contained a "Human-Brown" gtk theme.
<ogra> Mithrandir, thats what i did that edubuntu-meta rebuild for ...
<_ion> I really liked the colors in the Human theme in breezy.
<ogra>    * Refreshed dependencies
<ogra>    * Added network-manager-gnome to live-i386, live-amd64, live-powerpc,
<ogra>      live-ia64, live-sparc, live-hppa
<ogra>    * Removed nm-applet from live-i386, live-amd64, live-powerpc, live-
<ogra>      ia64, live-sparc, live-hppa
<infinity> ogra: Then you need to wait for my upload.  Sorry. :/
<ogra> Mithrandir, ^^
<ogra> ah, k
<Mithrandir> ogra: what about wpasupplicant?
<infinity> Mithrandir: Solved in my upload.
<ogra> i missed that ... (edubuntu meeting aside here)
<Mithrandir> infinity: well, true.
<infinity> Mithrandir: I just added a hard dep on it.
<infinity> ogra: Don't worry about it.
<ogra> Mithrandir, what infinity said
<Mithrandir> Riddell: kubuntu cds are done
<infinity> We can whip the approrpriate people about fixing NM's behaviour after Flight mojo is over.
<Mithrandir> ogra: do you want edubuntu install cds to test too?
<infinity> Kinnison: Would it be terribly bad to disable lp_publish's crontab on drescher and do by-hand cron.daily runs to speed up the process when we need to? :)
<ogra> Mithrandir, since they'll suffer also from the kdeedu breakage, i'll need new ones i guess ...
<_ion> j: Your 0.6.2 package seems to have docbook-to-man and wpasupplicant in build-deps. Are those really necessary?
<Pygi> _ion: I need to talk to you ^_^ And hi
<Mithrandir> ogra: ok, spinning
<Pygi> pitti: around? urgent issue to solve ;)
<_ion> j: The .diff.gz also contains network-manager-0.6.2/src/nm-device-802-11-wireless.c.new  i think that doesn't belong there.
<pitti> hi Pygi 
<_ion> Hi pygi
<ogra> Mithrandir, what about the kbd-chooser change and d-i rebuild Kamion talked about, is that in ?
<Mithrandir> ogra: yes.
<ogra> good :)
<Pygi> pitti: do you have the "powers" to rebuild wpasupplicant in main?
<Pygi> pitti: one patch should be included right now, if possible ;)
<Mithrandir> ogra: I'm halfway through i386 testing already. :-P
<pitti> Pygi: in general yes, but right now we are in flight-6 freeze
<ogra> Mithrandir, wow, fast guy, you deserve a pony :)
<Pygi> pitti: yes, I know that, but this is security issue, you know :-/
<pitti> Pygi: so every main upload needs Mithrandir's or Kamion's approval
<Pygi> Mithrandir: ping ;)
<siretart> Pygi: what patch for wpasupplicant? please file a bug and attach that patch
<Pygi> siretart: A security issue :-/
<Mithrandir> Pygi: dude, no need to ping me when I've said something in the channel in the last minute. :-)
<pitti> Pygi: which one? spewing WEP passwords into log files?
<Mithrandir> Pygi: hmm, where's the patch?
<Pygi> Mithrandir: yes, sorry ;)
<Pygi> pitti: yup
<_ion> mithrandir: Ping ;-)
<Pygi> Mithrandir: wait a sec ;)
<pitti> Pygi: well, that's a pretty old issue
<infinity> Pygi: If it can make it in in under 21 minutes, you win.
<infinity> Pygi: Otherwise, I don't care. :)
<Pygi> pitti: still, should be fixed, no?
<pitti> Pygi: yes, of course it should
<Pygi> infinity: heh ;)
<infinity> Pygi: It can be fixed after Flight-6, if we can't do it in 21 minutes.
<pitti> Pygi: but not such a big deal for flight-6 maybe, if it doesn't arrive on time
<infinity> pitti: Is the patch small and obvious?
<Pygi> I'll give the patch right now
<Pygi> sec pls ;)
<pitti> infinity: no idea, I didn't see it
<ogra> Pygi, but not while we're all busy preparinmg flight CDs and have to handle the archive like raw eggs :)
<infinity> pitti: I'm happy to squeak it in before the next cron.daily.
<Pygi> ogra: agreed, but I want that fixed ;)
<infinity> pitti: Install CDs may not end up with the patch (oh well), but live would get it.
<ogra> Pygi, sure but there is no hurry ... we're not on a race :)
<infinity> Pygi: Do you actually have a small and sane patch?
<Mithrandir> Pygi: if it's just information disclosure into the log files, I don't really care.  Live CDs generally don't last that long.
<Pygi> ogra: yes, we are ;)
<Pygi> infinity: sec pls ;)
<siretart> Pygi: please CC: me
<infinity> Mithrandir: More to the point, test CDs don't last that long. :)
<Pygi> yes, patch is small
<Mithrandir> infinity: that too, but if you end up putting a password into a log on a tmpfs on a live cd, I would be surprised if it was there a day later.
<Kamion> ooh, y'know, I might actually be able to change priorities now
<pitti> Mithrandir: SRAM, you know :-P
<infinity> Kamion: Crazy talk.
<Pygi> siretart, infinity ... private message please ;)
<Kamion> ... or not.
<infinity> Pygi: Is there a CVE to go with this?
<fabbione> infinity, slomo: what is FTBFS?
<infinity> fabbione: Nothing.  I'm retarded.
<fabbione> infinity: ah ok :)
<fabbione> oh David left me another mono fix
<fabbione> this will make the test suite going
<fabbione> and beagle will build
<infinity> Nice.
* fabbione checks before heading to bed again
<slomo> fabbione: please give me the patch instead of uploading a new mono ;) i have 1.1.13.6 and another patch pending currently
<Pygi> infinity:  hm, what do you mean?
* Kamion files bug 37156
<Ubugtu> Malone bug 37156 in launchpad-upload-and-queue "can't change sections or priorities with change-override.py" [Normal,Unconfirmed]  http://launchpad.net/bugs/37156
<Pygi> _ion: you there still?
<fabbione> slomo: mind if we first get this one in?
<fabbione> slomo: it fixes several problems on sparc
<fabbione> and it has been tested
<slomo> fabbione: ok but give me the debdiff so i can merge it easier into my local version, ok?
<fabbione> slomo: sure..
<doko> infinity: so you are awake ...
<infinity> Pygi: A CVE assignment from mitre for the information disclosure.
<infinity> Apparently not.
<Mithrandir> ogra: edubuntu cds done
<_ion> pygi: Somewhat. :-)
<Pygi> apparently :P
<_ion> pygi: I'm resting.
<Pygi> _ion: we need to start work on 0.6.2
<ogra> Mithrandir, thanks, rsyncing
<Pygi> ah, ok, rest ;)
<pitti> Pygi: patch looks good enough to me
<_ion> pygi: j already upgraded the package.
<_ion> pygi: Or is there something else to be done?
<slomo> fabbione: the exceptions and gc patch is btw in 1.1.13.6 already
<Pygi> _ion: ah, you did? in our repo?
<_ion> pygi: /whois j^
<fabbione> slomo: yes, the new patch adds more libgc fixes
<Pygi> ah, yes, I saw that packages _ion ... have you dropped unneeded patches?
<_ion> pygi: http://bootlab.org/~j/NetworkManager
<Pygi> _ion: care to copy that to our repo?
<Pygi> or ping tonio_ to do it?
<KaiL> morning Pygi 
<Pygi> KaiL: hi hi
<_ion> pygi: Now that n-m 0.6 is already accepted to Ubuntu, is our repo needed anymore? If there's something that should be fixed, i think a malone bug report should be enough.
<Pygi> KaiL: I have a question for you ;)
<Pygi> _ion: agreed ;) but we need 0.6.2
<Kinnison> infinity: I don't imagine so
<fabbione> slomo: http://people.ubuntu.com/~fabbione/mono_diff
<_ion> pygi: I'm very exhausted at the moment. If i'm feeling better later today, i'll update the package in the repository.
<Kinnison> infinity: it should be fine. the best you'll achieve is around double-rate, depending on how the publisher is feeling
<fabbione> slomo: and ubuntu9 uploaded. Please let me know when you are ready with the new version, that we will give it a spin
<Pygi> _ion: thank you ^_^ and have a good rest ^_^
<fabbione> i am off again
<fabbione> later
<infinity> Pygi: If my test-build finishes before the hour, you get your patch in.
<ogra> fabbione, get well ...
* Pygi votes for finishing before the hour ;)
<fabbione> ogra: thanks
<slomo> fabbione: i'm ready ;) i'm only waiting for a uvf exception approval now
<infinity> fabbione: Erk.  Someone should have warned you that new uploads will gain the wrath of Mithrandir. :)
<infinity> Oh wow, that builds fast.
<Pygi> thank you infinity ^_^ now all you need is to make sure it finishes ;)
<fabbione> slomo: ok.
<fabbione> infinity: eh..
<ogra> infinity, is mono on the CD ?
<fabbione> infinity: a bit too late..
<ogra> i didnt think it is 
<fabbione> infinity: and afair mono is not on CD
<infinity> fabbione: Yeah, I have no idea if any of it is in ship.  Oh well, too late anyway. :)
<fabbione> Mithrandir: sorry :/
<fabbione> ok
<fabbione> i am off. really
<seb128> ogra: no, it's not
<fabbione> infinity: care to give back beagle once mono is built?
<infinity> fabbione: Bug me tomorrow.  I'm doing the bed thing soon.
<ogra> seb128, not before dapper+1 at least :)
<fabbione> infinity: night
<ogra> if we find the f-spot :)
<Pygi> will be back soon
<sladen> mjg59 / jdub: D'oh fixed in acpi-support, ta
<zul> heylo
<ogra> moin zul
<zul> moring ogra 
<KaiL> Pygi, j^: I'm currently working on a new WLAN status page, which only lists WLAN chipsets,  not the specific devices - that should make the list a lot shorter and avoid false entries, as the device names often doesn't change, but the hardware itself does
<KaiL> hmm, bad timing ;)
<infinity> mvo: /topic, dude
<ogra> infinity, tell that to sladen :P
<janimo> was there a final decision made on gtk1.2 and rdepends demotion to uni?
<janimo> xmms in particular
<janimo> also what was decided on libmad?
<infinity> Petty sure xmms is heading to universe.
<janimo> this is an ex-mms
<janimo> libmad too?
* infinity heads to bed.
<tseng> libmad is used by kde iirc
<sladen> ogra: what did I break?
<sladen> ogra: /me reads, groovy
<ogra> sladen, /topic :)
<janimo> tseng, does libmad ship on kubuntu CD as well or only in main?
<janimo> Riddell: ^
<tseng> beats me dude, it could not use it at all these days
<Riddell> tseng: it's a build-dep only
<Riddell> janimo: it doesn't ship on the CD
<janimo> Riddell: but is in main, and stays there for dapper?
<Riddell> janimo: we could drop MP3 support in arts, but what's the advantage?
<janimo> Riddell: I am not thinking in terms of advantages/disadvatages here. just curius :)
<janimo> since graveman which is potential xubuntu app deps on libmad
<janimo> and if libmad goes to universe no need to push it
<janimo> graveman I mean
<janimo> Riddell: speaking of arts is that going to be kept for kde 4 too?
* ogra hopes not ...
<Riddell> janimo: crivvens no
<Treenaks> Riddell: What will be used?
<ogra> Treenaks, gstreamer (hopefully)
<Treenaks> that'd rock
<ogra> yep
<Riddell> Treenaks: phonon
<Riddell> an API with multiple backends
<Riddell> of which gstreamer would be my preference to use
<Treenaks> Riddell: one of which is gstreamer, I guess?
<Treenaks> ah
<Pygi> I am back
<Pygi> infinity: good or bad news?
<KaiL> rehi Pygi 
<KaiL> Pygi: I'm currently working on a new WLAN status page, which only lists WLAN chipsets,  not the specific devices - that should make the list a lot shorter and avoid false entries, as the device names often doesn't change, but the hardware itself does
<Pygi> KaiL: rehi? ;) great, thanks ^_^
<KaiL> https://wiki.ubuntu.com/WirelessChipsets
<KaiL> the old device based list is rather - uhm - useless
<Pygi> k, thanks for help ^_^
<Riddell> Kamion: can you rebuild the kubuntu live CD filesystem?  so it's in live with the install CDs for flight 6
<ogra> Riddell, we're still waitinfg for the wpa stuff
<KaiL> Pygi, it's only a bit complicate, to get the people even to give me those 2 values... *gar*
<Pygi> ogra: it' coming in? ^_^
<Pygi> the patch I mean ;)
* ogra had planned different stuff today than rebilding CDs over and over :(
<Kamion> Riddell: I imagine Mithrandir/infinity will do that when ready
<Riddell> ok, didn't realise we were still waiting
<zul> Kamion: i have a gfxboot patch for grub locally which I have to test out fyi..
<Kamion> zul: I really actively don't want to apply that before dapper
<zul> Kamion: im working on dapper+1 stuff
<Kamion> I know SuSE have it, but I want to keep grub stable; let's look at it after dapper
<Kamion> zul: ok, talk to me after dapper :-)
<Kamion> but thanks for the note
<zul> Kamion: okie dokie..
<Pygi> Kamion: any chance I can get UVF exception to update n-m 0.6.1 to n-m 0.6.2?
<Kamion> Pygi: please send UVF exceptions by mail, not IRC. see http://wiki.ubuntu.com/DeveloperResources
<Pygi> Kamion: yes, I am aware of that, just wanted to ask ^_^
<Pygi> s/ask/is there a chance for it
<ogra> Pygi, just send the mail 
<ogra> the answer will tell you ;)
* Pygi understands...
<Kamion> if I answer these questions by IRC, I have to work at your schedule rather than mine
<Kamion> IRC is not good for batch processing
<Kamion> I'm doing other things right now
<Pygi> k, sorry
<sladen> KaiL: orinoco/prism work  
<KaiL> sladen, I'd like to have the exact names from lspci :)
<KaiL> esp. as there are afaik some prism2, which doesn't work
<j^> orinoco_pci should be blacklisted so that  hostap_pci is used for Intersilli Prism 2/2.5/3 chips
<Kamion> no, some cards need hostap
<Kamion> see the PCMCIA list for discussion of this
<Kamion> lists.infradead.org
<j^> bugs 36718
<Ubugtu> Malone bug 36718 in module-init-tools "blacklist orinoco_pci" [Normal,Unconfirmed]  http://launchpad.net/bugs/36718
<j^> Kamion i am talking about orinoco_pci not orinoco_cs
<j^> orinoco_pci and hostap_pci support the same chips
<ogra> j^, hey, orinoco is working fine here, dont break it
<j^> ogra does it also support WPA?
<Kamion> oh, hmm, I'm less sure about that but it seems to me that the same considerations apply; orinoco and hostap *claim* to support the same chips but ...
<ogra> j^, i dont use WPA and personally never met any person using it 
<KaiL> hostap is in dapper, but not in breezy?
<ogra> (to be honest i dont understand all the fuss about it)
<j^> ogra i personally dont use any wireless encryption, but as sad as it is i had to use WPA
<trappist> ogra: it gets around a lot of the insecurities of wep
<Kamion> http://lists.infradead.org/pipermail/linux-pcmcia/2005-December/003001.html says that the exact same problem occurs with orinoco_pci and hostap_pci
<ogra> trappist, i live 200m away from the next neighbor, no need for any encryption here ... 
<KaiL> ogra, because on Windows it's even more broken than on Ubuntu? ;)
<trappist> ogra: not trying to shove it down your throat, just telling you what the fuss is about :)
<ogra> trappist, j^, dont get me wrong, i appreciate that you guys do the work, but i personally couldnt care less about WPA
<j^> ogra hostap_pci is also faster in finding networks
<Kamion> http://lists.infradead.org/pipermail/linux-pcmcia/2005-December/002997.html says that there *are* cards that orinoco supports but hostap does not
<ogra> j^, just dont break it ;) thats all i'm begging for ;)
<j^> Kamion _cs not _pci
<ogra> i dont care which driver drives my card as long as everything works
<Kamion> j^: who cares about the bus?
<Kamion> it's the same core
<mjg59> Kamion: They're different drivers
<Kamion> mjg59: whence the comment in http://lists.infradead.org/pipermail/linux-pcmcia/2005-December/003001.html then?
<mjg59> I don't think there were orinoco or symbol PCI parts
<j^> Kamion orinoco_pci == hostap_pci, other cards are in orinoco_plx
<mjg59> Oh, maybe there were orinoco PCI ones
<j^> mjg59 but are you sure its not one of the later orinoco ones that use prism2 chips?
<Kamion> well, if orinoco_pci is really useless, surely we should just stop building it (or put it somewhere else by default) rather than making life difficult for folks who know what they're doing (e.g. are building their own kernels) by blacklisting it
<j^> Kamion editing a txt file to use the module vs. building your own kernel, not sure what makes life difficult
<Kamion> http://lists.shmoo.com/pipermail/hostap/2005-November/011901.html
<Kamion> the people who build their own kernels will have been doing so for years and will know how to do it; they may not know how to deal with (or where to find) relatively new configuration files
<j^> Kamion could say the same for e100 vs eepro100
<j^> or others found in /etc/modprobe.d/blacklist
<Kamion> e100 and eepro100 do not have quite identical PCI device ID tables
<j^> i would also count myself in the group of people that build their own kernels for years, i know about blacklist files and i stopped building my own kernels though
<Kamion> I see several devices supported by one but not the other (and neither is a superset)
<_ion> I wouldn't build my own kernel if i were able to use /dev/fb{0,1} with Matrox G400 using the default kernel image.
<Pygi> _ion: Dan and Robert are really helpfull ;)
<j^> Kamion e100 vs eepro100 or hostap_pci vs orinoco_pci now?
<bddebian> Kamion: ping?
<Kamion> j^: e100/eepro100
<Kamion> bddebian: yes?
<bddebian> Kamion: Do you mind if I bug you privately for just a sec?
* j^ downloads the kernel code end does some extractions
<pitti> mjg59: I just noticed a flaw in your at_console dbus patch; got a minute?
<mjg59> pitti: Sure
<Kamion> bddebian: er, is it particularly private?
<bddebian> I would prefer it was, but if you are busy, that is fine
<Kamion> bddebian: ok
<pitti> mjg59: so it seems that _dbus_is_console_user() is only called when creating a policy, not when receiving a dbus function call
<pitti> mjg59: this is fine for Fedora's at_console, but since ours checks the foreground console, it doesn't react to fg console changes
<mjg59> pitti: Hrmph.
<pitti> mjg59: i. e. if I start g-v-m or g-p-m on one conole, then switch user, start a new one, *both* have at_console privs
<mjg59> Yes
<mjg59> Ok, that's wrong
<mjg59> Can you see a simple fix? :)
<pitti> mjg59: I just started to look at the dbus sources, but it seems to require some rearrangements, since the policy parser already resolves quite much
<mjg59> Ngh.
<pitti> mjg59: hm, it might be possible to create both policies in bus_policy_create_client_policy() and move the decision to the method call handler
<Kamion> bddebian: (i.e. go ahead)
<j^> Kamion http://bootlab.org/~j/NetworkManager/orinoco_vs_hostap.html
<pitti> mjg59: btw, I'm (ab)using at_console in g-v-m to finally solve the race between multiple user's g-v-m instances, that's why I noticed
<mjg59> pitti: Ah, cool
<Pygi> infinity: thanks ^_^
<lamont> COULD WE PLEASE STOP RESETTING MY HOME PAGE EVERYTIME I UPGRADE FIREFOX???
<ogra> Kamion, i have a preseedable debconfvalue to select a theme in edubuntu-artwork, if i set edubuntu-artwork/theme=plain at the CD prompt, shouldnt that be picked up ?
* pitti holds his ears
<pitti> hi lamont
<Treenaks> lamont: that doesn't happen for me..
<zul> we just do it to bug you lamont ;)
<pitti> lamont: WFM
<lamont> ok... it's just the breezy-> dapper transition that trashes it.
<ogra> here as well
<lamont> I mean, I love seing the new dapper info page, but could I please have my home page?
<pitti> lamont: complain to Diziet then :)
<lamont> yeah, I did.  and he claimed he fixed it...  Guess it's time to reopen the bug
<bddebian> Kamion: Are you seeing that -> ?
<lamont> Note that because the bug is in the default configuration, ie in the
<lamont> initial profile, an existing user will unfortunately not see the fix
<lamont> unless they generate a fresh profile. This is unfortunate but we
<lamont> don't have a good way of safely and coherently updating existing user
<lamont> profiles.
<lamont> that is utter crap
<lamont> Diziet: you around?
<lamont> 33895
<pitti> mjg59: *sigh* that requires a fair amount of changes in dbus
<pitti> Robot101: ping
<Robot101> pitti: pong
<pitti> Hi
<pitti> Robot101: are you aware of Ubuntu's at_console policy patch?
<Kamion> ogra: yeah, should be
<pitti> Robot101: for us 'at_console' means 'is at the foreground console', not 'is at any console'
<Kamion> lamont: Diziet's on holiday this week I think
<Robot101> yeah, painfully aware, because I have a CVS dbus and dapper, so half of the gnome-{screensaver,{power,volume}-manager} stuff is broken for me
<pitti> Robot101: we need that because it makes much more sense with g-p-m and such
<Robot101> right
<pitti> Robot101: I just discovered that our implementation is broken; at_console is only evaluated at policy creation time, not at the time when a function call actually takes place
<lamont> Kamion: ah, ok
<pitti> Robot101: so two g-p-m's or g-v-m's still race against each other
<lamont> Kamion: I just reopened 33895 for him to enjoy when he's back then... :)
<ogra> Kamion, thanks
<pitti> Robot101: do you think a dbus policy feature like 'is at the foregound console' will ever make it upstream?
<pitti> Robot101: if so, do you have some time to discuss it? if not, we should find a different solution for Ubuntu
<lamont> http://bld-4.mmjgroup.com/~wb/buildLogs/stats/dapper.stats2.png
<lamont> note the kde spike yesterday
<Robot101> pitti: I'd be happy to argue in favour of commiting at least a compile-time switchable implementation of at_console
<pitti> Robot101: I just noticed that changing dbus this way requires a fair amount of code changes
* Robot101 nods
<pitti> so I'll need help with that
<Robot101> yeah it's not a trivial patch by any means, and a helper program too
<Robot101> I didn't look closely at it yet
<pitti> Robot101: the helper program is the easiest part, we already have it :)
<Robot101> right, but where's the best place to implement the variable behaviour
<pitti> Robot101: if we want it then the check needs to move to the signal/method call handler anyway
<pitti> Robot101: and which behaviour takes place is solely determined by _dbus_user_at_console() then
<pitti> Robot101: i. e. our's would use the dbus-foreground-console, Fedora might use pam_console, etc.
<lamont> neato.
<lamont> are my printer settings all supposed to go *poof* on upgrading to dapper?
<lamont> or was I just lucky...
* lamont notes that running out of disk space in the middle of a dist-upgrade is a bad thing
<pitti> Robot101, mjg59: the altearnative would be to change dbus-foreground-console to dbus-is-foreground-console and call it in g-{p,v}-m themselves; this doesn't enforce policy, but is much easier to implement
<Kinnison> dholbach: ping?
<Kinnison> pitti: That sounds like it'd give the impression of correctness without the security backing it up. If we can't get it right at the core then I guess so, but I don't like it :-)
<dholbach> Kinnison: pong
<pitti> Kinnison: full ack
<Kinnison> dholbach: I've been reviewing the gparted stuff you sent
<Kinnison> dholbach: you expressed concern about needing a 'reload' or something -- can you explain what you meant?
<dholbach> Kinnison: how bad is it, doctor?
<pitti> Robot101: do you have any idea how Fedora et al solve that problem?
<dholbach> Kinnison: does it show up volumes and partitions for you, when you start it?
* Kinnison tries
<Kinnison> oh crud, I need to recompile
<Kinnison> please wait
* Kinnison taps fingers
<dholbach> ok
<Kinnison> once it has rebuilt I'll take a closer look
<Kinnison> umm, hang on
<Kinnison> it refuses to build
<Kinnison> privileged.patch is failing
* Kinnison took the latest source from your website, was that wrong?
<dholbach> um.... it built for me
<dholbach> strange
<dholbach> even in pbuilder
<Kinnison> unpack the source you published in a fresh dir and try
<ogra> dholbach, pbuilder update ?
<Kinnison> It might be a simple-patchsys bug where it left a patch applied or something
<sladen> lamont: how do you manage to get hppa/sparc *above* i386 in those graphs...?
<lamont> sladen: it's graph2.
<lamont> graph1 (dapper.stats.png) is "installed/total"
<lamont> graph2 (dapper.stats2.png) is "installed/(installed+out-of-date)"
<lamont> so you get penalized only for out-of-date packages (that built in the past) on graph2
<lamont> and hppa/sparc rock. :-)
<lamont> although hppa really doesn't like kde, based on the slow recovery.
<lamont> new data point in about 45 min or so
<lamont> sladen: graph 2 ignores all the crap that an architecture was never able to build before, either.
<sladen> lamont: cupsd will crash in an infinite loop (100% CPU) if you run out of dist-upgrade and run out of diskspace during it...
* ogra never runs out of dist-upgrade ... there is always one left :)#
<lamont> hrm... anyway, I re-added my printer
* lamont hands sladen a baseball bat.
* ogra grins
<dholbach> Kinnison: i uploaded a new .diff.gz and .dsc
<Kinnison> dholbach: i'll grab them, one sec
<dholbach> Kinnison: thanks a lot... dunno what happened between and now and then...
<Kinnison> dholbach: looks better, configuring now
<sladen> lamont: apparently that's NOT A BUG.  Since daemons shouldn't be responsible for checking every the return result of every library/syscall because out-of-disk is known is cause badness anyway
<lamont> sladen: sigh
<lamont> lazy damn programmers.
<Kinnison> dholbach: right yes, I see, it just doesn't show
<Kinnison> dholbach: how strange
<dholbach> i could try with 0.2.3
<Kinnison> let me look first
<Kinnison> dholbach: right, running it without embedding still needs a refresh to begin
<Kinnison> dholbach: most odd
<dholbach> yeah :/
<mvo> Mithrandir: please hit me hard (or blame gnome-xchat), I haven't read the bits that we are frozen for flight-6 and uploaded a new gnome-app-install and synaptic
<dholbach> Kinnison: you think it's a good idea to pester upstream with the patch? :)
<Pygi> dholbach: yes, bother upstream ;)
<Pygi> I know I wasn't asked, but still :P
<Kinnison> dholbach: I'm wondering about the on_signal_show
<Mithrandir> mvo: ok. :-/  Disruptive changes?
* Pygi is discussing currently with n-m upstream :P
<Kinnison> dholbach: which in theory should be called when the window is shown -- that would cause the refresh
<Kinnison> dholbach: IMO we need to attach that signal to somewhere
<mvo> Mithrandir: no, not really. minor updates, but I'm not sure about size impact of g-a-i because I updated the application-data
<dholbach> Kinnison: right
<Kinnison> dholbach: check if 0.2.3 has the same issue, if so then we need to work out why that signal isn't firing
<Mithrandir> mvo: 'k, let's hope it works out, then.
<mvo> is there a way to prevent g-a-i from building (or cancel it or something)?
* ogra throws a shocked look at mvo 
<dholbach> Kinnison: i'll do that tonight maybe... i'm just writing the hug day announce and then need to run to an appointment - hope you don't mind
<ogra> did you say size ?
<mvo> ogra: *cough* yes *cough*
<ogra> tststs
<ogra> (i'll survive i guess, dont worry)
<Kinnison> dholbach: of course I don't mind. Just shout when you have the next pass for me to look at (if you need my help subsequently)
<Kinnison> dholbach: the rest of the patch seems okay
<dholbach> Kinnison: thanks a lot
<mvo> ogra: from the look of it it *seems* like the size is identical *puuhhhh*
<dholbach> I personally feel this is very much worthwhile.
<Kinnison> dholbach: there's a little wart
<Kinnison> dholbach: you make the title of the window conditional on installer_mode
<Kinnison> dholbach: *inside* a test for installer_mode
<ogra> mvo, i have made as much room as i could, the edubuntu CD could bear another 1-200k 
<Kinnison> dholbach: which seems odd
<Mithrandir> mvo: we could dep-wait it on something bogus, but I'll rather just spin the live cds now and hope for the best.
<ogra> mvo, so it should be fine then
<dholbach> Kinnison: oh... I'll make a note to double check that - it sounds indeed odd
<Kinnison> dholbach: it's in Win_GParted's constructor
<dholbach> merci
<Kinnison> kein ahnung
<dholbach> haha
* dholbach hugs Kinnison
* Kinnison grins
<ogra> eeek
<ogra> amd64 edubuntu install failed
* mvo grabs a brown paperbag for not reading topic and stops uploading for today
<Pygi> ogra: no good :'(
<Pygi> ogra: failed on what?
* Kinnison decides to go and hide himself away in a cupboard to try and get this sodding gnome-power-manager upload done
<Mithrandir> ogra: because of what?
* Kinnison won't be on IRC as a result (too distracting)
<Kinnison> phone me (cell or landline) if I am needed urgently
<Kinnison> otherwise I'll be around in a few hours assuming all goes well
<ogra> pitti, Kamion "debconf: Obsolete command TITLE configuring foomatic-filters called"
<Mithrandir> Kinnison: uh, wait.
<Kinnison> Mithrandir: yes?
<Mithrandir> Kinnison: is this critical for flight-6?
<ogra> debconf or foomatic ...
<Mithrandir> Kinnison: if not, please hold it off until flight 6 is out.
<Kinnison> Mithrandir: I don't believe it's urgent for it
<Kinnison> Mithrandir: I won't upload
<Mithrandir> Kinnison: ok, then you can go and play in the cupboard. :-)
<Kinnison> Mithrandir: s/upload/package/ in my statement if it makes you feel better
<Mithrandir> Kinnison: it does.
<Kinnison> Mithrandir: I won't even take my gpg key into the cupboard
<Mithrandir> :-)
<Kinnison> sorry, didn't mean to alarm you
* Kinnison -> less distracting places
<ogra> argh 
<Mithrandir> Kamion: I'll build livefs-es now, fyi.
<ogra> wrong alert, seems my media is broken ...
<ogra> (i missed the errors above)
<pitti> ogra: *phew*
<Kamion> ogra: that debconf error is harmless
<Kamion> er, rather, it's not an error, just a warning
<Kamion> interesting that ogra could boot amd64 - Mithrandir couldn't earlier
<ogra> Kamion, yes, i had the broken pipe error again above ...
<Kamion> what broken pipe error?
<ogra> and some drive ready seek complete errors above ...
<ogra> from debconf ...
<Kamion> you're being very vague :)
<Mithrandir> Kamion: might be my machine throwing a fit.  I haven't tried on my home amd64.
<ogra> i had that last flight as well, where you said immediately that its the media
<ogra> its the same error
<Kamion> Mithrandir: doesn't boot for me either, but I haven't checked the media
<Kamion> all media sucks. kthxbye
<Kamion> ogra: DriveReady SeekComplete errors usually indicate media problems, certainly
<ogra> nomeata, i meantt the debconf error that i had last flight ..
<Kamion> "Broken pipe" means that a process tried to write to a pipe only to find that the other end had closed it
<Kamion> in order to work out exactly what that means, context is needed
<Mithrandir> Kamion: it worked when I reburned with i386.  And I burned the amd64 version three times, so I somehow doubt it's the media.
<ogra> Kamion, i already rebooted ...
<ogra> Kamion, just take my word for it, its the same error you identified media breakage in flight 5 with
<Kamion> ok
<ogra> amd64 still boots fine here btw
<Kamion> I suppose the ElTorito boot segment could be b0rked on amd64, but that's very weird given that Edubuntu boots
<ogra> -rw-rw-r-- 1 ogra ogra 723605504 2006-03-29 14:40 dapper-install-amd64.iso
<ogra> should be the current one 
<Mithrandir> ogra: can you try regular ubuntu and see if it works for you?
<ogra> Mithrandir, depends how long it takes to rsync that over an edubuntu iso ...
<ogra> i'll pull it now
<Mithrandir> thx
<Kamion> oh, for pity's sake, my BIOS boot order was wrong
<Kamion> hmm, but still bad media I think
<ogra> back in pkgsel again
<janimo> pitti, if evince-gtk is to use the evince translations I guess can just disable /po building and there's no need for langpack.mk
<pitti> janimo: I'm still reluctant to approving evince-gtk; it would mean to do all fixes twice
<pitti> janimo: this should really be a multibuild source package with two different configure options
<janimo> pitti, I agree but I don't see a solution right now
<pitti> janimo: how big is the code difference?
<janimo> the patch is about 1000 lines
<janimo> so the changes are a few hunderd lines
<pitti> janimo: it's not possible to merge that with #if .. #else .. #endif ?
<janimo> since upstream does not even comment on the patch, does not even refuse it straight out I don't see what else I can do
<janimo> pitti, wlel that is the patch basically , ifdef WITH_GNOME stuff
<seb128> pitti: it would require me updating the xubuntu patch every time GNOME roll a new tarball if we want evince normal updated with GNOME
<seb128> because if the patch conflicts when we get the new version it blocks the update
<pitti> seb128: no, that patch should go upstream, of course
<janimo> pitti, http://bugzilla.gnome.org/attachment.cgi?id=59636&action=view
<janimo> this is how it looks like roughly
<ogra> has anybody tested ubuntu i386 already ?
<Amaranth_> ooh, flight 6
<crimsun> If someone's doing "known issues" for Flight 6, please add a note regarding HDA Intel for certain chipsets will be muted (those using STAC9xxx codecs) due to a brown paper bag paste error. It's already fixed in BenC's git tree.
<pitti> janimo: ok, that doesn't look too scary; and upstream doesn't want it?
<janimo> pitti, upstream does not comment on it
<janimo> except initial comment on my original patch in september
<janimo> which they said is unnecessary as there are other areas to improve in evince for performance
<janimo> pitti, trust me I don;t like current package split
<janimo> I spent way more time on fighting autotools in the evince package than on the code itself
<Kamion> Mithrandir: OK, likewise, I have i386 booting but not amd64
* Kamion has a bad feeling ...
<pitti> janimo: I believe that :/
<janimo> just to keep it up to date with upsteram and debian package
<pitti> janimo: so, is evince-gtk the normal evince package plus debian/patches/yourpatch, or is it a forked orig.tar.gz?
<ogra> Kamion, Mithrandir, edubuntu amd64 is gold ... testing ubuntu amd64 now
<janimo> pitti, regenerated orig.tgz yes
<janimo> mostly for autotools
<janimo> the debian pacthes are only laucnhpad + configure in the gnome package case too
<janimo> so it's orig tar.gz untarred, edit makefiles,autoreconf, recompress
<janimo> more or less
<pitti> janimo: hm, using evince's orig.tar.gz and calling autoreconf at build time is not an option?
<janimo> pitti, that could be I guess, but I did not investigate that much
<janimo> I know there are some AUTO_UPDATE cdbs vars is that it?
<janimo> but saw some arguments pro and against it in some d-d archives and thought I'd do what most packages do
<janimo> that is from what I see not dep on autotools for build
<pitti> janimo: well, updating autotools files during build is evil, yes, but a forked orig.tar.gz is even more evil
<janimo> true
<pitti> janimo: AUTO_UPDATE with tarball.mk doesn't hurt that mach
<pitti> s/mach/much/
<janimo> I'll look into that then
<pitti> oh, evince isn't tarball.mk
<janimo> ah, yesit is not
<pitti> hm, but still better to have the changes in the diff.gz, I guess
<janimo> if you mean tar.gz in tar,gz
<janimo> you mean configure changes?
<pitti> yes
<Mithrandir> Kamion: it might be cosmic radiation or something and fix itself if I rebuild the image?
<janimo> ah, I thought nothing betas that in eveilness :)
<ogra> Mithrandir, Kamion, i'm in base install now
<Kamion> Mithrandir: I'm just making a change to debian-cd to remove elilo configuration from /isolinux/ on amd64
<janimo> but seems forked tar.gz does
<Kamion> ogra: Ubuntu/amd64?
<ogra> yep
<robtaylor> Kamion: know much about usbutils?
<janimo> s/betas/beats/
<pitti> janimo: code changes in debian/patches, and autoreconf changes in the diff.gz is not too evil (or autoconf changes in debian/patches/99_autotools.patch)
<Mithrandir> ogra: hmkay.
<Kamion> this is insane, how come it breaks for both Mithrandir and me
<Kamion> robtaylor: no
<ogra> no idea
<ogra> but it works fine here
<Kamion> I'm tempted to rebuild just amd64 anyway with this debian-cd change, for the hell of it
<janimo> seb128, other than the packaging do you have anything against the patch itself?
<Kamion> Mithrandir: mind if I kick that off now?
<pitti> reminds me of the refusal of my computer to boot the Kubuntu amd64 back then
<Mithrandir> Kamion: please do.
<ogra> just leave out edubuntu, its already tested and fine :)
<Kamion> Mithrandir: have you tried amd64 live?
<Mithrandir> Kamion: no, I haven't had time to generate images, just the livefs-es.
<seb128> janimo: I've not looked at the code but in principle no
<seb128> janimo: but that's upstream call
<janimo> pitti,seb128 I'll write to upstream and ask them to at leats comment on the patch
<Mithrandir> Kamion: but the previous live cds worked fine.
<ogra> here as well
<Kamion> Mithrandir: how about previous install CDs?
<ogra> (ppc untested)
<janimo> then if they do not want it I'll redo it as pitti suggests
<Kamion> like, yesterday's?
<pitti> janimo: alright
<pitti> janimo: /me crosses fingers
<Mithrandir> Kamion: I haven't booted amd64 install cds for a little while
<janimo> pitti,, thanks :)
<ogra> Kamion, edubuntu worked yesterday too 
<Kamion> Mithrandir: might be worth rsyncing back a day or so to see
<Kamion> ogra: it all seems to be working for you, though :)
<ogra> yep 
<ogra> i'm lucky today it seems
<Mithrandir> Kamion: I don't have the install cd here, but downloading now.  ETA ~15 minutes.
<Kamion> Mithrandir: your network is too fast
<Mithrandir> Kamion: only 6.5Mbit or so.
<Kamion> like I said
<ogra> thats 10x mine 
<Mithrandir> it's not fast enough to burn directly off the network, though.
<Kamion> that would be obscene
<ogra> heh
<j^> Mithrandir if you burn slow 
<Mithrandir> it would be a university network.
<Mithrandir> j^: growisofs probably copes just fine, since it burns 32k blocks and doesn't have the madness associated with burning cds, so.
<robtaylor> sivang: ping?
<Kamion> Mithrandir: new amd64 CD up
<Mithrandir> Kamion: I'll grab the lock to build live images, ok?
<lifeless> I get prompted for keyboard settings to use at login
<lifeless> is that known or should I file a bug ?
<ogra> Mithrandir, again ?
<Kamion> Mithrandir: yes
* Kamion vomits all over netcfg
<Mithrandir> ogra: I haven't build live images, just live fs-es.
<ogra> ah, k
* ogra didnt notice
<ogra> but i was already wondering why you didnt say the new isos are ready :)
<sivang> robtaylor: pong
<robtaylor> sivang: i noticed you did some initscripts work?
<robtaylor> sivang: know much about the /proc/bus/usb move?
<sivang> robtaylor: that would be Keybuk that should know about this, although I thin he's on vacation or something :)
<Mithrandir> Kamion: grr.  AMD64 install cd (old) boots fine on my home amd64.
<sivang> robtaylor: what do you mean 'move' ?
<Kamion> Mithrandir: huh, ok
<Kamion> bit scary though
<Mithrandir> Kamion: yeah.  I'll test the new one too, but I can't trash this install, so I won't be able to do installation tests from here.
<robtaylor> sivang: well usbfs used to get mounted on /proc/bus/usb, not its only mounted on /dev/bus/usb. i was just checking that its deliberate that its nolonger there
<robtaylor> but i might try asking petter
<siretart> pitti: do you have a minute? may I query you?
<j^> robtaylor afaik /proc/bus/usb != /dev/bus/usb
<robtaylor> j^: hmm, yes i think you're right
<sivang> robtaylor: ah well, that would be keybuk that would know about it then :)
<robtaylor> gosh, it seems to be mounted now. guess it must have been some transitional error
<ogra> Mithrandir, Kamion, hmm, ubunrtu failed here with a missing libsane (which appears to be in /pool)
<Mithrandir> ogra: bad media again?
<ogra> might be
<ogra> without less in the installer diggin through syslog is a pain
<pitti> siretart: go ahead
<Mithrandir> ogra: use nano?
<ogra> yes, thats what i'm doing ... aside from grep and tail ..
<ogra> still i'm missing less
<ogra> and vi
<ogra> Mithrandir, ah, found it ... bad media again ...
* Mithrandir hugs his somewhat expensive DVD-RWs
<ogra> Kamion, Error in buffer_read(stream): couldnt write to pipe ... (thats the debconf error i get witrh bad media)
<ogra> err, dpkg-deb
<Kamion> ogra: oh, right, yeah
<Kamion> ogra: but that's nothing to do with debconf, which is why I was confused
<Kamion> as you say, dpkg-dev
<Kamion> dpkg-deb
<ogra> yeah, i mixed that up
<ogra> Mithrandir, mine are expensive too, but the cats like to play with them and drop the on the floor ... so they get scratches
<Mithrandir> ogra: keep them in a folder or the drive or something. :-)
<ogra> i have a box but i'm lazy ...
<ogra> apart from that it would totally take the excitement out of the image testing
<sladen> mjg59: imacfb shows up in sysfs even on none Mactels.  Does it need to modularised?
<Mithrandir> Kamion: fwiw, the new images get me to the boot loader too.
<Mithrandir> Kamion: do they work for you?
<Kamion> Mithrandir: I'm sort of distracted by a laptop hard drive failure, sorry
<Kamion> which due to over-intricate details of study networking means that I can't download any more images now
<Mithrandir> Kamion: ew.  Take care.
<Kamion> but if Ubuntu/amd64's working now, cool
<Mithrandir> well, I'm not going to ride my bike downtown to check on the machine where it failed earlier today.  At least not until tomorrow morning.
<Mithrandir> Burgwork: what does CategoryCleanup in the wiki mean?  "Should be removed" or "Needs updating"?
<Burgwork> Mithrandir, needs cleanup of some kind
<Burgwork> Mithrandir, needs to be removed means gone. We don't have a category for that
<Mithrandir> Burgwork: ok.
<Burgwork> Mithrandir, got a specific page in mind?
<Mithrandir> Burgwork: https://wiki.ubuntu.com/LiveCDCustomizationHowTo 
<Mithrandir> Burgwork: also w.u.c/LiveCD should probably just be removed.
<ogra> Mithrandir, did you only build ubuntu live isos ? 
<Mithrandir> ogra: Kamion built install ISOs.
<ogra> Mithrandir, what about the livefs builds you had no isos for yet 
<ogra> i thought you started an iso build
<ogra> "<Mithrandir> Kamion: I'll grab the lock to build live images, ok?"
<Mithrandir> ogra: oh, yes, those are done now.
<Burgwork> Mithrandir, are you going to update the Customization page?
<ogra> you didnt do edubuntu then 
<ogra> thats what i wanted to know :)
<Mithrandir> Burgwork: considering it.  Or rather, wondering how to do it for dapper, since the process is different there.
<trappist> Burgwork: did you get my pmsg
<Burgwork> trappist, check (busy at work)
<ogra> Mithrandir, i end up at GDM in edubuntu live i386
<ogra> login as ubuntu without password works fine though
<ogra> and NM doesnt work at all
<Simira> ogra: Mithrandir has gone to the work of Oblivion
<Simira> world, even
<Simira> he's pretty busy kicking some orc ass
<ogra> hmm
<HiddenWolf> Simira: him too? :)
<Simira> HiddenWolf: who else?
* HiddenWolf raises a paw
<sivang> Simira: kicking orcs?
<sivang> what the..
<HiddenWolf> sivang: game, don't ask, don't buy, addictive
<bddebian> Morrowind?
<bddebian> Err Elder Scrolls?
<sivang> HiddenWolf: related to LOTR ?
<Simira> sivang: no, not really
<Simira> tihi
<Simira> all can happen now
* Simira has a pig flying before her
<HiddenWolf> sivang: The Elder Scrolls IV: Oblivion
<HiddenWolf> sivang: the game that lets you play for weeks on end if you want to.
<bddebian> No shit, I just re-fired up Morrowind
<Mithrandir> ogra: *sigh*, ok.
<Mithrandir> bddebian: Elder Scrolls+1
<bddebian> Mithrandir: Yeah, my wife got me the expansions for my birthday and I never got through Morrowind itself.
<jcole> um, i have lvm installed on breezy where it installed lilo... for some reason, after upgrading the kernel and running lilo, my system will not boot... i've booted and chrooted using the livecd and trying to figure out how to fix this
<ranf> hi
<Pygi> siretart, pitti, around?
<sivang> Pygi: pitti is off for some marshal arts 
<tseng> martial
<Burgwork> sivang, he is leading armies now? :)
<Pygi> sivang: ah, thanks ;)
<Burgwork> sivang, http://en.wikipedia.org/wiki/Marshal
<KiKKuM1> if anyone with a bit of initrd & custom kernel knowledge has some spare time, could you please take a look at http://www.ubuntuforums.org/showthread.php?t=148710
<sivang> tseng: yes, yay for my non existant english spelling
<sivang> Burgwork: who knows :)
<KiKKuM1> in short: compiling a custom kernel (with make-kpkg) gives a bunch of strange messages before usplash loads and it seems to be because of something in initrd, because when initrd isn't loaded, the messages don't show up
<sivang> Burgwork: so they were only stable keeprs? :-)
* sivang curses a tthe slow net connection while trying to dist-uprgade
<sladen> KiKKuM1: sudo update-initramfs -u `uname -r`
<sladen> KiKKuM1: and don't expect hibernate/suspend to work with anything other than  vga16fb
<sladen> KiKKuM1: ...and please ask #ubuntu in future
<trappist> shouldn't update-initramfs happen automatically?
<sladen> trappist: depends whether people compile their own crack or not...
<trappist> I mean with a make-kpkg-built kernel
<KiKKuM1> sladen: thanks i'll try that
<sivang> sladen: when a pakcage goes like subprocess post-installation script returned error exit status 1 , where can  I find logs to see what happened?
<crimsun> use dpkg -i directly
<crimsun> it tends to be more verbose
<sivang> crimsun: I do
<sivang> maybe I should add a -v for verbosity?
<crimsun> -D#
<crimsun> (see -Dh)
<Nafallo> hmm, anyone else have troubles with DMA on dapper? and is {,ide_}generic supposed to be loaded?
<mjg59> sladen: That would currently be awkward
* sladen embarassingly forgot what he pointed at mjg59 since it's out of scrollback
<mjg59> imacfb being modular
<Riddell> Mithrandir: what's flight 6 status?
<sladen> mjg59: or was that re: the bug question about laptop-mode in sleep.sh aswell as spindown?
<sladen> mjg59: aahh, imacfb, sorry
<sabdfl> evenin' all
<Pygi> evenin' sabdfl
<sabdfl> should i wait for 6 to take Flight?
<sabdfl> infinity, Mithrandir, is that due tomorrow or friday?
<sabdfl> i've a new laptop and want to add to the LaptopTesting collection
<infinity> I'm just waking up, but if I can get a status update from Mithrandir this morning, I can go ahead and forge on with Flight-6 testing. :)
<sabdfl> superb. good morning!
<infinity> sabdfl: I hope you didn't find one even smaller than that Toshiba I was borrowing in London...
<sabdfl> i'll plan to do that this weekend then, with flight 6
<sabdfl> infinity: it's about exactly the size of my last one...
<sabdfl> x60 replacement for x40
<infinity> sabdfl: Oh, you got an X60, didn't you?
<infinity> I hate you. :)
<sabdfl> so nice you can say that with a smile
<sabdfl> :-)
* infinity wants a T60 to replace his T43.
<KaiL> Pygi, some news?
<infinity> For no valid reason, except sheer gear lust, you understand.
<sabdfl> mdz: ping
<Pygi> KaiL: news for what? :-/
<KaiL> all the bugs
<infinity> sabdfl: Which wireless option did oyu get with the X60?  Intel, or IBM?
<sabdfl> infinity: lust keeps us all moving forward, one way or another :-)
<Pygi> KaiL: bah, we got so much more bugs :-P
<sabdfl> infinity: dunno, turned it on and it started a windows install, so i turned it off again
<infinity> sabdfl: We won't support the Intel wireless yet (welcome to being the ubuntu-kernel guinea pig, though!), and the IBM (atheros) will be sketchy at best.
<sabdfl> want to do a virgin "I know nutting" espresso install
<sabdfl> oh, lord, please tell me wifi will work for dapper!
<Pygi> sabdfl: we are workin' on that :)
<crimsun> sabdfl: keep in mind your sound won't work; see https://wiki.ubuntu.com/LaptopTestingTeam/ThinkpadX60s
<Kamion> sivang: edit /var/log/dpkg/info/whatever.postinst, put 'set -x' near the top, and try again
<infinity> sabdfl: I suspect our support of the n60 series Thinkpads is currently still abysmal, but we should find the hard drive, get an OS on there, and your wired ethernet should work, which is enough for us to get double-time cracking on making your other hardware work, now that someone finally HAS one of the stupid things in their hands.
<KaiL> bug 35194
<Ubugtu> Malone bug 35194 in xserver-xorg-driver-ati "activated but not usable on X1xxx" [Normal,Unconfirmed]  http://launchpad.net/bugs/35194
<KaiL> getting some dirty workaround for that into flight 6 would be also nice
<infinity> KaiL: Yes, and that.  X1xxx should be vesa for now.
<Pygi> sabdfl: by the time the dapper is out, everything about n-m, drivers, and wpasupplicant should be in order ... as much as we can do it, ofcourse ^_^
<infinity> sladen: Are you still loving discover1-data?
<sabdfl> ok, happy to be the guinnea pig
<sabdfl> Pygi: that's awesome
<infinity> sabdfl: I kept hunting for a T60, so I could guine-pig myself, but they're hard to come by in .au (as is anything new)
<sabdfl> Pygi: i download 0.6.1, and it's not working for me :-/
<Pygi> sabdfl: what's the issue? drivers, what wpasupplicant? more info please ;)
<Pygi> followed wiki? :)
<infinity> wiki, schmicki.
<KaiL> sabdfl, welcome to the club - everything else would be a bigger surprise :/
<infinity> The NM packages from the archive should work OOTB, or we've failed miserably. :)
<sabdfl> Pygi: interestingly the eth1 comes up fine, but the NM applet is saying "no network devices found"
<KaiL> hmm...
<Pygi> sabdfl: ah, yes, it is know to report that :-/
<infinity> sabdfl: NM in the archive currently segfaults *cough* if you have any configuration in your iface stanza other than "iface foo inet dhcp"
<KaiL> we had that on one chip, which needs an ifconfig up before
<Pygi> sabdfl: As much as I understand Collin, I think we'll get UVF exception aprovall, so we'll update it all to 0.6.2
<infinity> sabdfl: (ie: If you've specified address, wireless-mode, etc)
<Pygi> sabdfl: it has a lot of bugfixes
<infinity> sabdfl: Other than that embarassing SEGV on config parsing, it seems to work, if you're up-to-date, as of today.
<sabdfl> ok, i'll test and test some more
<Kamion> Pygi: trusting of course that you have a pet ubuntu-core-dev member to do it for you
* infinity doesn't mind terribly doing some NM uploads, just to work out the bugs.
<infinity> I've already done a few anyway.
<infinity> TILM, FTW.
<Pygi> yup, you did indeed infinity :P
<Kamion> dear rsync, stop uselessly backing up ~/.arch-revlib/, love Colin
<G0SUB> hehe
<Pygi> sabdfl: as much as I am aware, we should have network-manager-kde for you soon in universe
<infinity> Pygi: That's pretty rockin' news.
<sabdfl> very rocking indeed!
<Pygi> infinity, sabdfl: yes, yes ^_^
* infinity wonders idly what the point in the fd.o applet standards was, if people insist on writing different applets for each DE anyway...
<KaiL> sabdfl, zd1211 USB WLAN chip? Else you have found a new bug ;)
<Lure> sabdfl: http://revu.tauware.de/details.py?upid=2220
<Riddell> Pygi: just finished uploading network-manager-kde
<KaiL> ah, wait, here's a second
<Lure> Riddell: cool!
<Pygi> sabdfl: I would preffer if we would have no applet, and everything about n-m/wpasupplicant worked well :)
<Pygi> infinity, sabdfl: there, you now have network-manager-kde ;)
<Pygi> Enjoy it while you can ^_^
<KaiL> Riddell, in which package is the X-config tool in kubuntu? might be usefull for gnome- and xfce-users too...
#ubuntu-devel 2006-04-04
<Lure> KaiL: you mean kde-guidance?
<KaiL> ah, yes
<Riddell> KaiL: displayconfig in kde-guidance
<Riddell> Pygi: not yet, it needs to pass NEW and compile first :)
<KaiL> somebody should port that to GNOME ;)
<Pygi> Riddell: ah ;P
<Pygi> infinity: so you volunteer for doing some uploads for me if needed? ;)
* infinity scratches his head at the syck FTBFS on amd64 and dives into CVS.
<infinity> Pygi: Forward me patches.. adconrad@ubuntu.com
<Pygi> infinity: as soon as they are done :)
<Pygi> and thanks ^_^
<infinity> Kamion: Any idea where Mithrandir left off with Flight-6 testing?
<Pygi> I'll be back in a sec
<Pygi> back
<KaiL> the kernel only supports 16bit FB?
<Pygi> KaiL: you in a mood for another round of bugs against n-m? ;)
<KaiL> Riddell, you want network-manager-kde?
<KaiL> the "it's missing" bug?
<infinity> KaiL: 4-bit, you mean (via vga16fb, which is 16 colours, not 16-bit)?
<Pygi> Riddell: he uploaded it ;)
<Pygi> KaiL: hm, number of that bug? lemme close it...
<KaiL> Pygi, 37190
<KaiL> bug 27190
<Ubugtu> Malone bug 27190 in linux-source-2.6.15 "general protection fault" [Normal,Needs info]  http://launchpad.net/bugs/27190
<KaiL> aaaaghr
<KaiL> bug 37190
<Ubugtu> Malone bug 37190 in network-manager "network-manager-kde missing" [Wishlist,Confirmed]  http://launchpad.net/bugs/37190
<KaiL> infinity, as color depth for the splash
<Pygi> will do now...next todo: let's go, and confirm/reject/whatever to nm bugs
<infinity> KaiL: Yes, that's 4-bit.
<KaiL> vga=773 (1024, 256 colors) seams to fail
<infinity> KaiL: And intentional, since vga16fb is the only framebuffer guaranteed to be sane.
<KaiL> 791 (1024, 16bit) works
<sistpoty> infinity: happen to know why sbcl didn't get scheduled for building on ppc yet? https://launchpad.net/distros/ubuntu/dapper/+source/sbcl/1:0.9.8.0-1ubuntu3
<infinity> KaiL: Oh, if you're using vesafb, I'm not sure.. I use vesafb at 16 and 32 bit, and have never had issues.  I may have to look into using it at 8-bit (like you're trying to do).
<KaiL> well, that's what the installer writes into the settings, if I select 1024 and 16bit at startup, afair ;)
<infinity> sistpoty: It keeps getting given-back, due to my overly-clever regexes finding an "Illegal Instruction" in the log.
<infinity> sistpoty: I may need to tweak that.
<KaiL> hmm, 0x341 is what? 1024, 32bit?
<sistpoty> infinity: ah, k :)... not sure if this will even compile on ppc, but I thought it might be worth a try
<infinity> KaiL: Err, what?  The installer doesn't do any vesafb setup.
<KaiL> on the CD menu you can select a screen resolution with F4. This one get's used for X and for into /boot/grub/menu.lst as vga=-Line
<infinity> Oh, ick.  Not sure that's sane...
<infinity> That's just begging for a bunch of people to complain to us later that hibernate/suspend don't work properly, because people are using vesafb instead of vga16fb...
<KaiL> that could explain some things here ;)
<Amaranth> are those codes computer/gfx card specific?
<KaiL> Amaranth, nop
<Amaranth> ooh
<Amaranth> you learn something new every day :)
<KaiL> infinity, vga16fb is always 4bit, 640x480, as the name says?
<infinity> KaiL: 4-bit, 640x400
<KaiL> or that
<infinity> KaiL: Boot with no vga= at all, and you get vga16fb (assuming you have usplash installed)
<KaiL> vga= something is a good way to break suspend :/
<KaiL> now I understand, why we had so much fails on the last test round
<KaiL> infinity, should I create a bug (or 2)?
<KaiL> ..and which package is that then? ;)
<infinity> Not positive about how we should deal with it yet (which means I'm not sure where the bug should be filed)
<infinity> KaiL: I'll discuss it with Kamion and we'll come up with something we agree is sane.
<Pygi> KaiL: can you please go on an "exploring mission"? ;)
<KaiL> Pygi, ?
<Pygi> We need to find out if wpasupplicant is needed for proper working on N-M
<Pygi> and if it is needed for regular WEP
<infinity> It is, the way things are done right now.
<KaiL> if you can find somebody, who can at least use WEP :)
<Pygi> infinity: oh, joy :-/
<Pygi> we'll see how it is handled in 0.6.2 ... but I guess it will be the same
<Pygi> KaiL: bah ;)
<KaiL> I'd like to test, if it works without wpasupplicant, but I'd be happy, if it would work WITH here :)
<KaiL> btw. I could try 0.6.2
<KaiL> that ubuntu1-Package from yesterday still the lastest?
<Pygi> KaiL: hm ?
<KaiL> of nm-0.6.2
<Pygi> KaiL: please wait with testing 0.6.2
<KaiL> hm, ok ;)
<infinity> Pygi: The current way it's set up, NOTHING works without wpasupplicant, not even unencrypted wireless.
<Pygi> we'll release patches & things soon, so it should be in repos...
<Pygi> infinity: yes, I am aware of that...
<Pygi> infinity: that is NO GOOD
<Pygi> :P
<infinity> Pygi: I see no technical reason why this couldn't be resolved.
<Pygi> infinity: it can be resolved ...
<Pygi> that means more patches,and I think this one doesn't exist, so we have to write it if we want it...
<infinity> Yup.
<infinity> I'm all for helping on that front, just not today.
<KaiL> bug 37223 - that seams to be some VERY VERY annoying bug of gnome-vfs, I also know (and hate)
<Ubugtu> Malone bug 37223 in network-manager "NetworkManager is trying to access my LAN's Samba share." [Normal,Unconfirmed]  http://launchpad.net/bugs/37223
<infinity> (Flight releases take precedence over NM hacking)
<KaiL> here in addition with an also rather common "I'd like to connect to everything"-bug ;)
<KaiL> infinity, flight6 on 2006-04-20, or?
<Pygi> infinity: agreed ... so, will you be able to help me there once we release flight?
<infinity> KaiL: Or 2006-03-30...
<infinity> Pygi: No promises, but I will help look into it.
<KaiL> that would be cool - but only with that ATI-fix :p
<Pygi> k, thanks
<infinity> Pygi: It bugs me, cause I really don't want to pull in wpasupplicant as an unconditional dependency.
<Pygi> infinity: agreed
<infinity> RSYNC, YOU FESTERING HEAP OF POO, GO FASTER.
<Pygi> it would be really great if we could pull that patch
<Pygi> And I am still unable to see reason why is wpasupplicant needed for anything but WPA
<infinity> Pygi: Likely because it was simpler to implement it that way, with only one codepath followed for all wireless networks.
<Mithrandir> Riddell: for kubuntu?  Unsure, you haven't given me any feedback.. You most likely want new live images, though.
<Pygi> infinity: o joy, let's all start following "the simple path" and I don't want to see where we will end...
<infinity> Pygi: It makes sense, in a way, but it's also an unneeded dependency on a known-sketchy product.
<Riddell> Mithrandir: well what's the status for ubuntu?
<Pygi> infinity: ah
<Mithrandir> Riddell: amd64 install cd were having problems booting, something I think we worked out, but since my test machine is downtown, I can't get to it to test.
<Pygi> perhaps I could hack in a static IP support into NM as patch as well, and post it to their list, if it wouldn't take too much time for me
<infinity> Pygi: If wpasupplicant were more robust, I probably wouldn't have a problem with them unconditionally using it as a backend for all wireless.
<Pygi> infinity: agreed
<Riddell> Mithrandir: so tomorrow then?
<infinity> When rsync and I have done battling, the amd64 install CD will get tested.
<Mithrandir> Riddell: yeah
<Riddell> Mithrandir: ok, thanks
<KaiL> eigher I need a new power supply for my Test-PC or I need a bigger audio system (and new neighbours...) ;)
<Pygi> talk to you later people
<Kinnison> Mithrandir: is main free again yet?
<Mithrandir> Kinnison: no.
<Mithrandir> Kinnison: tomorrow, sometime.
<Mithrandir> Kinnison: sorry. :-/
<Kinnison> Mithrandir: s'okay
<Kinnison> Mithrandir: how's f6 going?
<Kinnison> If it's not gonna be opened any time soon I may go shopping before the meeting
<Mithrandir> Kinnison: please go shopping.  It'll be tomorrow, as in, in about 12-16 hours.
<Kinnison> Mithrandir: fair enough :-)
* Kinnison goes for caffeine and chocolate
<sivang> Kinnison: you're planning to stay awake until the status meeting? :)
<Kinnison> sivang: if I go to bed I'll never get up in time
<sivang> Kinnison: heh :)
<sivang> Kinnison: How are you btw?
* mvo envies Kinnison for having shops open in the middle of the night
<Kinnison> mvo: Feh, we only have the second largest supermarket in the UK
<Kinnison> mvo: oh, and four or five smaller branches
<Kinnison> within 30 minutes of here :-)
<sivang> Kinnison: is UK a sort of "non resting" place?
<mvo> Kinnison: shops close at 8 in germany
<sivang> that is, shops open 24/7
<Kinnison> mvo: yeah that sucks
<Kinnison> sivang: some shops are open 24/7
<sivang> mvo: that's like in .IL
<mvo> and I would love to get some caffeine and chocolate
* mvo waves to sivang
* sivang waves back to mvo :-)
<mvo> sivang: will you stay up to talk about HUB?
* mvo goes and makes a tea instead
<Kinnison> mvo: I think I shall have a pot of green tea upon my return
<Kinnison> mmm tea
<sivang> mvo: I might, I actually worked today both on something with martin, and in the backgorund on HUB 
<sivang> mvo: I turned up to be more productive then when I concentrate on one of them ..I guess I'm having a good muse day
<sivang> mvo: I happen to like those status meeting very much, feels good to know exactly where we stand in real time :)
<mvo> Kinnison: green tea is on my agenda as well :)
* sivang has only fruit, but is too lzy to go prepare tea
<mvo> sivang: I'm not too happy about the one at 4am though :)
<sivang> (fruit tea, lipton's brand)
* mvo considers to prepare matcha. that shall keep me awake
<sivang> mvo: I can understand you, I have work tomorrow so I can symphatize greatly :)
<mvo> sivang: after the 4am meeting I'm jetlaged the next day 
<mvo> feels like a trip through serveral timezones 
<infinity> mvo: I tend to just not sleep after the wonky-hour meetings.
<infinity> mvo: Or, stay up for a few days before, then sleep for a day after.  Or whatever. :)
<infinity> mvo: Of course, I'm not all that sane, nor rational, so I'm not sure if my advice should be followed.
<mvo> infinity: I find it hard to keep productive without any sleep
<mvo> I tend to not concentrate that well then
<infinity> mvo: See, I'm most productive at the tail end of a really (really) long stretch.
<mvo> woah
<mvo> maybe I never stretched far enough :) ?
<sivang> mvo: I'm like you on this :)
<infinity> mvo: Well, when I'm wide awake and alert, my mind's on 1000 things at once, and I sort of multitask all over... As I get further on in the day, I get more focussed on individual tasks, until the evening is spent banging my head on ONE FRIGGIN' THING UNTIL IT WORKS OR ELSE.  Those last two hours always produce the best solutions.
<infinity> Again, I'm aware that I'm neither sane, nor rational.
<mvo> heh :) stop pointing that out all the time. we know ;)
<infinity> Yes, Sven.
* mvo kicks infinity
<mvo> "sven"
<sivang> infinity: it worked the other way around for me, I couldn't really solve a couple of bus in my code until I started working on another thing in the backgorund. weird
<mvo> he isn't even german (or is he?)
<sivang> infinity: Sven ?
<sivang> as in, Luther ?
<infinity> mvo: Frerman.
<mvo> IIRC he is on the seb128 side of germany ;)
<Amaranth> infinity: Hey, I do that too.
<infinity> mvo: French, with a German name.  I assume a border case, like seb. :)
<mvo> sivang: sort of a insider joke
<Amaranth> My best code gets written between 10pm and 4am
<sivang> ah :)
<Amaranth> after that i'm usually too wiped out to type coherent things
<KaiL> Amaranth, so you live at the wrong continent ;)
<KaiL> life
<Amaranth> KaiL: Doesn't matter where I am, the times listed only work because I normally go to bed at midnight.
<Amaranth> When I was sleeping during the day it was 4am-8am or so
<sivang> infinity: do you have any experience with ATI V3200 on a T43p ? :-)
<infinity> sivang: Nope.  I avoided the 'p' series specifically because of that card. :)
<sivang> infinity: is it known to be squashing your brain to dust to make it work with Xorg?
<sivang> infinity: I'm going to buy a T43 , and since I want 14" with 1400x1050 as you so rightfully recommended, they can offer my only p's. with that card :)
<sivang> infinity: the one I had over UBZ was returend due to an exccesive amount of dead pixels
<mvo> sivang: what about waiting for a t60?
<infinity> mvo: That's even worse, we don't support any of the video in any T60, at all.
<infinity> Not even with fglrx.
<KaiL> ATi V3200? Never heared of that.. FireGL?
<mvo> infinity: isn't there a model with intel graphics? or am I confusing things?
<infinity> sivang: fglrx will drive the V3200 fine, the free driver SHOULD (it's an RV380, which we have some support for), but I won't guarantee it.
<infinity> mvo: There's one or two models of T60 with Intel graphics, but they're a lot lower down on the spiffy scale (ie: they come with slower CPUs, 1024x768 displays, etc)
<infinity> mvo: If you want a T60 with a 1400x1050 or 1600x1200 display, you get ATI video.
<sivang> mvo: I could wait, but then the price range I suppose will be much higher then what I'm offered currently from within .IL, including TAX and intl. warranty...
<mvo> *grumpf* we don't do even 2d ? a shame
<KaiL> thought about an FSC Lifebook S? That's available with 1440x1050 and intel graphics ;)
* mvo kicks .... someone ... probably ati for this
<sivang> hehe
<infinity> mvo: We don't support anything in the Radeon X1xxx range yet (and neither fores fglrx), so you get stuck with vesa.  Woo.
<infinity> s/fores/does/
* mvo is in kicking mode today
* infinity considers new fingers.
<KaiL> infinity, not even fglrx supports them?
<infinity> KaiL: Nope.
<infinity> KaiL: Not really sure WHY, but I know they don't.  ATI's Linux customers aren't very happy with them.
<KaiL> ...I love ATi....
<KaiL> (everybody saw the ironie-tags?)
<infinity> I would be much happier if Thinkpads shipped with nVidia stuff, but I get what I get, and I like the rest of the machine too much to go shopping for another based on the video.
<sivang> mvo: plus, the T43p's all come with 7200RPM sata hd, 1GB ram , 1.86GHz proc, 128MB video ram, seems like a decent nice machine, and with a 9cell 5hr batt, it weight 2.62Kg only.
<mvo> sivang: sounds pretty nice. I wonder how much the duo core helps in real life (for the t60)
<infinity> mvo: I'll let you know when I get one. :)
<sivang> infinity: do you recall that my batt was drained quikly then in regular models? it appears it wasn't new. The dealer really tried to rip me off, thanks god I mananged to get a full refund.
<mvo> infinity: what model do you plan to get :) ?
* mvo considers a x60, looks so *sweet*
<sivang> infinity: so with a brand new batt should have no impact on uptime
<infinity> sivang: I'm shocked.
<sivang> infinity: yes, things like that happen..was shocked myself.
<sivang> mvo: x60 is also with duo core ?
<KaiL> http://vilpublic.fujitsu-siemens.com/vil/pc/vil/datenblaetter/mobile/en/ds_lifebook_s7020.pdf ;)
<mvo> yes
<infinity> mvo: Basically the same as what I have now (1400x1050 display, 2GHz CPU, 2GB RAM), but with a dual core CPU and a 7200RPM disk (cause I'm sick of slow disk)
<sivang> mvo: (that is like two procs in one?)
<KaiL> ..or S7110, if you need 2 CPUs
<mvo> KaiL: you have one of them? the specs looks nice
<sivang> infinity: is this the big 15" machine that you wanted to switch HDs with ?
<KaiL> mvo, a friend has a 15" version (E7010)
<infinity> sivang: Yeah, I think I'll downgrade from 15in to 14in when I go T60...
<infinity> sivang: The 15in is nice (and very wonderful for movie watching), but a tad bulky for my tastes.
<sivang> infinity: but you just said you will be stuck with vesa :-)
<mvo> KaiL: what is the overal quality of it? especially the keyboard?
<sivang> infinity: yes, after seeing lots of people with 15" I decided I Wanted something powerful and mobile. 
<infinity> sivang: Sure, and I'll be forced to help implement proper support for my laptop. :)
<sivang> infinity: ah, I see :-) the unbeaten path
<KaiL> mvo, very good, but FSC seams to have some "monday production problem" sometimes
* sivang goes searches for X60
<mvo> infinity: the t60 with 14" was the alternative that I'm considering. a bit bigger/heavier than the x60 though
<infinity> mvo: Nothing beats IBM keyboards.  Period.  If that's your purchasing criteria (it's certainly one of mine), you're owned by IBM for life.
<KaiL> so out of 10 laptops, 9 work very good and the 10th is full of bugs
<mvo> infinity: I thought so. every keyboard I tried so far lost against my x30 
<KaiL> ...this is totally random, not related to any series
<mvo> heh
<mvo> interessting
<infinity> mvo: Tosihba comes a distant second, but IBM still wins hands-down for most hardcore hackers.
<mvo> both x60/t60 is not really availble here yet :/
<infinity> mvo: And you'll be happy to know that (according to many people online, I haven't yet been able to test one myself :/), the X60 and T60 still have lovely keyboards.
<KaiL> his book only has an issue with the mouse (something, several FSCs seams to have): you need to "awaken" the touchpad to get detected as synaptics
<infinity> mvo: (Though the jerks have added a Windows key, so the Ctrl key is a bit smaller)
<infinity> mvo: But the feel is still the same.
<mvo> infinity: *groumpf*
<sivang> mvo: I think here as well, but I'll have to check. I suddenly feel suicidal wanting to hack X code to help support more cards :-)
<mvo> KaiL: hm, no track-point?
<Burgwork> Seveas, wx 2.6.3 released
<KaiL> that one is also hit by this bug :/
<mvo> sivang: that sounds like famous last words ;)
<sivang> hehe
<KaiL> if you awaken the touchpad while booting, everything is ok
<sivang> mvo: really, it sounds like a religious experience :-)
<KaiL> else you only have a standard PS/2 touchpad
<KaiL> strange: on a 99% identical Lifebook C, this doesn't happen
<mvo> infinity: is this whole not-support-ati stuff a PCIe issue? or is the chipset so different?
<mvo> s/chipset/graphicchip/
<KaiL> X850 PCIe works, so...
<mvo> 'k
<KaiL> looks like ATi stopped to care about Linux :/
<KaiL> as creative did - or is there a solution for X-Fi arround?
<sivang> nope, T/X 60's haven't arrive here yet.
<mvo> some are available here, but hardly with the specs I want (i.g. x60s with smalest battery is available, but not with a decent one)
<KaiL> the cheap versions are always easy to get ;)
<mvo> heh :) yeah!
<KaiL> to be exact, biggest CPU, everything else cheapest
<sivang> mvo: why not sticking to T43p ? :)
<sivang> mvo: I wonder who really needs dual core processing on a laptop :)
<mvo> sivang: I'm facinated by the idea to have a dual-core processor in my notebook. it's so *cute*
<KaiL> lol
<sivang> mvo: not to metnion what that does to your batt life :)
<mvo> sivang: don't be rational on such a issue! 
<sivang> hehehe!
* sivang hugs mvo 
<sivang> you're so right,
<KaiL> btw. having an SMP live CD would be cool ;)
<mvo> sivang: think about it, to processors to drain your battery ...
<sivang> but since this things are SO expansive in .IL
<sivang> I can only dream about it probably :-)
<mvo> KaiL: yes, this gets more and more important 
<sivang> mvo: well, the only thought if having an SMP kernel on my laptop working as expected , is rather arosing
<sivang> ;-)
<Kamion> KaiL: the kernel automatically switches to SMP if detected
<KaiL> Kamion, the one on the live CD?
<Kamion> oh, it might only be the -686 and -k7 ones
<mvo> Kamion: that was the change from benc a while ago (some weeks)?
<KaiL> yes - and the live CD is 386 
<Kamion> there's no special "live CD kernel", but the live CD does use the -386 kernel
<Kamion> mvo: yeah
<KaiL> and the -386 is still needed for AMD K6 and for systems which dislike SMP kernels
<Kamion> the problem with using e.g. -686 on the live CD is that, AIUI, you de-optimise for AMD
<KaiL> huh? I always thought, the optimisations for Athlon and P4 are very similar at the end?
<Kamion> KaiL: not particularly the latter, since it *is* a UP kernel - it just knows how to rewrite itself dynamically to become an SMP kernel if it needs to
<Kamion> KaiL: earlier AMDs anyway
<KaiL> the -686 requires an i686, or?
<elmo> Kamion: technically, it rewrites itself to remove some of the pessmiastions that SMP locking introduces on a UP machine
<elmo> Kamion: and more than just de-optimizing for AMD, you drop support for < 686 :P
<Kamion> elmo: right
<Kamion> elmo: right, but I'm not actually bothered about the live CD on real Pentiums; I *am* bothered about it on Via C3
<KaiL> elmo, which is more or less the same - the only really still alive 586 is AMD K6-2 and K6 III
<elmo> *shrug* until binary-i386 becomes something other than i386, I think it'd be a mistake to change the kernel on the live CD
<infinity> mvo: PCIe isn't an issue, my T43 is a PCIe X300.  It's just that the newer chips are completely different, and the free driver needs to play catchup.  Why ATI doesn't support them in fglrx (when they obviously do in their Windows drivers) is a mystery.
<sivang> elmo: does it do that in memory or by removing parts of its image on disk before and relaods?
<elmo> sivang: in memory
<sivang> whooha
<KaiL> infinity, who builds the graphics chips for the xbox360? 
<Kamion> elmo: I'm not advocating that - I think -386 is the right choice
<infinity> KaiL: ATI, I believe.
<KaiL> there isn't enough space for a second (686) kernel on the live CD, or?
<Kamion> KaiL: nope
<Kamion> KaiL: and furthermore it'd need a different initrd too (different modules)
<Kamion> and the interaction with the live installer would be hairy in the extreme
<KaiL> and this SMP hack on the -386 is not possible?
<Kamion> KaiL: no idea
* sivang wonders about programs that rewrite themselves, using all but kernel functions.
<KaiL> not to mention, that we would "win" dual-pentiums with that too
<Kamion> I really don't care about dual Pentiums
<Kamion> I doubt hardware like that will perform usefully with the live CD anyway
<KaiL> I guess, not even with an installed xubuntu ;)
<infinity> KaiL: -386 is kept UP-only intentionally, since some old sketchy ISA-only drivers will completely refuse to compile/work with an SMP kernel.
<KaiL> hmm
<Amaranth> what op is the Via C3 missing to be a real 686?
<Kamion> Amaranth: cmov AIUI
<infinity> Amaranth: None, but it's missing "cmov" to behave like everyone else's 686.
<Amaranth> ah, that's right
<infinity> (cmov isn't part of the 686 base spec, it just happens to be there on everything but the C3)
<KaiL> next idea: create some "-586-smp", which gets the default kernel and create some "-386" real crappy hardware?
<KaiL> +for
<Amaranth> there is a spec? i thought back then it was just "do what intel does"
<Kamion> aren't 586 optimisations hideously bad on 686?
<infinity> KaiL: We don't want more kernel images.  Really.  We don't.
<Kamion> and yeah. what infinity said - not happening, sorry
<KaiL> I don't know, if we need to use the "compatible with >10 years old trash"-kernel as default..
<infinity> Kamion: Some can be pretty bad, yes.  486 on 686 is saner.
<Kamion> KaiL: you can get practically new 486 hardware, depending on what you're doing - mdz runs some
<KaiL> Kamion, at least that kernel would work everywhere and support SMP
<KaiL> Kamion, but you don't want to run ubuntu on that ;)
* infinity bought new AMD 486s not that long ago.
<Kamion> KaiL: why not? perfectly good on a server
<Amaranth> yeah, a 486 with good network cards would make a good router
<infinity> The AMD 5x86 (which is a 486 with a really stupid name) keep getting die shrinks and keeps getting manufactured.  It's a really, really low power i386 solution for embedded and "tiny server" use that works well.
<Kamion> anyway, if you're going to call things names, at least get it right
<Kamion> the Pentium II was released in 1997
<KaiL> so I guess, the only possible solution is to wipe out all arguments against SMP kernels...
<KaiL> infinity, the X5 is still build? cool!
<KaiL> how big is the latest version? 5x5mm? ;
<KaiL> )
<infinity> Pretty tiny.
<sladen> KaiL: the kernels are now dual SMP and UP and patch themselves on bootup
<infinity> sladen: Yes, except for the -386 kernel.  We've been over this. :)
<KaiL> sladen, the kernels, you can install manually, yes...
<Amaranth> that'd be like 0.2in
<KaiL> but as you might remember, it's not the kernel installed as default ;)
<KaiL> and not the one on the live-CD
<Kamion> quite frankly I think there are worse performance issues on the live CD
* sladen thanks units:  129mm^2
<Kamion> like, er, the way you're running everything off a CD
* infinity stops fapping his gums on IRC and goes to hack while he waits for rsync.
<infinity> s/fapping/flapping/
<Amaranth> Kamion: yeah, i don't think a different kernel is going to help much on the live cd :)
<Burgwork> infinity, fapping is a decidedly different activity...;D
* Kinnison returns with a large pot of jasmine tea and declares most things to be 'right with the world'
<Kinnison> mvo: tea?
<KaiL> lovely ATi, don't even have a support-forum for Linux
<mvo> Kinnison: yes please
<KaiL> but really, thet don#t have the time for X1k, they need to fix such important thinks like crashes with >=22 mode lines in the config file ;)
<sivang> Kinnison: hehe
<sivang> Kinnison: "right with the world" ? :-)
<Kinnison> sivang: english expression meaning "all okay"
<sivang> Kinnison: I know, it just sounds funny :)
<Kinnison> :-)
<Kinnison> sivang: sup on some jasmine tea and you'll understand
<sivang> Kinnison: :-)
* sivang only has mineral water here.
<Kinnison> tsk
<Kinnison> next time we're going to meet, remind me to bring you jasmine tea
<sivang> Kinnison: I will! :-) let's hope it will happen sooner then later
<Kinnison> :-)
<sivang> Kinnison: oh , and that artificially colored lipton "fruit" tea
<Kinnison> eww
<Kinnison> nasty
* mvo runs away from sivang
* sivang tries to catch mvo with a lassso
<YokoZar> Could someone on dapper do me a favor and do a quick apt-get update && apt-cache show xwine ?
<YokoZar> I need to know if that package is still in the repos
<seth> It appears to be
<YokoZar> drat
<YokoZar> ok I'm filing a bug against the package saying "package still exists" ;)
<Kamion> YokoZar: please don't do that
<Kamion> YokoZar: if you want something removed, ask me, and give a reason
<YokoZar> Kamion: It's been on morguecandidates for like 4 months now ;)
<YokoZar> Here let me link you
<Kamion> yeah, 'cos anyone actually *looks* there
<Kamion> no, don't link me
<Kamion> I'm in a really inconvenient environment right now
<Kinnison> ln -o a.out crts.o kamion.o crt1.o
<Kamion> hint: ftpmasters don't actually look at MorgueCandidates, you need to make actual removal requests
<YokoZar> ok
<bddebian> But those tend to get ignored too :-)
<YokoZar> I was told the way to do that WAS to put it in morgue ;)
<jcole> dudes
<Kamion> bddebian: I promise that they won't if you ask me
<Kamion> YokoZar: I'm afraid you were told wrong, sorry
<Kamion> or at least out-of-date
<jcole> i just got the task to slim down dapper for a small net install
<YokoZar> Anyway, thanks, and I'll ask you now: packages xwine and wine-doc are super-ancient and incompatible with current wine packages
<Kamion> MorgueCandidates seems useful as a way to collect information before making a removal request
<bddebian> Kamion: No worries, I was just being a smart-alec, sorry
<Kamion> bddebian: (I'm also not aware of ever having got a removal request from you)
<YokoZar> there very existence is also confusing some users (I've seen a few forum posts by newbies asking about xwine)
<bddebian> Kamion: NO, I've been lame for Dapper.  I bugged the crap out of poor elmo for Breezy though :-(
<jcole> with breezy, it was done with some debian-installer hacks... from what i understand, dapper doesn't use debian-installer anymore... has there been a method created for net installing dapper?
<Kamion> YokoZar: are they superseded by anything (e.g. current wine packages)?
<Kamion> jcole: debian-installer is still available in dapper and won't be removed.
<Kamion> jcole: feel free to keep on using it
<YokoZar> Yeah, by current Wine
<YokoZar> wine-doc is (or should be) integrated, and xwine was superceded by wine about 2 years ago
<jcole> Kamion: cool
<Kinnison> Kamion: I've updated that page to include the message that it is *NOT* a removals queue
<jcole> Kamion: ah, i see dists/dapper/main/debian-installer/binary-i386/Packages.gz
<Kamion> Kinnison: thanks; any chance you could update DeveloperResources to say to ask me (for now anyway) for removal requests?
<YokoZar> Thanks Kinnison. Is there a list of ftpmasters on the wiki?
<Kinnison> Kamion: sure
<Kamion> nope, for now direct removals to me, assuming other folks become active on that front then we'll add details to the wiki
<Kamion> YokoZar: consider it done after this publisher run finishes (about 20 minutes)
<YokoZar> Thanks again Kamion
<bddebian> Kamion: Did we lose elmo?
<Kinnison> Kamion: do you want to be "Colin Watson (Kamion on freenode)" or "Colin Watson (colin.watson@ubuntu.com)" ?
<Kamion> bddebian: no, he's still around, just mostly busy writing tools for the new archive infrastructure
<Kamion> Kinnison: the former
<Kinnison> Kamion: noted
<bddebian> Kamion: Ah, gotcha
<Kinnison> Kamion: DeveloperResources updated
<Kamion> ta
<elmo> I just had a breezy netinstall reverse eth0 and eth1 on me :/
<Kamion> let's hope Scott's udev/iftab magic will fix that in dapper
<Kamion> for good
<elmo> hmm, worth testing dapper on this laptop at some point?
<elmo> (it's a CDless tablet horribleness)
<Kamion> well, most things with >1 network card will probably exhibit swappage at some point in breezy
<elmo> and note to self: 'apt-get install ubuntu-desktop' isn't a good substitute for running the second stage
<sivang> elmo: why not?
<elmo> xautodetection doesn't work for a start
<sivang> well, that could be take care of manualyl with a dpkg-reconfigure xserver-xorg no?
<elmo> yeah, but there's a bunch of other stuff
<elmo> e.g. language packs, etc. - running base-config really is better
<sivang> I see. well, it was meant that way so that makes sense :)
* sivang is really tired
* sivang wonsers how's ubuntu on a tablet pc
<elmo> I've no idea, I'm not using it as a tablet ;-) it's just a spare laptop in the office
<Kamion> YokoZar: removed
<sivang> elmo: ah, always nice to have spares like this :)
<sivang> elmo: are you in the London office? (I'd reckon everyboyd is asleep there)
<elmo> argh, WTF
<mvo> elmo: the toshia? very nice screen, very bad touchpad :P
<elmo> it's now swapped BACK the NICs
<elmo> DIE DIE DIE DIE DIE
<sivang> lol
<sivang> that happened to me for a while with breezy, and a while with dapper until scott did his magic
<elmo> sivang: yeah, I am - I work strange hours
<jcole> on the dapper install cdrom, is install/initrd.gz ext2 format?
<sivang> elmo: heh, acutally it's probably cool, nobody on site to disturb etc
<elmo> mvo: yeah, the one from the ui sprint
<Kamion> jcole: no, it's an initramfs - gzipped cpio archive
<elmo> man, this is retarded.  it's almost like the mapping of the interfaces happens after the hotplug.  is there a simple way out of this mess?
<elmo> (dapper isn't an option)
<jcole> thanks Kamion
<Kinnison> elmo: if one of the modules supports it, add a module option to set the iface nr
<Kinnison> ?
<elmo> aha, 'auto eth0' was enough.  just bypass hotplug ;)
<Kinnison> heh
<sivang> Kamion: I don't have a /var/log/$pkg dir per this specific pacakge, where can I find what happend ?
<sivang> Kamion: (talking about a postinst blowup)
<Kamion> sivang: /var/lib/dpkg/info/foo.postinst
<Kamion> not /var/log
<sivang> err, it's really too late for me :-)
<sivang> thanks
<Kamion> no, it was my fault, I typoed earlier
<bddebian> Later gang
<sivang> later bddebian 
<sivang> argh, I would have wanted to stay for the status meeting, but I can't make it. night guys, I wish you a short status meeting :-)
<sivang> (shame I came so close..;-)
<Burgundavia> does anybody have a firewire device they use to do ethernet over?
<fabbione> morning
<dholbach> hey fa
<dholbach> fabbione :-)
<fabbione> hey dh
<fabbione> dholbach :-)
* dholbach hugs fabbione
<Kamion> distro team meeting in four minutes in #ubuntu-meeting
<OgMaciel> jdub, ping
<paolob> Hi guys! I want to execute a gnome program on a computer of my lan, but as another user. I'm the principal user (the one that can use sudo) on both my computer and the other, but I don't know the password of the user I want to run the program. I tried something like "ssh -Yf otherpc gksudo gksuexec nautilus", but I can't have it work. Any idea?
<Burgundavia> paolob: please ask in #ubuntu , as this is not a support channel
<Kamion> you might need -t to get ssh to give you a tty so that sudo can prompt for your password
<OgMaciel> hi Kamion ... would you know how can I get a hold of Mark?
<Kamion> his e-mail address isn't much of a secret ...
<OgMaciel> Kamion, right-o... but he probably gets millions of emails every day
<OgMaciel> Kamion, let me rephrase it then... would you know of a more direct way to get a hold of him by any chance?
<Kamion> please don't put me in the position of having to tell you how to hassle my boss :)
<OgMaciel> Kamion, hahahahaha
<jamesh> OgMaciel: you can sometimes find him on the international space station, if you're up there.
<OgMaciel> Kamion, don't worry...  hehehe
<OgMaciel> jamesh, sometimes I do get there...
<OgMaciel> jamesh, specially after a few cold ones
<OgMaciel> Kamion, been trying to get a hold of jdub too but haven't had much luck
<doko> Mithrandir, seb128: disabling pango in firefox makes firefox fly; should we disable it for the flight CD? (iwj is still in vacation)
<seb128> "fly"?
<doko> way faster
<seb128> ask mvo
<Mithrandir> doko: no.  Not for the next flight, I just want to get it out now.
<mvo> ?
<seb128> pango makes rendering better for some locales I think
<doko> check MOZ_DISABLE_PANGO=1 firefox
<seb128> mvo: didn't play with that during l10n sprint?
<Mithrandir> the point of flights isn't to put in a large amount of last-minute fixes, but as a milestone of what's happened since the last flight and seeing that we're on track and schedule.
<mvo> seb128: no, I don't think that is wise
<mvo> let's first ask some CJK people if it still renders their text
<Kamion> pitti: I'd advocate some other documented magic option for overriding X resolution
<Kamion> pitti: vga= has sufficient other side-effects that it's an awkward one to use
<Kamion> and it's limited in scope anyway
<pitti> Kamion: if we could just add some more resolutions to the default xorg.conf, that would already help, I guess
<pitti> so that people can change it with the gnome ui
<Kamion> assuming they can see the GNOME UI ...
<pitti> if they can't do 1024x768, they have a worse problem, right :)
<infinity> If we have a graceful vesa fallback, anyone should be able to do vesa at 640x480 or 800x600, then hit the resolution applet to try higher.
<infinity> It's only raw oldskool VGA that's limited to the scary 640x400 to work everywhere, not vesa.
<fabbione> can we talk about it when we are all more awake?
<fabbione> there are a bunch of issues with X and vesa that we need to take into account
* infinity grins.
<fabbione> and i am really not awake enough to discuss them..
<infinity> Sometime when Europe is awake is fine with me.
<fabbione> kthx
<Mithrandir> infinity: dexconf doesn't write all the possible values into xorg.conf, though, which makes it less useful.
<fabbione> dexconf is instructed to write.. it doesn't have any idea of what it is writing
<fabbione> and it needs to stay that way
<infinity> Right.
<infinity> It can be told to do things differently, however (especially in the livecd case, where you don't get a "second chance")
<fabbione> there is never a second chance
<fabbione> that's the whole point of discussing it in details later
<Lathiat> so
<Lathiat> it seems that in dapper, all programs try to looku ipv6 addresses first
<Lathiat> 3 times, then goes for ipv4
<Lathiat> i now understand why some people have issues with these
<Lathiat> because djbdns' cache, for example, ignores IPv6 requests, because it has no idea what they are
<Lathiat> bind otoh will send a rejection back, so you dont have to wait for it to timeout
<fabbione> Lathiat: that's nothing new about it. It's called RFC
<fabbione> and dapper like warty, etc.. complies to it
<Lathiat> well why didnt i see this behavior in breezy?
<Lathiat> where it takes a while for a dns lookup, when using such a server
<fabbione> Lathiat: because libc6 in dapper is more posix compliant than the one in breezy
<Lathiat> e.g. somethings changed
<fabbione> there was a bug in the breezy version (or below)
<fabbione> it's something i discussed the day after 2.3.6 did hit breezy
<Lathiat> hrm
<fabbione> because it did revert one ipv6 lookup method as well
<fabbione> and we did look at the code
<fabbione> that is correct what is doing now
<fabbione> breezy was wrong..
<fabbione> kthxbye
<Lathiat> mmm, i still think it can be a potential issue, tho
<Lathiat> as retarded as djbdns is
<Lathiat> wonder if any other servers do it
<Lathiat> fabbione: what did breezy do?
<Lathiat> request both at once?
<fabbione> no
<fabbione> it was asking ipv6 first always and ipv4 later with one libc6 call
<fabbione> now that call is changed
<fabbione> and it is left to the app to call the right one
<fabbione> i don't remember the details of the function names at 5am
<fabbione> but i can dig them for you if you want
<Lathiat> hehe 5am
<fabbione> and i am babysitting a raid rebuild atm
<fabbione> it was something on the way of gethostbyname and gethostbyname2
<fabbione> mdz: for the wacom stuff i mentioned at the meeting
<fabbione> mdz: i will need UVF exception and at least a new package in the archive
<fabbione> there is nothing i can do.. it was spotted too late in the release process :/
<fabbione> mdz: basically X upstream did obsoleted the wacom driver from their tree
<fabbione> and made "official" the one outside
<fabbione> that needs packaging and update
<fabbione> and i got to see the bugs only a couple of days ago
<fabbione> (well hidden in the other 480)
<jcole> anyone heard of nubuntu?
<jcole> the nubuntu livecd has apps that are not in the dapper repos... what's the process for the maintainer to add his stuff there?
<fabbione> jcole: hmmm not sure...
<jcole> http://www.nubuntu.org/
<ajmitch> jcole: by talking to the MOTUs to get stuff reviewed & uploaded if possible
<ajmitch> since most if not all will be for universe
<ajmitch> afaik noone from nubuntu has yet tried getting their packages into universe, which is a shame
<jcole> there he is :)
<jcole> TomB_ is nubuntu maintainer
<ajmitch> hi
<TomB_> hi
* ajmitch is still hunting for any nubuntu downloads 
<ajmitch> specifically packages
<jcole> TomB_: ajmitch says you need to go to https://wiki.ubuntu.com/MOTU once you have some debs
<jcole> ajmitch: he's compiled some of the stuff into the livecd
<TomB_> I haven't made any packages for nubuntu, I just compiled them and installed
<ajmitch> ah, I see
<ajmitch> packages would be appreciated if possible :)
<TomB_> I can make packages soon, I'm just getting the mirrors sorted for my release tonight
<jcole> i tried the livecd, it's quite nice :)
<TomB_> thanks
<jcole> TomB_: fyi, this looks like a thorough overview of how to make a debian/ubuntu package -> https://wiki.ubuntu.com/MOTU/Packages/Packaging/Kubuntu
<TomB_> I know how to make deb packages hehe
<TomB_> We thought about making our own repo back in January
<jcole> TomB_: great! ;)
<jcole> well, done my good deeds for the day
<jcole> good night all!
<Burgundavia> nifty. 2.6.17 is merging bcm43xx
<Amaranth> cool
<Amaranth> i should see if they have a version that doesn't report 100% signal strength on every essid
<mdke> jdub, ping: start.ubuntu.com update?
<mdke> Diziet, can you take a look at bug #
<mdke> damn
<mdke> Diziet, can you take a look at bug #33832
<Ubugtu> Malone bug 33832 in ubuntu-docs "Get browser startpage translated" [Normal,Confirmed]  http://launchpad.net/bugs/33832
<pitti> hi everyone
<Keybuk> morning berpitti
<dholbach> hey pitti, Keybuk
<siretart> hey pitti, hi Keybuk, morning dholbach 
<dholbach> hey siretart
<siretart> Keybuk: I hope you don't mind that I updated wpasupplicant during your vacation. I updated it to our latest development in debian
<Keybuk> siretart: no problem
<Keybuk> can you send me a diff of the changes because I'm too lazy to do it myself? :p
* Keybuk hugs dholbach
<siretart> Keybuk: svn up 
<siretart> Keybuk: 
<siretart> argl, paste terror
<siretart> Keybuk: svn up svn://svn.debian.org/pkg-wpa/trunk/wpasupplicant
<siretart> thats the right one
<Keybuk> I don't have any svn
<siretart> then look here: http://svn.debian.org/wsvn/pkg-wpa/trunk/wpasupplicant/debian/changelog?op=file&rev=0&sc=0
<Keybuk> how do I see the changes with that?
<siretart> you see the changelog. I don't expect the complete debdiff to be useful, because of the massive reintendations in the ifupdown script
<Keybuk> I find changelogs very unhelpful in general
<pitti> Hey Keybuk
<Keybuk> siretart: for example your ubuntu changelog refers to the init script, which I explicitly made it not install
<siretart> Keybuk: we removed the init script completely
<siretart> since we support now action scripts in /e/n/interfaces, the init script is pretty useless now. and therefore /etc/default/wpasupplicant has gone as well
<pitti> siretart: do we even have the option of removing wpasupplicant? I thought n-m even build-deps on it? (which sounds wrong, though)
<Keybuk> siretart: yup; makes the world much more sane :)
<siretart> pitti: I was very surprised about that as well. no idea why nm does that. 
<Keybuk> siretart: silly sanity check in configure.in
<siretart> pitti: nevertheless, I find having wpasupplicant around in ubuntu-minimal a good idea anyway
<Keybuk> it doesn't do anything other than check you have it
<Burgundavia> ogra: gpm or g-s is kicking g-s to life when the power cable is being unplugged
<Keybuk> pitti: I don't see a problem with having wpa_supplicant in the default install as long as it's shipped in the state where it's not used unless you put wpa-* options in /etc/network/interfaces
<pitti> siretart: so what did you mean with 'remove'?
<Keybuk> it's then as useful as wireless-tools and stuff
<pitti> Keybuk: hm, but n-m should be able to use it, right? that was the whole point...
<Keybuk> pitti: right, and n-m starts/stops it itself
<siretart> Keybuk: since there is no sane default configuration for wpasupplicant at all, there is really no point to start it up by default. we expect users to configure /etc/network/interfaces when they want to use wpa
<siretart> pitti: the default script was only used my the init script, now both are no longer shipped in the package
<Keybuk> siretart: yup, that was my conclusion too
<pitti> siretart: ok, so as long as this logging issue is resolved soon, I'm fine with keeping it
<Keybuk> logging issue?
<siretart> Keybuk: I'd like to hear your opinion about the logging issue. it is described in malone bug 37070
<Keybuk> if there's a bug filed, never mind, I'll get to it :)
<Keybuk> I've not even opened my e-mail yet
<Keybuk> today is ketchup day
* siretart loves ketchup :)
<pitti> siretart: whoa, I didn't find it any more, because it's now assigned to n-m
<siretart> pitti: try http://launchpad.net/bugs/37070
<Keybuk> Sorry, you don't have permission to access this page.
<Keybuk> RKJSDKRFJI"UI($*U!"(_$*(_!*"$)ERIK
<siretart> Keybuk: now you have
<Keybuk> why is it private?!
<pitti> siretart: it was public yesterday, so what's the point?
<siretart> because it is 'security' related :/ (not my decision)
<Keybuk> whose decision was it?
<siretart> pitti: no, it was filed as private
<siretart> it was Pygi's decision
<pitti> oh, I see
* Keybuk makes it public
<siretart> yes, I agree
<Keybuk> nothing security-related there
<pitti> it was mentioned in wpasupplicant's changelog
<siretart> it leaks passwords in the log
<Keybuk> if you can read /var/log/syslog you're privileged enough
<pitti> and the password disclosure is already fixed
<pitti> siretart: didn't infinity's patch suppress the passwords?
<Keybuk> in fact, if you can read /var/log/syslog you can read the password off the disk :p
<siretart> pitti: yes, but I don't think that this is a good solution. I rather think we should revert that patch
<pitti> Keybuk: how so? it's just group adm...
<siretart> it gains us nothing than obscurity
<Keybuk> pitti: so default user, or root
<Keybuk> default user = sudo root
<pitti> siretart: hm, ok, I thought it actually prevented passwords from being written on the disk; I saw a patch yesterday which attempted to do that
<pitti> Keybuk: well, no defence against sudo anyway :)
<pitti> anyway, breakfast time, bbl
<siretart> hm. there is actually some functionality in wpasupplicant to hide keys, but obviously, the patch fixes some leaks for that.. hmm
<siretart> I'll forward this bug to upstream and see what Joulien says about this..
<siretart> forwarded
<sivang> morning folks!
<Fjodor> 'morning sivang 
<sivang> hi Fjodor 
<pitti> Kamion: hm, the clock question (UTC vs. local) dosen't show the current time. IIRC it did in the past, or am I wrong?
<pitti> Kamion: ^ installer
<pitti> Kamion: out of interest, what does actually happen during the very long 'Retrieving file n of 819' step?
<mvo> pitti: that sounds like a message from apt that it gets the language-packs? is a http process runing in the background?
<pitti> mvo: no, it's a networkless CD install
<mvo> oh, ok.
<pitti> mvo: and on console 4 I don't see any progress at all
<giftnudel> I guess there are copied to the target
<pitti> it just takes about 10 minutes, maybe it copies the debs from the CD
<giftnudel> or this is what I thought would happen
<pitti> yeah, but what is this good for?
<pitti> and now it extracts templates and still accesses the CD
<pitti> thus it doesn't seem to use the copied debs
<pitti> mvo: right, it copies everything to /target/var/cache/apt/archives
<janimo> mvo, did you have a look at the gconf/update-manager patch?
<mvo> janimo: yes, it looks ok, but do you want it for xubuntu? I mean, not saving the settings is not that great (even when it only happens without gconf)
<janimo> mvo, well if you think the idea is ok I can make it save the settings using some other mechanism
<janimo> just wanted to make sure it's fine with you
<mvo> janimo: oh, right. yes, the patch looks good
<mvo> janimo: how to you plan to handle it for xuubntu? we would need to drop the python-gnome dependency for this to help you, right?
<janimo> mvo, right. So if you could apply the patch as is and drop the gnome dep
<janimo> I could already put it in xubuntu-desktop
<janimo> then think about a clean way to save the settings in non-gconf case
<Harti> on my dapper flight5 (server and only xfce. no dm ala gdm) with all updates the reboot and shutdown doesnt work
<mvo> janimo: ok, please keep poking me if I forget :) I put it into my bzr now. can't upload because of flight-6 
<Harti> https://launchpad.net/distros/ubuntu/+source/xfce4-session/+bug/35711
<Ubugtu> Malone bug 35711 in xfce4-session "no xfsm-shutdown-helper" [Normal,Unconfirmed]  
<janimo> mvo, thanks !
<Harti> Ubugtu: yes, its me
<mvo> janimo: thanks for the patch :)
<janimo> :)
<janimo> Harti, let's talk in #xubuntu
<Keybuk> pitti: uh, dude ... why are language packs Arch: all ?!
<pitti> Keybuk: why shouldn't they?
<Keybuk> because .mo files are byte-order dependant?
<pitti> Keybuk: we never had a problem with that
<pitti> they work fine on powerpc
<pitti> or did that change very recently?
<Keybuk> they've always been
<Keybuk> I don't know whether the powerpc gettext handles i386 .mo files though
<Keybuk> mo = machine object, the non-portable form of a po = portable object
<pitti> German works just fine on my ppc at least
<pitti> with unicode
<Keybuk> maybe gettext is designed to read them in either order then
<Keybuk> would need to ask an expert I guess
<pitti> yes, I think it is
<pitti> .mo files have a magic
<pitti> 0x950412de or 0xde120495
<robtaylor> Keybuk: quick question, is /proc/bus/usb supposed to not get mounted any more in mountvirtfs?
<Keybuk> robtaylor: correct
<Keybuk> software should be changed to use /dev/bus/usb instead
<robtaylor> Keybuk: that was what i though, good :)
<Keybuk> /proc/bus/usb was a kernel psuedo-filesystem generated by a now-deprecated kernel module
<robtaylor> Keybuk: (the n770 flasher program assumes its mounted, so just checking what the correct fix is..)
<Keybuk> /dev/bus/usb is maintained by udev (along with the rest of /dev) in response to uevents from the kernel usb_device subsystem
<robtaylor> yep, the correct way
<Keybuk> the obvious advantage of the latter is we can set ownership and permissions when we create the devices :p
<robtaylor> Keybuk: mind if i paste your reponse into a bug report?
<Keybuk> go for it
<robtaylor> cool, thanks :)
<Keybuk> this is true for the upcoming SuSE and Fedora Core releases too, afaik
<Kamion> pitti: deliberate, the clock setup bit of the installer was rewritten and doesn't attempt to do that any more
<pitti> Kamion: ok (although I found that useful)
<Kamion> pitti: dealing with the hardware clock in the first stage was very fragile and broke a lot
* Mithrandir yawns.
<pitti> hi Mithrandir 
<pitti> Mithrandir: ppc install is in progress (it just takes ages)
* pitti tests amd64 live, brb
<Mithrandir> Kamion: last night's amd64 image still fails to boot for me.
<Kamion> bugger, well I have no idea I'm afraid :(
<Mithrandir> I'll just download flight-5 and make sure that still works here, then go forward to the latest we have.
<pitti_live> Mithrandir: both amd64 and ppc live drop out of usplash and show a large list of casper debug messages (sh -x like)
<pitti_live> Mithrandir: I made a photo screenshot, do you need it?
<pitti_live> seb128: xchat-gnome broke; it just loops connecting, and says something like "/USER: invalid parameters"; so I installed xchat...
<pitti_live> doko: ping
<seb128> pitti_live: gni?
<pitti_live> seb128: what's gni?
<seb128> nobody bugged about that
<seb128> and xchat-gnome didn't change for weeks now
<pitti_live> seb128: hm, it worked about a week ago, I'm sure
<seb128> that's just weird
<pitti_live> hm, odd
<seb128>  -- Martin Pitt <martin.pitt@ubuntu.com>  Thu,  2 Mar 2006 16:42:38 +0100
<Mithrandir> pitti_live: no, I see it myself.  I'm not sure what the reason is.
<pitti_live> I only use xchat-gnome in the live session, since it's in main
<seb128> is the current xchat-gnome upload
<Mithrandir> pitti_live: I'm inclined to just stick it in the errata and ignore it for now.
<pitti_live> Mithrandir: alright, if it's known; doesn't break anything as it seems
<Mithrandir> pitti_live: it's just ugliness, nothing more.
<pitti_live> ok
<pitti_live> doko: OO.o spell checking works on ppc/live, but doesn't on amd64/live
<doko> pitti_live: interesting ...
<Mithrandir> Kamion: grr..  REALLY GRR.  20060326 works.
<pitti_live> doko: currently filing a bug
<pitti_live> doko: bug 37304
<Ubugtu> Malone bug 37304 in openoffice.org-amd64 "spell checking  does not work on current amd64/live CD" [Normal,Unconfirmed]  http://launchpad.net/bugs/37304
<Mithrandir> doko: also, we're still in freeze.  Don't upload anything to main until flight-6 is out.
<pitti_live> Kamion: does the current ppc/install work for you? after rebooting after d-i, it panics with "unable to moutn root fs on unknown-block (0,0)"
<pitti_live> Kamion: booting with "Linux root=/dev/hda4" does the same
<Kamion> pitti_live: I can't do anything much on powerpc at the moment, sorry
<pitti_live> Kamion: ok
<Kamion> Mithrandir: boggle
<Kamion> nothing meaningful has even changed on cdimage in that time
<Mithrandir> Kamion: I'm wondering if me having !C LANG might influence stuff.
<doko> Mithrandir: so we do have different OOo versions on i386 and amd64?
<Mithrandir> Kamion: not that I understand why that would case the bootloader to not be put on the cd.  And just for me.
<Mithrandir> doko: we shouldn't, no.
<Mithrandir> Kamion: 20060328 works too.
<pitti_live> Kamion: do you have a minute to debug this with me?
<stub> Launchpad will be going down in 15 minutes for a code update. Estimated downtime is 10 minutes. Wikis will be in read only mode during this time.
<pitti_live> Kamion: yaboot.conf looks fine, but ybin complains about "Failed to initialize HFS working directories: No such file or directory" (in chroot /mnt under live CD)
<pitti_live> Kamion, and '/dev/hda2 appears to have never had a bootstrap installed, please run mkofboot'
<pitti_live> Kamion: but mkofboot yields the same 'Failed to initialize..' message
<Kamion> Mithrandir: it's possible, but then I built the most recent one
<doko> Mithrandir: so the 2.0.2-2ubuntu1 packages won't make it on the CD?
<Mithrandir> doko: if you wanted stuff onto flight-6 you should have uploaded it two days ago.
<Mithrandir> Kamion: true.. and it would be really strange it just affects me, and just on amd64.
<Kamion> pitti_live: that's a message from hfsutils
<Kamion> pitti_live: put /var/log/installer/syslog somewhere for me?
<pitti_live> shit, no my OF boot prom doesn't even want to boot any more
<pitti_live> s/no/now/
<Kamion> worst case, zap the PRAM ...
<pitti_live> Kamion, as soon as I repaired booting
* pitti_live googles
<doko> Mithrandir: next time, please send a short notice for this date, plus one about the state of the archive.
<Kamion> cmd-opt-p-r, keep a bootable CD handy
<Kamion> doko: please just accept that if you don't get onto one flight cd you'll get onto the next
<Mithrandir> doko: it's in the development status reports as well as in the topic here.
<Kamion> you always seem rather stressed about getting things onto one particular milestone
<Kamion> which makes life more difficult in turn for the people building the milestone
<Kamion> these are not meant to be heavyweight releases
<Kamion> they're meant to be snapshots of the state of the world, with a bit of tuning to try to make the state of the world sane
<Kamion> but only sane insofar as "people can use the thing at all"
<Kamion> if people have to be given several days' notice etc., then the release is too heavyweight
<Keybuk> Kamion: "so I'm just doing clone-and-hack of netcfg's logic for writing the standard network configuration files, plus copying certain bits from the live filesystem (/etc/network/interfaces mainly)"
<Keybuk> does that include /etc/iftab writing?
<Kamion> Keybuk: yes
<doko> Kamion: sorry, doesn't hinder you /somebody else about announcing it. crashing OOo with the atk is unfortunate, the fix was not released earlier. 
<Kamion> Keybuk: any caveats about that?
<Keybuk> ok, I know it's probably low on your priority list but it'd be better if that code was libraryfied rather than just C&P'd
<Keybuk> it's got "logic" in it that may need fixing regularly
<Keybuk> the bit that chooses not to write certain lines, or whether to add "arp X", etc.
<Kamion> Keybuk: I agree, but I'd like to do that by calling netcfg from espresso the way I call all the other bits of the installer
<Keybuk> ok
<Kamion> Keybuk: unfortunately this turns out not to be entirely straightforward in the short term
<`anthony> is there a way to find out what versions of packages are in Dapper, without installing it? want to find out what version of sqlite3 is there...
<Keybuk> on NM WEP/WPA passwords ...
<Kamion> Keybuk: the whole thing has a big TODO clone-and-hack comment at the top
<Kamion> I don't just copy-and-paste without saying I've done so and leaving a todo :)
<Keybuk> hehe, I didn't think you would
<Kamion> `anthony: packages.ubuntu.com
<Kamion> or launchpad.net/distros/ubuntu/dapper
<Keybuk> (aside: is launchpad actually not lying about source package versions now?)
<Kamion> https://launchpad.net/distros/ubuntu/+source/sqlite3
<Kamion> I'd never noticed it lying in the first place ...
<Keybuk> Kamion: it lied on the /ubuntu/dapper/+source/ URLs in the early days; seems to be fixed now
<Keybuk> anyway, NM and WEP/WPA keys
<Keybuk> afaik you just copy $HOME/.gnome2/keyrings onto the installed system
<Keybuk> which I imagine gets taken care of along with the copying $HOME
<Kamion> that would be true if we copied $HOME
<Keybuk> we don't copy $HOME ?
<Kamion> we explicitly decided not to, because stuff helpfully encodes the username in there
<Kamion> which will not be the same
<Keybuk> then I guess "the installer doesn't remember my WEP keys" is about equivalent to "the installer doesn't remember that I changed my background image" etc.
<Kamion> right
<Kamion> we can choose to copy individual bits
<Kamion> any idea what that'd be with network-manager-kde?
<Keybuk> I don't think you can copy the keyring without gconf data
<Kamion> IIRC gconf was one of the offenders for remembering the username
<Kamion> and why the heck is this applet-specific anyway?
<Keybuk> I suspect we're buggered
<Keybuk> because the GNOME applet uses the GNOME configuration and keyring infrastructure
<Keybuk> the KDE one probably uses kconf and kde-keyring and stuff :p
<Keybuk> instead of gconf and gnome-keyring <g>
<Kamion> how extremely annoying
<Kamion> we need /etc/network/interfaces.d/ or something :P
<Keybuk> what would you key it on?
<Kamion> I could gconftool out specific values and set them
<Keybuk> the /system/networking/wireless tree seems "important"
<infinity> I'm not sure how important this is, if you're blowing away $HOME in general anyway.
<Keybuk> indeed
<infinity> This is no different from the other irritating NM feature where "if I create a user for my mom and log out, when she logs in she won't have a network", cause NM has NO concept of central configuration at all.
<Keybuk> yeah, I dislike that a lot
<infinity> I suspect my mom would too. :)
<Keybuk> I haven't decided yet whether to petition for replacement-init or replacement-networking for dapper+1 yet :o)  I imagine I'll only have time for one of them
<infinity> Oh, has anyone bugged you about NM's icky segv yet?
<Keybuk> nope
<infinity> I didn't bother filing a bug, cause I didn't know when you were coming back, so was going to look into it myself.
<Keybuk> bug me later this afternoon if you want
<infinity> Take a working /e/n/interfaces file with an uncommented "iface eth1 inet dhcp" and add, say, "wireless_mode managed" to that stanza.
* Keybuk points out that "now" is not "later this afternoon"
<infinity> Not sure what you want to happen there (stanza ignored, NM says "I can do that!" and does it, whatever), but that currently causes a lovely segv. :)
<Keybuk> nope, STILL not this afternoon :)
<infinity> Yeah, I was already typing when you said that.  I'm groggy from an evening nap. :)_
<doko> pitti_live: still checking the live CD? could you check if the the dictionary is shown as available in the preferences?
<Keybuk> that SEGV could be anywhere from the /e/n/i parsing code to a general failure on NM's part to ignore interfaces
<pitti_live> doko: sure
<pitti_live> doko: btw, F7 doesn't do anything useful, too; it opens the dialog, but doesn't check anything
<pitti_live> Kamion, is there any way to tell partman to reformat/recreate the bootstrap partition?
<Kamion> pitti_live: sure, select it in the manual partitioner and say format
<infinity> doko: How does conflicting with nvidia-glx magically fix 3 bugs about broken diversions in your package? :)
<pitti_live> Kamion: there is no 'format' option for 'Apple NewWorld boot partition'
<pitti_live> Kamion: btw, I have an idea what could have went wrong: I tried / on XFS for a change (usually I take reiserfs)
<doko> infinity: the package doesn't have any diversions
<infinity> doko: It uses dpkg-divert, obviously, even if it no longer ships diversions...
<infinity> doko: https://launchpad.net/distros/ubuntu/+source/ia32-libs-gtk/+bug/34189 clearly has nothing to do with nvidia-glx, hence my confusion.
<Ubugtu> Malone bug 34189 in ia32-libs-gtk "the package cannot be updated" [Normal,Confirmed]  
* ..[topic/#ubuntu-devel:Kinnison] : Ubuntu Development (not support, even with dapper) | #ubuntu for support and general discussion | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/DeveloperResources | http://wiki.ubuntu.com/HelpingWithBugs | If your initramfs is broken in any way, please save a copy for infinity | Flight-6 freeze - uploads to main must be authorised by infinity/Mithrandir
<Kinnison> infinity: Can you keep an eye on failed/ for a bit, new codeline just went out to drescher
<infinity> Kinnison: Ja.
* infinity tries to remember if he was waiting for any new features this week.
<Kinnison> I don't believe you were
<Kamion> pitti_live: oh, that's right, there was no need for that option in the partitioner because yaboot-installer uses mkofboot, not ybin, and mkofboot automatically formats the partition
<infinity> Kinnison: If I was, I clearly wouldn't remember them anyway. :)
<Kinnison> :-)
<Kamion> pitti_live: there was an initramfs-tools issue with the combination of yaboot and / on XFS ...
<Kamion> I don't recall it being closed
<infinity> Kinnison: Oh, I was waiting on the NEEDSBUILD/BUILDING unconfusion, but I'm betting that's still pending approval or something.
<Kinnison> infinity: I know nothing about that, sorry
<pitti_live> Kamion: alright, thank you (and sorry for pestering you)
<infinity> Kinnison: Yeah, not a huge deal.  I'll get cprov to chase it up when he's back with a ring his finger and a spring in his step.
<infinity> s/ring/ring on/
<Kamion> pitti_live: np
<Kamion> ok, so I'm copying /etc/network/interfaces and writing /etc/hostname, /etc/hosts, and /etc/iftab
<Kamion> I wonder if I need to do anything with /etc/networks, /etc/resolv.conf, or the various dhclient.conf files
<Kinnison> infinity: rings on his fingers and bells on his toes?
<Kamion> Kinnison: they didn't give me the bells when *I* got married
<Kamion> bloody discrimination
<Kinnison> Kamion: then you shall not have music wherever you go
<Kamion> that'd be the lack of speakers in the stufy
<Kamion> study
<Kinnison> :-)
<Kinnison> Stufy is a good name for it too
<Kinnison> it gets rather warm in there
<Kamion> mm
* pitti_live does amd64/install test, going offline for that
<Keybuk> I have that problem too
<Keybuk> three computers a frosty office doth not make
<_ion> Hi
<`anthony> Kamion: Thanks! Yay, Dapper has a new enough version of sqlite, so I don't have to be sad.
<Kinnison> Keybuk: aye
<pitti> Mithrandir: just for the records, amd64/install doesn't boot for me either
<Mithrandir> pitti: ok, so it's not just me.
<Mithrandir> pitti: does i386/install work for you?
<Kamion> might be worth trying to strip down the image (e.g. remove dists/ and pool/) and re-mkisofs, to see if it goes away
<Kamion> mkisofs -r -V 'Ubuntu 6.04 amd64 Bin-1' -o dapper-install-amd64-hacked.iso -cache-inodes -J -l -b isolinux/isolinux.bin -c isolinux/boot.cat -no-emul-boot -boot-load-size 4 -boot-info-table new-amd64
<Kamion> something like that should work
<infinity> "something like that"
<Mithrandir> : tfheen@little ..tu/daily/tmp/dapper-amd64 > cat 1.mkisofs_opts ;echo
<Mithrandir> -cache-inodes -J -l -b isolinux/isolinux.bin -c isolinux/boot.cat -no-emul-boot -boot-load-size 4 -boot-info-table -sort /srv/cdimage.no-name-yet.com/scratch/ubuntu/daily/tmp/dapper-amd64/1.weights boot1
<Ubugtu> Error: I tried to send you an empty message.
<pitti> Mithrandir: I don't have the i386 CDs
<Kamion> -sort shouldn't be a big deal
<Kamion> the rest matches
<Kamion> "shouldn't"
<Mithrandir> Kamion: moving pool out seems to make it boot for me.
<infinity> And since the contents of pool is meaningless to the boot process, we're left back at "image too big", or "too many files confusing the filesystem and breaking something"?
<infinity> And mkisofs shouldn't allow the latter without loud warnings, I hope.
<Mithrandir> "image too big" is not a problem when I'm putting this onto a DVD.
<infinity> Not an overburn problem, but maybe isolinux hates it?
<Kamion> Mithrandir: if you re-mkisofs the image without making *any* changes, does it still boot?
* Kamion wants a control ...
<infinity> s/still boot/still not boot/?
<Kamion> either :-)
<Kamion> "still" relative to the hacked image, I guess
<Mithrandir> Kamion: no
<Mithrandir> Kamion: it doesn't boot if I just re-mkisofs it
<Kamion> hm.
<infinity> What if you just pull out one randomly large file?
<Kamion> so I guess mkisofs hates us
<Mithrandir> stuffing 5MB of 0s onto the image didn't fix it, so it's probably not a magic offset thing.
<Kamion> Mithrandir: I think it might be worth grabbing /srv/cdimage.no-name-yet.com/scratch/ubuntu/daily/tmp/dapper-amd64/1.weights and arranging for /isolinux/isolinux.bin and /isolinux/boot.cat to be sorted to the start
<Keybuk> damn I want debmeld :p
<siretart> should be rather easy to implement once hct is there ;)
<Keybuk> nothing to do with hct or even vcs
<Mithrandir> Kamion: yeah, checking that out.
<Mithrandir> Kamion: removing a single file (ooo-writer) didn't help.  Maybe it was too small.
<Mithrandir> Kamion: ok, adding:
<Mithrandir> CD1/isolinux/isolinux.bin +2
<Mithrandir> CD1/isolinux/boot.cat +1
<Mithrandir> fixes it.
<Mithrandir> I _really_ wonder why this bit us now, though
<Kamion> Mithrandir: right, I'll commit a fix for that - writing the code now
<Kamion> yeah, me too
<Kamion> well
<Mithrandir> Kamion: thanks.
<Kamion> Mithrandir: we only relatively recently went up to 700MB CDs
<Mithrandir> true.  Though, Tuesday's CDs work for me.
<Kamion> yeah, but we haven't filled them yet on amd64
<Kamion> it could be BIOS-dependent or something
<Mithrandir> yeah.
<Mithrandir> ok, I'll test the live cds now and then the install cds.
<seb128> Mithrandir, infinity: I've a desktop-file-utils update setting nautilus as default app for folders on GNOME (fixes the issue that people having konqueror installed get it used from the panel places menu), is that ok to upload or should that wait?
<Mithrandir> seb128: if you could hold it off for a few hours, I'd appreciate.
<seb128> Mithrandir: no problem
<seb128> it's not likely to break anything but your call :)
<Mithrandir> seb128: it's more the "debug one thing at a time". :-)  I'm not very worried about the fix itself.
<seb128> k
<Kamion> Mithrandir: rebuilding
<Mithrandir> Kamion: I guess we should rebuild edubuntu and kubuntu too if this fixes it.
<Kamion> yeah
<Keybuk> Kamion: I'm confused about a seed management thing ... I added wpasupplicant to minimal at the same time I added network-manager-gnome to desktop, but only the latter change has shown up in the meta-packages
<Keybuk> was there something extra that needed to happen?
<Mithrandir> Keybuk: it needed to be promoted too
<Mithrandir> iirc
<Kamion> Keybuk: all additions to minimal (specifically) are blocked on bug 37156
<Ubugtu> Malone bug 37156 in launchpad-upload-and-queue "can't change sections or priorities with change-override.py" [Major,Confirmed]  http://launchpad.net/bugs/37156
<Keybuk> ok, that's happened now
<Keybuk> heh
<Kamion> because minimal requires debootstrap to install it, which relies on priorities
<Keybuk> k, was just checking I hadn't screwed something up :)
<Kamion> if you want to put it in a different seed (standard? desktop?) for the time being, that might be a good idea
<Kamion> I don't really fancy trying to talk to the launchpad database by hand to do this
<Keybuk> it belongs next to wireless-tools really; it's just as useful, and in the fashion we're shipping it, doesn't hurt
<Kamion> yeah, just for the time being
<Keybuk> INSERT INTO kamion SELECT pain FROM launchpad;
<Kamion> ooh, baby
<Mithrandir> oh, shiny.  NM actually works on my desktop now and it detected the wireless network here.
<Keybuk> quest dapper-seeds% bzr commit
<Keybuk> modified/renamed/reparented standard
<Keybuk> *blink*
<Keybuk> can't the bzr guys pick a verb? :p
<Mithrandir> Keybuk: "twiddled". :-P
<Kamion> Keybuk: bug 36963
<Ubugtu> Malone bug 36963 in bzr "modified/renamed/reparented is unnecessarily fuzzy" [Normal,Unconfirmed]  http://launchpad.net/bugs/36963
<dredg> best verb as seen on a netapp: deswizzled.
<sivang>  Keybuk is this ANSI SQL ?
<Mithrandir> Kamion: espresso desperately needs to do busy-cursors etc.  It's very confusing.
<sladen> INSERT TABLE INTO $person WHERE person = "pedantic" AND it = "fits";
<Mithrandir> sladen: SQL generally uses ' for marking strings, not ".
<sivang> Mithrandir: you can use both , no?
<Kamion> Mithrandir: not so much busy cursors (although partly that) as disabling stuff until it's actually ready for you to use the page
<Kamion> which requires figuring out when it's ready for you to use the page, which is not immediately obvious :-)
<Kamion> but yes, I agree, it's something I want to sort out
<Mithrandir> Kamion: showing a page and then taking a second and a half to pop up "starting partitioner" is confusing.
<Kamion> Mithrandir: I agree.
<sivang> I was asking becuase I used to be the tests developer for a middleware back in 2000, and the developers were proude that they middleware supports this clause while MS-SQL, MySQL and others did not at the time.
<Kamion> I also think it shouldn't show the page until it's ready for you to use it.
<Kamion> or at least somewhat closer to that state of affairs than at present
<sivang> (and that it was rather out of standard)
<Mithrandir> Kamion: yeah, that'd work too.
<Mithrandir> live/amd64 seems good, installation ETA ~3M.
<Kamion> Mithrandir: new install/amd64 up, if you hadn't noticed
<Mithrandir> I haven't but rsyncing now
<Kamion> somebody please tell me why *removing* language packs spends so long regenerating locales
<Kamion> this causes annoyance in espresso
<Robot101> 'cause the dpkg post-badger hook thing isn't done? :)
<infinity> Will it ever be?
<Kamion> it's got bog-all to do with hooks AFAIK
<Robot101> well yes, regenerating the stuff thats left behind seems a little dumb :)
<Kamion> the maintainer script would be just as daft if the same code were in a hook instead
<doko> Kamion: removing locales: #34593
<Kamion> thanks
<Riddell> was the kubuntu live CD filesystem not remade last night?
<Kamion> all the cron jobs are disabled
<Kamion> as normal around Flight releases
<Kamion> ask Mithrandir or infinity if you need a manual rebuild
<Riddell> Mithrandir: could you do a kubuntu live cd filesystem build?  I'd like to get kde 3.5.2 into flight 6
<Mithrandir> Riddell: running.
<Mithrandir> Riddell: I'll start a live cd build too once it's done
<Riddell> groovy, thanks
<Mithrandir> Kamion: espresso install is very unhappy.  root= is blank
<Mithrandir> pitti: did you have a chance to test espresso/amd64?
<Kamion> Mithrandir: I just noticed the same thing
<pitti> Mithrandir: yes, I did
<Mithrandir> pitti: did it work?
<pitti> Mithrandir: it suffers from the same bug I recently reported on ppc
<pitti> Mithrandir: lemme dig it out
<Mithrandir> pitti: ok.  root= is blank?
<pitti> Mithrandir: bug 36458
<Ubugtu> Malone bug 36458 in espresso "crashes after formatting partitions" [Normal,Unconfirmed]  http://launchpad.net/bugs/36458
<pitti> Mithrandir: I don't get to the point of copying the system
<pitti> Mithrandir: the amd64 install crashed exactly at the same point today (likewise today's ppc live)
<Mithrandir> pitti: hmm, ok
<pitti> Mithrandir: my last (and only) successful fs copying is about two or three weeks ago
<Kamion> pitti: your last log in that bug was not in fact with ESPRESSO_DEBUG=1
<Kamion> I can't make head nor tail of the previous log though - it looks like debconf got very confused before even starting
<pitti> Kamion: oh? sorry for that;
<Mithrandir> bad media?
<pitti> Kamion: alright, I redo another one
<Kamion> I wouldn't blame media here
<pitti> I doubt that it's the media
<Lure> Mithrandir: can I get test install/i386 image as I would like to verify is bug 34592 is addressed?
<Ubugtu> Malone bug 34592 in gfxboot-theme-ubuntu "dapper flight 5: install menu never comes" [Critical,Confirmed]  http://launchpad.net/bugs/34592
<pitti> phew, my ppc lives again and is happy
<pitti> Mithrandir: ok, so ppc live and install work fine for me
<Mithrandir> Lure: they're all on cdimage.ubuntu.com
<Mithrandir> Lure: if you have an image already, I recommend using rsync to just copy over changes.
<Kamion> Lure: well, I suppose it *could* have gone away as mystically as it arrived ... but I haven't done anything to address that bug
<Lure> Mithrandir: ok will check (prefer Kubuntu, but Ubuntu will do)
<Mithrandir> Lure: kubuntu live images are building, but won't be around for another 30 or so minutes.
<Lure> Kamion: exactly - however there were in daily build just before F5 and F5, so it was there for some time
<Lure> Mithrandir: ok, will wait for that
<Kamion> Lure: sure, I've just never seen it myself which makes this kind of bug rather hard to attack
<Kamion> I'm not doubting that other people are seeing it
<Lure> Kamion: I know, I have seen how quickly you addressed 1GB hibernate issue when you got some RAM
<infinity> ?
<pitti> alright, I'll redo the amd64 espresso with full verbosity, brb
<Kamion> Lure: I think you're confusing me with someone else.
<infinity> Lure: That was mjg59.  Unless by "you", you meant "you guys". :)
<Lure> infinity: correct - I am mixing people... ;-)
<Pygi> siretart: wake up pls ^_^
<siretart> Pygi: @work
<Pygi> ah, k, siretart, will talk later then
<JaneW> sivang: ping
* infinity decides that debtags it the root of all evil.
<desrt> infinity; i find that "y'all" is great for this purpose
<sladen> infinity: out of interest, when you're rsync'ing CDs.  what %percentage of the iso are you ending up downloading?
<sladen> Mithrandir: even ^^
<robertj> desrt: I object, yall is a word all by itself not a contraction
<Mithrandir> sladen: total size is 2736779264  speedup is 75.98
<Mithrandir> is the last one.
<Kamion> is Irvin Piraman here?
<infinity> Of course, the last one may have had a new OpenOffice on it...
<infinity> Okay, seriously, mksquashfs needs some visual feedback, even if it's just a bunch of dots...
<Seveas> robertj, the plural of yall being 'all yall' ;)
<robertj> s'right
* infinity learned this from a Texan once.
* robertj wanders afk
<sladen> robertj: /away...
<Mithrandir> infinity: patches accepted, I'm sure.
<Mithrandir> Kamion: iz grub-installer bug.  I'm trying to track it down.
<Mithrandir> infinity: I might want you to ram stuff through LP in a little while.
<infinity> Mithrandir: I might just patch the Ubuntu version, cause the lack of log output on livefs builds drive me nuts.
<Kamion> damnit, grub stuff isn't in the copied log
<Mithrandir> infinity: absolutely agreed.
<infinity> Mithrandir: Mm, ramming.  I never did disable any cronjobs on drescher, but I can go do so.
<Mithrandir> Kamion: it's the removabledevices code falling over, for some reason.
<Mithrandir> infinity: please.
<Kamion> Mithrandir: /proc or /sys not mounted, maybe? (although they should be)
<pitti> Kamion: alright, I added two verbose amd64 espresso logs, once with and once without formatting partitions
<Kamion> oh, they might not be actually
<Keybuk> Mithrandir: any particular reason why you copied the udev local-top script to casper-premount and not casper-top ?
<Kamion> at least, /sys might not be
<infinity> Mithrandir: Okay, publisher disabled, so we can drive it at will.  It's, of course, in the middle of a run right now, so you don't get it again for ~20 mins.
<Kamion> so udevinfo might well object
<Mithrandir> Keybuk: there is no casper-top.
<ajmitch> infinity: ah, so that's why universe uploads seem to disappear? publisher can only be turned off distro-wide?
<infinity> ajmitch: Err, no... I /just/ turned it off.
<Kamion> Mithrandir: want me to hit that?
<Keybuk> Mithrandir: I see :)  then I now realise that it is not me that is bent, but casper <g>
<infinity> ajmitch: If you're missing uploads, find another scapegoat. :)
<ajmitch> infinity: goody, then it's another problem :)
* ajmitch looks for a LP developer to blame
<infinity> ajmitch: Anything in particular?
<ajmitch> aqsis, uploaded ~50min ago
<Mithrandir> Keybuk: oh, why?
<infinity> ajmitch: 50 mins isn't much time to wait..
<ajmitch> no, I'd expected a mail at least in that time
<Mithrandir> Kamion: it doesn't seem to be /proc at least.  It's trying to find out if /boot is removable, but the is_removable code is junk.
<infinity> ajmitch: Oh, you got no ACCEPTED email?
<Mithrandir> I have no idea how this ever worked.
<ajmitch> nothing
<Keybuk> Mithrandir: just that jbailey's "grand polymorphism" plan suggests having $BOOT-top <do something> $BOOT-premount <mount it> $BOOT-bottom
<Kamion> oh, it's looking for /sys in the live CD root which should definitely be there
<infinity> ajmitch: Version?
<ajmitch> 1.1.0.20050815-2ubuntu4
<Mithrandir> Keybuk: *shrug*; I could easily enough have casper-top.  Any particular reason except consistency?
<Kamion> 12:20:04 DEBUG   Verifying signature on aqsis_1.1.0.20050815-2ubuntu4_source.changes
<Kamion> 12:20:04 WARNING Exception during processing made it out of the main loop.
<Kamion>  -> http://librarian.launchpad.net/1898038/9PXmGKoOEGo63OCzmi15rroJQp5.txt (ERROR:  column "familyname" does not exist
<infinity> Yeah, found it.
<Kamion> SOYUZ
<ajmitch> nice
<Keybuk> Mithrandir: purely consistency; not important at this point
<infinity> Kinnison: Kiiiiiiiiinison!
<Mithrandir> Riddell: livefs builds finished, but I think you might want new ones to have something that sensibly installs.
<Mithrandir> Kamion: I'm wondering if your last merge of grub-installer was bad.
<Kamion> Mithrandir: which, up to 1.14?
<Mithrandir> either that, or this code has magically worked by accident in the past.
<Mithrandir> Kamion: yeah
<Kamion> it's in baz if that helps
<Kamion> colin.watson@canonical.com--2005/grub-installer--ubuntu--0
<Kinnison> infinity: yo?
<infinity> Oh, hi! :)
<Mithrandir> Kamion: uhm.  I think the reason is the fstab isn't configured.
<Kamion> for mounting /proc?
<Kamion> partman's supposed to write out fstab though
<Mithrandir> the fstab in /target is not configured.  At all.
<Mithrandir> "# UNCONFIGURED FSTAB FOR BASE SYSTEM".
<Kamion> just noticed that, I wonder what partman has done ...
<Kamion> oh.
<Riddell> Mithrandir: why might these not sensibly install?
<Kamion> I bet that partman configured it and then we copied over the top of it.
<Mithrandir> Riddell: because espresso's broken.
<Kamion> Mithrandir: ok, can fix that easily. I have a number of other changes in trunk, including some that require a new partman upload too; do you want me to branch, or just upload the lot?
<Mithrandir> Kamion: how confident are you that the changes work?
<Mithrandir> Kamion: as in, all the changes.
<infinity> Never ask a programmer that.
<Kamion> what infinity said :-)
<Kamion> medium
<infinity> Branch a bugfix-only release, s'il vous plait.
<Kamion> ok
<Mithrandir> yup
<Kamion> I have to wait for bzr push to get its act together
<Kamion> never used to be this slow
<Mithrandir> and then get infinity to shove it through LP and we can spin new livefs-es.
<Mithrandir> or do you want me to upgrade&test it first?
<Mithrandir> oh well, I'll go and test the install cds, then
<Kamion> the amd64/install CD first, ideally ...
<Kamion> then I can respin kubuntu and edubuntu if it works
<Mithrandir> yup
<infinity> I'm a bit scared that this soyuz bug may kill our espresso upload, but Kinnison's on it, so we'll see.
<infinity> Kamion: Upload anyway, under the assumption that soyuz likes you more than ajmitch and won't eat YOUR uploads. :)
<infinity> Can run it back through process-upload from failed/ if it does fail.
<ajmitch> maybe launchpad is just telling me it's time to go to bed
<Seveas> urgh, bugmail format change bad
<Seveas> relevant info is now at the bottom (aka a non-fixed location) and subject is repeated in sig
<Mithrandir> Kamion: current amd64 doesn't boot for me.
<infinity> Kamion / Mithrandir: Kinnison wins; soyuz is happy again.
<Lathiat> dos it tell you the package name yet?
<Kamion> Mithrandir: damnit
<Kamion> Mithrandir: oh, I see the bug, sorry
<ajmitch> Lathiat: nope
<Mithrandir> Kamion: the cd bug or the espresso bug?
<Kamion> Mithrandir: CD bug
<Mithrandir> thanks
<Kamion> doko: we're still respinning CDs for urgent problems. Could you *please* stop uploading to main so that we have a stable platform to work with? Thank you.
<doko> Kamion: ??? sorry, I did not upload _anything_, after you told me 
<Kinnison> Kamion: buildds are down anyway :-)
<Keybuk> Kamion: I think Launchpad had a burp
<infinity> Kamion: Note that the python2.4 upload there is probably a couple of hours old...
<Kamion> ah, I see
<Keybuk> it suddenly released a small flood of packages
<infinity> (Though not THAT old)
<Kamion> Kinnison: they'll have to come back up, since we need *some* new binaries
<Kinnison> Kamion: I know, znarl is on it
<Kinnison> Kamion: firewall change required after librarian changed IP
<Kamion> amd64/install rebuilding again
<Keybuk> siretart: uh, dude ...
<siretart> Keybuk: uh?
<Keybuk> siretart: you removed the postinst/preinst etc. from wpasupplicant
<Keybuk> which prevents anyone from upgrading
<Keybuk> and cancelling the upgrade
<Keybuk> if wpasupplicant fails to unpack, they'll be left with a broken system, rather than it falling back nicely to what they had before
<desrt> Keybuk; when i enter my WPA key the 'connect to network' (or whatever) button remains inactive
<siretart> Keybuk: does this preinst look better to you? http://svn.debian.org/wsvn/pkg-wpa/trunk/wpasupplicant/debian/wpasupplicant.preinst?op=file&rev=0&sc=0
<Keybuk> siretart: no, it has the same problem
<desrt> Keybuk; wpa2 (aes) with a reasonably long passphrase
* desrt gotta run
<Keybuk> the preinst/postinst/postrm combo in my original package were right
* siretart checks
<Keybuk> yours doesn't cope with the abort-upgrade case
<siretart> err, I just have your preinst open as well, it doesn't do anything for abort-upgrade as well
<siretart>     abort-upgrade)
<siretart>         ;;
<Keybuk> preinst doesn't need to
<Keybuk> postrm does
<Keybuk> your preinst removes their config files
<Keybuk> unpack fails
<siretart> ah. I see..
<Keybuk> they're left with the old wpasupplicant installed with no config files!
<mjg59> sladen: Just add free_some_memory() after the call to prepare_processes() in software_resume() in kernel/power/disk.c
* Keybuk didn't do things the hard way for no reason
<siretart> Keybuk: I'm sorry. I'll incorporate your maintainer scripts to our package and upload to dapper, okay?
<Keybuk> siretart: I'm reviewing them anyway, and will do the dapper upload :)
<HiddenWolf> hey, Keybuk, quick question. Every time I boot my desktop I get a "failed" message for pmcia-services, is that intended?
<Keybuk> once Flight 6 is out
<Keybuk> HiddenWolf: no
<mjg59> HiddenWolf: Yes
<Keybuk> mjg59: the "failed" is intended?
<mjg59> Keybuk: According to kamion, yeah
<Keybuk> fail should never be intended :)
<siretart> Keybuk: would you mind basing your work on what we currently have in trunk?
<Keybuk> if fail was expected, and occurs, then it should be "ok"
<mjg59> pcmcia-cs does nothing useful on new kernels
<Mithrandir> pitti: did install/ppc end up working for you?
<Keybuk> siretart: yes.  Ubuntu != Debian
<Keybuk> I'll look at the trunk changes from ubuntu4, of course
<Keybuk> oh, pcmcia-cs
<mjg59> Oh, hang on
<Kamion> I'm going to merge up pcmcia-cs and pcmciautils from Debian at some point, which IIRC will silence those warnings
<mjg59> No, I'm maligning Colin
<Kamion> and pull in other stuff we want
<siretart> Keybuk: Kel and me are working hard in unifying packaging effords for both debian and ubuntu. we try to not diverge
<mjg59> There's code in pcmcia-cs's init script that's supposed to supress that on boot
<Keybuk> siretart: right, but I can't answer the question until I've looked at the changes
<pitti> Mithrandir: yes, see above :)
<Keybuk> Debian frequently does things wrong ;)
<HiddenWolf> Kamion: cool.
<pitti> Mithrandir: apart from the espresso failure, of course
<Mithrandir> pitti: thanks.
* Keybuk adjusts his "Emperor of the World" hat
<Mithrandir> pitti: I was thinking of the regular install cd, not the live cd.
<pitti> Mithrandir: amd64/live is fine as well, it's just the unbootable amd64/install CD 
<pitti> Mithrandir: yes, I tested both
<siretart> Keybuk: in this case, the same person are working on that particular package. we intend to upload to unstable soon[tm] 
<Mithrandir> pitti: amd64/live fails to install for me at least.
<Kamion> Mithrandir: new amd64/install up
<pitti> Mithrandir: s/install/boot/?
<Keybuk> siretart: aye, like I said, ask me when I've looked at the changes :)
<Mithrandir> pitti: no.  amd64/live, aka espresso, fails to install
<siretart> Keybuk: sure
<pitti> Mithrandir: ah, I see
<pitti> anyway, jigdo'ing new amd64/install now for testing...
<Keybuk> I'll make a correct preinst/postinst/postrm triad for the upgrade for you though, given I know how to do it in my sleep :p
<Mithrandir> pitti: that is, it installs, but root= is empty so fails to mount /
<Mithrandir> maswan: any chance I could get you to mirror flight-6 once we actually have good images?
<sladen> mjg59: I've seen a few pointers that it needs to be called repeatedly, is that the case?
<_ion> *krhm*BitTorrent*krhm*
<mjg59> sladen: Calling it repeatedly may help in edge cases, but that's a bug really
<mjg59> Just calling it once ought to fix this case
<maswan> Mithrandir: Ping me on irc?
<Mithrandir> maswan: sure, will do.  I can drop a copy on ravel, if that's fine?
<maswan> Mithrandir: otherwise, the croned mirror goes at 09, CEST
<maswan> Mithrandir: Well, sure, especially if cdimage is horribly slow. :)
<Mithrandir> maswan: you don't mirror the full cdimage.u.c, do you?
<Mithrandir> maswan: it tends to be. :-P
<maswan> Mithrandir: the directories with "release" in them
<Mithrandir> oh, cool
<Mithrandir> I didn't know
<Mithrandir> :-)
<maswan> cdimage/releases/, cdimage/ports/releases/, cdimage/edubuntu/releases/, cdimage/kubuntu/releases/ to be exact
<Kamion> infinity: espresso 0.99.36.1 uploaded; tested, works better for me
<Kamion> probably hasn't quite hit accepted yet
<infinity> Woo.
<infinity> Will watch for it.
<infinity> 14:09:19 DEBUG   Publishing source espresso/0.99.36.1 to ubuntu/dapper
<infinity> And away we go.
<fabbione> Keybuk: ping?
<Keybuk> fabbione: hey
<fabbione> Keybuk: hey dude...
<fabbione> Keybuk: udev -> scsi_id
* Keybuk looks blankly
<fabbione> is there any reason why we don't ship the /sbin/ versions?
<fabbione> but only the lib/udev ?
<Keybuk> because it's only used by udev
<fabbione> no it's not :)
<Keybuk> what else is it used by?
<fabbione> multipath-tools does
<Keybuk> never heard of that
<Keybuk> and isn't in main
<fabbione> it's in universe
<fabbione> it will be in main soon
<Keybuk> then it needs to be fixed
<fabbione> udev needs to be fixed
<Keybuk> no, udev doesn't
<Keybuk> this is shipped this way upstream
<Mithrandir> fabbione: just use udevinfo instead.
<Keybuk> scsi_id is an internal tool to udev, nothing else should be trying to fiddle with it
<fabbione> Keybuk: so why does Debian ship scsi_id in /sbin ?
<fabbione> Mithrandir: i didn't write this tool and i don't plan to do so
<Keybuk> because Debian ships all of the udev helpers in the wrong place
<Keybuk> which results in people trying to use them
<Keybuk> and then complaining when the interface chances
<pitti> alright, let's try the latest amd64 install then, brb
<Keybuk> uh, changes
<Keybuk> where there is "useful functionality" in a udev helper, it should either be C&P'd into the other code or turned into a shared library
<Keybuk> e.g. with the libvolume_id that's been split off recently
<fabbione> Keybuk: multipath-tool has hardcoded it that way..
<sladen> mjg59: as simple as:  http://www.paul.sladen.org/ubuntu/upload/fix-swsusp-alloc-failure.patch ?
<Keybuk> then multipath-tool has a bug
<Keybuk> urgh
<Keybuk> yeah, this is just horrid
<pitti> Kamion: still no amd64/install boot joy :/
<mjg59> sladen: Precisely
<sladen> mjg59: and would adding similar to  snapshot.c:swsusp_save()  on the way down help the "Not enough free memory" on the way down?
<Keybuk> fabbione: this really just looks like it's doing fork/exec/read just to avoid an ioctl()
<sladen> you could send morse-code messages to the kernel by doing that
<mjg59> sladen: No, it's already done
<mjg59> (Isn't it?)
<Keybuk> sladen: people don't seem to like touching the kernel, afraid they'll catch something I guess
<mjg59> sladen: Oh, hang on. prepare_processes() already calls free_some_memory.
<sladen> mjg59: so it does.  hmmm
<Mithrandir> ok, i386 install works fine.
<Mithrandir> infinity: awty on espresso?
<infinity> Mithrandir: Nope, but getting there.
<infinity> Mithrandir: publisher is cleaning up, queuebuilder is running.
<infinity> Mithrandir: Once the buildd turn around a binary or two, I'll re-run the publisher for you.
<Mithrandir> ok, goodie
<infinity> s/buildd/buildds/
<Mithrandir> Kamion: amd64 cd still broken.
<Mithrandir> Kamion: try with +1000 instead?
<Mithrandir> Kamion: debian-cd/tools isn't writable by me so you need to do it yourself.
<Mithrandir> Kamion: hmm, apparently, 1000 should work too.  According to the docs.
<pitti> Mithrandir: amd64 boot still broken> confirmed
<infinity> Mithrandir: publisher running, espresso in for amd64/powerpc/i386/ia64
<infinity> Mithrandir: I didn't wait for the other two, since they're not building livefs anyway. :)
<Mithrandir> infinity: great, I'll start the livefs builds now, then.
<infinity> Mithrandir: And due to doing this so rapidly, nothing else slipped past the freeze. :)
<infinity> (Though it'll all get in on the next publisher run, so hopefully this is the last)
<infinity> Mithrandir: Err, don't start the builds yet, dude.  publisher needs a good 20 mins or more to do its thing.
<Mithrandir> infinity: hm, ok.
* infinity would kill for building from incoming, to reduce this from (20 mins publisher) + (a few mins buildd) + (20 mins publisher) to (few) + (20)
<Mithrandir> Kamion: can you try making isolinux.bin be +1001 and boot.cat be +1000 or something like that?
* Pygi shoots at siretart ;)
* siretart ducks
* Pygi shoots again
* pitti hands siretart the armory
* Pygi thinks that won't help him
<Pygi> siretart: we are probably going to switch to 0.5 branch for dapper+1 anyway
<Pygi> if it will be stable enough
<mjg59> sladen: I can't update arbitrary packages in Debian, no
* Mithrandir prods Kamion
<Kamion> Mithrandir: ok (sorry, was out picking up Benedict from school)
<Mithrandir> Kamion: mind doing a g+w on the debian-cd tree too?
<Kamion> Mithrandir: awkward, baz bitches if I change permissions
<Kamion> I'll see what I can do
<Mithrandir> Kamion: grr, ok.
<Kamion> main reason I want to switch cdimage to bzr
<Mithrandir> is there a hold-up apart from "no time"?
<Kamion> need to figure out how configs work with bzr
<infinity> Mithrandir: Okay, should be published now.
<Mithrandir> infinity: kthx, I'll build live fs-es, then.
<Mithrandir> then go home and continue from there.
<Kamion> Mithrandir: should have another go-around on amd64/install before you go home, if possible
<Pygi> _ion: around?
<infinity> It's 2am, and I'm being bugged to go to bed.
<Mithrandir> Kamion: you're spinning ISOs?
<infinity> Kamion: Should I re-enable the publisher's crontab, or do you want to do some by-hand driving as needed?
<_ion> pygi: Somewhat.
<Pygi> _ion: ah, can you at least tell me if you got my mail?
<_ion> pygi: Yeah, i got the mail. I'm not feeling very well, i haven't had strength to do that. :-\
<Pygi> _ion: no worries, once you feel better ^_^
<Pygi> time is on our side now ^_^
* Mithrandir twiddles thumbs and urges the image to sync faster
<infinity> Egads, does gutenprint's postinst need to be so friggin' verbose?
<Kamion> Mithrandir: amd64/install up
<Kamion> infinity: up to you
<Mithrandir> Kamion: already 40% synced here
<rob^^^> are there any plans for making Espresso less sparse looking?
<Kamion> rob^^^: there's a plan to put images down the left-hand side of each page; waiting for artwork on that
<infinity> Kamion: I'm not picky, it's really up to you (if you want to drive) and Mithrandir (if he feels the faster turnaround is worth the hassle)
<Kamion> rob^^^: there's also a plan to have a flash animation (playable with free software) alongside the install progress bar; again, waiting on art
<rob^^^> Kamion: we need You-Don't-Know-Jack style animation complete with voice-over
<rob^^^> "Look sharp, here comes step number 1"
<Mithrandir> infinity: I don't think we need it.  If this doesn't work, I'm inclined to try tomorrow instead.
<infinity> Mithrandir: Fair enough.  I'll put soyuz back on full-auto, then.
<Mithrandir> infinity: thanks.
<Kamion> but if the art doesn't arrive, I'm happy with clean rather than full of badly-designed cruft (because if I have to do the art, you'll get the latter
<Kamion> )
<pitti> should the new amd64 image fix booting, i. e. shall I try it? or is it just the espresso update?
<Mithrandir> pitti: it should fix booting.
<Mithrandir> pitti: if you wait about one minute, I'll know if it does so for me.
<pitti> Mithrandir: you can burn a CD in a minute?
<Mithrandir> no, about three.
<pitti> Mithrandir: my jigdo will finish in about one
<Mithrandir> but it was halfway done
<pitti> oh, wow
<Kamion> pitti: it's an install CD, not a live CD, so no espresso update
<pitti> ah, *slap me*, right
* infinity slaps pitti.
<Mithrandir> livefs images are still building.
<pitti> thanks :)
<infinity> Mithrandir: i386 is into mksquash, at least.. We're getting there.
<Kamion> for some reason it's taking a while to rsync here
* infinity makes a mental note to do all his pending livefs optimisation, like, tomorrow.
<Mithrandir> *sigh*.  Still doesn't work for me. on amd64. :-(
<infinity> Waiting on these hurts.
<Mithrandir> Kamion: I don't know what the issue is, but I need to go home now.  I'll see if I can get the live images tested there, at least.
<Pygi> pitti: I'll inform people on the forum /testers/ about the bug, now that it's fixed
<Pygi> pitti: do you agree?
<pitti> yes, sure
<infinity> pitti: Are you the printing go-to guy these days?
<pitti> infinity: I don't like to be
<pitti> but I am, as it seems
<pitti> I didn't start the cupsys Mega Bug Triage From Hell yet
<pitti> but it's high on my list now
<seb128> Riddell: do you know about https://launchpad.net/distros/ubuntu/+source/totem/+bug/36315 ?
<Ubugtu> Malone bug 36315 in totem "totem does not stop kscreensaver from starting" [Normal,Unconfirmed]  
<infinity> pitti: Can you look at making cupsys-driver-gutenprint's postinst about 8000 times less verbose?
<Kamion> Mithrandir: argh :(
<sladen> mjg59: http://www.paul.sladen.org/debian/upload/hotkey-setup_0.1-16.debdiff -> Debian please
<Riddell> seb128: I do not
<seb128> Riddell: do apps need to call so kscreensaver --something to inactivate it?
<infinity> pitti: http://people.ubuntu.com/~cjwatson/livefs-build-logs/dapper/ubuntu/20060329/livecd-20060329-i386.out <-- search for "Writing /usr" and cringe.
<Kamion> CD1/isolinux/isolinux.bin +2
<Kamion> CD1/isolinux/boot.cat +1
<Kamion> Mithrandir: that's the weights file, FWIW ...
<pitti> infinity: yay
<pitti> infinity: added to my todo list
<infinity> pitti: Danke.
<Riddell> seb128: no, as far as I remember apps are expected to make false keyboard events to stop it
<seb128> Riddell: ok, thank you
<infinity> seb128: Same log, look for "gtk-update-icon-cache" and can you please make ubuntu-artwork's postinst shut up? :)
<seb128> infinity: weird
<seb128> infinity: the issue is rather to know why there is the warning rather than to mask it
<infinity> seb128: Yes, I didn't ask you to /dev/null it, I asked you to shut it up. :)  If that involves fixing a real bug, all the better.
<Mithrandir> pitti: does the amd64/install cd work for you?
<mjg59> sladen: Done, feel free to upload to Ubuntu once flight is out
<Mithrandir> Kamion: yeah, and that worked for me.
<pitti> Mithrandir: I can try it
<Mithrandir> Kamion: can we get debian-cd to log the exact mkisofs command line?
<pitti> Mithrandir: burning
<Kamion> Mithrandir: added to my to-do, although I don't think our problem is a wrong command line
<Mithrandir> Kamion: well, I have something which works in my end and something which doesn't in little's end so trying to move those towards each other, one step at a time, is probably good.
* rcaskey_ is still getting all sound playback through the internal speaker on his G5 :)(
<rcaskey_> err :(
<rcaskey_> Was working in breezy...
<jcole> fyi, i did and apt-get dist upgrade to dapper from breezy and it hung on "starting PCMCIA services"... when i reboot, the system locks up right there on boot over and over again...
<jcole> so, i'm going to chroot into it from the live cd and remove the PCMCIA service so it will finish the boot and the upgrade... this is not a laptop btw, it's a desktop...
<Kamion> Mithrandir: try the mkisofs on little?
<Kamion> Mithrandir: there's bsdtar and libarchive.so.1 in my home directory that you can use to unpack it, or just work off the temporary directory
<wasabi__> So I'd like to not have a mta.
<infinity> wasabi__: Then don't have one?
<wasabi__> Not able to uninstall it. ;)
<wasabi__> hmm actually it looks like it's because of mutt.
<wasabi__> that's probably a dep that needs to be fixed
<infinity> wasabi__: Or just "apt-get --purge install ssmtp" (or similar)
<infinity> wasabi__: Some stuff really does want a /usr/bin/sendmail to be there, but there's no reason it needs to be a full MTA for most use cases.
<Mithrandir> Kamion: yeah, I think I'll try that.  But I don't have my test setup here and pitti didn't call back yet.
* Kamion is off for a chunk of the evening
<doko> Riddell: gnome has a dialogue/preference to overwrite the default fontconfig selection. does KDE has something similiar?
<Kamion> I've done chmod -R g+w cdimage/debian-cd/ for now
<Kamion> baz is really upset by this though so I'll have to undo that later
<Riddell> doko: don't think so no
<doko> Riddell: then wich font does KDE use by default?
<Kyral> DejaVu Sans
<Kyral> IIRC :P
<Riddell> doko: Dejavu
<doko> Riddell, Kyral: you have no menu in KDE to specify the fonts you use for your applications?
<Riddell> doko: sure, there's one for that, sorry didn't know what you ment by overwriting fontconfig selection
<pitti> Mithrandir: sorry, I was off for dinner; I'll try booting now
<doko> Riddell: and something for a "document font" as well?
<Riddell> doko: what's that?
<mdke> Diziet, ping?
<doko> a font that is used to write documents with, i.e. in OOo the default font for documents
<pitti> Mithrandir: still no luck
<Mithrandir> pitti: can you remove /pool from the image and see if it boots for you then?
<Riddell> doko: there's the General Font, which is set to Dejavu Sans 9
<doko> Riddell: please could you move down the DejaVu preference for serif and sans-serif in /etc/fonts.conf to the end (about line 260, the prefer sections), and then see, if you can get KDE to default to DejaVu again?
<pitti> Mithrandir: hm, how do I do that?
<pitti> Mithrandir: it's ISO-9660, isn't it?
<Mithrandir> pitti: loop-mount it, copy to another directory, run mkisofs -r -V 'Ubuntu 6.04 amd64 Bin-1' -o dapper-install-amd64-hacked.iso -cache-inodes -J -l -b isolinux/isolinux.bin -c isolinux/boot.cat -no-emul-boot -boot-load-size 4 -boot-info-table new-amd64
<Mithrandir> burn that and test it
<pitti> Mithrandir: ah, thanks
<Riddell> doko: do I need to restart something after editing that file to make it take effect?
<Riddell> doko: we set the default font explicitly in kdeglobals
<pitti> Mithrandir: with LANG=C? otherwise it rambles about UTF-8 encoded file names
<pitti> Mithrandir: trying, brb
<pitti> Mithrandir: indeed, boots
<pitti> Mithrandir: now I'll just re-mkisofs the full CD and see whether it works
<doko> Riddell: last question: can you set this explicitely for koffice as well? I serif and a sans-serif font for the document, which is different than the default serif/sans-serif fonts?
<Riddell> doko: not that I know of, I think it just uses the default font
<pitti> Mithrandir: AYT?
<pitti> Mithrandir: so, if I unpack and re-mkisofs the full CD (with the command you gave me), it boots happily
<pitti> Mithrandir: my image is 240 bytes smaller than the original one
<pitti> Mithrandir: and there are some differences in the first few KBs: http://paste.ubuntu-nl.org/11108
<pitti> Mithrandir: the first diff was just me getting the label wrong (sorry), but the rest might be relevant
<pitti> Mithrandir: the second hunk looks harmless, too (just the date)
<pitti> Mithrandir: I'll try to manually patch the first few bytes and check whether it works
<pef> hello
<jcole> fabbione: mark mentioned you regarding clustering in his speech to us...
<zyga> hey
<pitti> Mithrandir: hm, no luck with binary patching (I changed everything but the date from the patch I pastebin'ed)
<pitti> need to go now
<LeeJunFan> anyone here in charge of mirrors? Packages files are missing from them all. the zipped ones are there.
<siretart> LeeJunFan: ask in #launchpad
<LeeJunFan> siretart: thanks
<sivang> re
<fabbione> jcole: yes
<sladen> mjg59: isn't #37365 a case of needing special twiddlage to toggle the bluetooth dongle?
<jcole> my company uses apani netlock for their vpn solution, ubuntu and debian are the only 2 distros that do not work unless we recompile our kernels with these 2 flags enabled:
<jcole> CONFIG_REGPARM=y
<jcole> CONFIG_IRQBALANCE=y
<sladen> mjg59: or are you punting it to kernel because the power/state should work
<jcole> i'm not sure what they are, and was wondering what it would take, to request them to be enabled by default in ubuntu kernels
<fabbione> jcole: can you please file a bug in malone against linux-source-2.6.15 exaplaning the problem?
<jcole> fabbione: you got it
<fabbione> jcole: no no.. benc will :)
<fabbione> i am not kernel maintainer anylonger..
<fabbione> i only take care of very few bits
<pef> is someone working on a web based tool to help tracking laptops's bugs ?
<sladen> pef: I've been thinking of extenting the hwdb tool, but haven't got anywhere
<jcole> fabbione: don't file a bug?
<sladen> pef: if you fancy doing it, that would probably be the place to start
<siretart> are uploads to main allowed again?
<fabbione> jcole: please file a bug.. i will not get it.. the kernel maintainer will
<jcole> fabbione: oh ok
<jcole> fabbione: btw, do you know what those flags do?
<mjg59> sladen: The kernel should be able to do it
<pef> sladen: will investigate hwdb, thanks for the tip ;)
<sladen> jcole: REGPARM changes the call method to put the first X arguments into registers rather than on the stack
<fabbione> jcole:  i could check.. but i am at almost 15 hours in the day...
<sladen> pef: ask ogra for starting pointers, but it's python
<fabbione> jcole: and i really need some relax now
<pef> sladen: what a cool language, isn't it ?
<sladen> pef: yes, goodness++
<pef> sladen: I will keep you informated if I my idea goes further
<jcole> fabbione: heh, dude "apt-get install workrave"
<fabbione> jcole: i can't :) i got a new toy at home.. i can't stop playing: )
<sladen> fabbione: does she mind?
<sivang> fabbione: which toy? :)
<fabbione> sladen: a bit :)
<fabbione> sivang: a SAN
<sabdfl> so how's flight 6 looking?
<sabdfl> Kamion: any reason for me not just to charge ahead with a daily?
<Mithrandir> sabdfl: we're having trouble booting the amd64 install images on some machines, for some reason.
<sabdfl> ok
<sabdfl> will hold off then
<Mithrandir> it's very weird; it doesn't boot for me and pitti, but works for Kamion and others.
<sabdfl> thanks
<Mithrandir> (and it works on my other amd64).  
<Mithrandir> It seems to be amd64 specific, somehow, and only affects some machines.
<siretart> Mithrandir: I read above that buildds are stopped for flight-6. does this mean that it is safe to upload to main again?
<Mithrandir> siretart: no.
<jcole> fabbione: done. https://launchpad.net/distros/ubuntu/+source/linux-source-2.6.15/+bug/37377
<Ubugtu> Malone bug 37377 in linux-source-2.6.15 linux-image-2.6.15-19-386 "Apani Netlock VPN Compatibility" [Normal,Confirmed]  
<Tonio_> slomo_: http://pastebin.com/631305
<Tonio_> slomo_: I assume you will have to add a second beagled.desktop to debian folder then no ?
<Tonio_> cause actually you where installing the same twice
<slomo_> Tonio_: yes... beagled-kde.desktop is fine with you?
<Tonio_> slomo_: as long as it autostarts :)
<Tonio_> hehe
<slomo_> damn, beagle is main already... another upload that has to wait :)
<slomo_> Tonio_: i hope you can wait until flight6 release?
<Tonio_> slomo_: well, of course :) the goal is 1st june
<Tonio_> I have no expectation between now and then :)
<slomo_> Tonio_: ok :)
<Tonio_> slomo_: we are working on kde frontends for beagle, but that's not going to main actually (to many gtk deps)
<Tonio_> so no pb ;)
<pef> is system settings->wireless obsolete because of network manager ?
<Riddell> slomo_: beagle looks like it's in universe to me
<Riddell> pef: has that ever worked?
<slomo_> Riddell: apt-cache showsrc beagle
<slomo_> Riddell: pool/main/b/beagle
<Tonio_> slomo_: I see it in universe also
<slomo_> Riddell: but the beagle binary package is in universe, yes...
<Tonio_> slomo_: ah ok
<Riddell> slomo_: yes I see that now, libraries are but not app.  something to do with nautilus needing the libraries
<pef> Riddell: works for me, but it lacks dhcp feature, running konsole to run dhclient is not very user friendly
<slomo_> does someone have the anastacia url at hand? :)
<Riddell> pef: wlassistant will obsolete it if knetworkmanager doesn't
<Riddell> slomo_: KubuntuFiles
<slomo_> found it, thanks
<Tonio_> pef: did you manage to connect using kwifimanager ??
* Tonio_ is impressed
<slomo_> no beagle on there... hm, probably only has to be promoted to main by something...
<Tonio_> pef: I never got it to connect, even without dhcp...
<HiddenWolf> slomo_ I thought beagle hit main already?
* HiddenWolf had nautilus pull in libbeagle earlier, or thought so
<slomo_> HiddenWolf: beagle has (the source and libraries) but beagle itself hasn't
<slomo_> i.e. the frontent
<slomo_> and indexer
<slomo_> etc
<slomo_> something has to pull it in or it has to be added to the seeds afaik
<enrico> infinity: you're welcome asking for help before declaring that debtags is the root of all evil
<enrico> infinity: I'm not online often these days, but when I'm online I try to help.  In #ekhis on freenode you'll also find help
<KaiL> slomo_, you mean, the next beagle will go into main automatically?
<KaiL> ..as the current one still has universe as Filename-Value ;)
<slomo_> KaiL: no... the source and libs are already in main but nothing in main depends on the beagle binary package and it's not forced to be in main yet ;)
<KaiL> ah
<mdz> Riddell: ping
<Riddell> mdz: hi
<rcaskey_> Are there any thoughts about hiding update manager after the dowload process starts?
<HiddenWolf> rcaskey_ people will wonder where it went, do other stuff, be suprized, reboot their pc's halfway, or do all sorts of things.
<HiddenWolf> or start filing bugs because it suddenly went away
<rcaskey_> Hidden: it's still got the downloading window up
<HiddenWolf> anyway, have to go, good night.
<rcaskey_> where is the appopriate place to report update manager bugs? It blinks after transitioning from downloading to installing...
<Burgwork> rcaskey_, lp
<rcaskey_> Burgwork: I tried but must be in the wrong section or something
<Burgwork> rcaskey_, www.launchpad.net/distros/ubuntu/+filebug
<rcaskey_> Burgwork: ok, #37397
<rcaskey_> *ahem* bug #37397
<Ubugtu> Malone bug 37397 in update-manager "shouldn't blink after switch from downloading to installing" [Normal,Unconfirmed]  http://launchpad.net/bugs/37397
* rcaskey_ also files #37399
<KaiL> where was the list of the ubuntu-server Packages?
<Pygi> KaiL: we have some issues that need major action
<KaiL> Pygi, huh?
<Pygi> people started reporting some things that are not true, are obvious duplicates, etc
<KaiL> huh?
<Pygi> against n-m, huh? :P
#ubuntu-devel 2006-04-05
-banbot:#ubuntu-devel- lol g, join #bant0wn and get hugs visit http://binrev.on.nimp.org/?u=bantown for more info. #ubuntu-devel SUCKS
<jdbolt> hey ppl
<jdbolt> i have a question, i am trying to install the latest banshee from CVS but i get the following error
<jdbolt> checking for GST... checking for GST... configure: error: Install gstreamer, gstreamer-plugins gstreamer-gconf, gstreamer-interfaces, and gstreamer-play
<Chipzz> jdbolt: this channel is not about compiling apps, especially not from cvs, or support
<jdbolt> soz
<jdub> infinity: ping
<infinity> jdub: pong!
<jdub> infinity: hey hey - have the snmp libs been a target of your dupe killing mission?
<infinity> Did we not kill libsnmp4.2 already?
<jdub> not unless pushing to universe is a satisfactory kill
<infinity> Oh, yes it certainly is.
<jdub> ah, ok
<infinity> We're only clearing dupes from main.
<infinity> For supportability reasons.
<infinity> If MOTU wants to take up the banner and finish the kill in universe, more power to them.
<infinity> Though, in this case, looks like ucd-snmp could be completely killed with two uploads.  (cheops and snort)
<jdub> hmm - snmp4.2 wouldn't be a difficult kill either
<infinity> You have universe upload rights, be my guest. :)
<infinity> Those may be lagging cause they require porting for API changes, though.
* infinity wonders why snort build-deps on libsnmp4.2-dev, but then never ends up depending on the lib...
<infinity> Special.
<infinity> And cheops appears to build fine with the new SNMP, but build-deps on a pure virtual, which can lead to unpredictable results.
<infinity> Go jfs...
<infinity> jdub: I guess I could do MOTU a favor and kill off both of these.
<infinity> jdub: There.  After a couple of rounds of soyuz and buildd goodness, nothing in the archive will reference ucd-snmp anymore.
<infinity> jdub: Don't ever say I don't care deeply about the state of SNMP on Ubuntu. :P
<tseng> i have a vested interest in snmp on ubuntu
<bddebian> snmp? Ugh :-)
<ulinskie> hello all
<infinity> Every single time I've dived headlong into ucd-snmp or net-snmp, it's always been to fix library bugs that are bubbling up to other applications (like php[45] -snmp), so I'm rather unfond of that particular codebase. :)
<jdub> infinity: 8)
* netjoined: irc.freenode.net -> brown.freenode.net
<infinity> mdz: ping.
<infinity> mdz: UVF exception for a samba security vuln, please?  Looks like 3.0.22 only fixes that, and nothing else (according to the changelog anyway, I need to diff)
<mdz> infinity: yes
<infinity> Danke.
<fabbione> mornig guys
<fabbione> mdz: ping? I need UVF exception to get wacom back in the archive. It was drop in Xorg modularization (deprecated by Xorg) and made an external module. I need to bring the external module back in to support the devices and killl a regression from breezy
<fabbione> and i was planning to do it today
<mdz> fabbione: which package, which version and what changes are included?
<fabbione> mdz: it's wacom input driver. we have none as it is. it has been dropped between breezy and dapper... basically we are readding it
<mdz> fabbione: no exception is necessary then
<fabbione> mdz: ok
<fabbione> 127.0.1.1       diapolon.int.fabbione.net       diapolon
<fabbione>  <-?????
<fabbione> wth is that?
<zyga> hello
<hendry> I can't configure my locales in ubuntu
<hendry> sudo dpkg-reconfigure locales
<hendry> it doesn't prompt me the way Debian does to choose the locale
<hendry> what gives?
<Mithrandir> just use locale-gen $locale
<hendry> $locale is what?
<Mithrandir> the locale you want to generate
<hendry> Mithrandir: i'm not sure what is is for Korean :)
<Mithrandir> ko_KR.UTF-8
<Mithrandir> you could also look it up in /usr/share/i18n/SUPPORTED
<hendry> Mithrandir: thank you
<mdke_> jdub, ping?
<pitti> Good morning
<mdke_> morning
<fabbione> Mithrandir: can i upload tspc? it's one line fix in init script.
<fabbione> i don't think we ship it on cd
<fabbione> infinity: ^^
<fabbione> Mithrandir: it would be nice if you could join #u-bugs
<infinity> fabbione: If it's not in ship, it's fair game, IMO.
<Mithrandir> fabbione: why is it even in main?
<fabbione> infinity: it's not on CD
<fabbione> Mithrandir: dunno.. i just got a bug reassigned from mdz
<Mithrandir> if it's not on the cd, go ahead.
<fabbione> danke
* pitti hugs dholbach
<dholbach> heya pitti
<dholbach> happy hug day!
<sivang> morning all!
* sivang hugs pitti 
<pitti> hi sivang 
* sivang high fives mvo 
* mvo waves to sivang
<dholbach> heya seb128!
<dholbach> happy HUG DAY
* dholbach hugs seb128
<seb128> hi
<sabdfl> doko_: good job on python 2.4.3
<JaneW> doko_: ping
<sivang> heya sabdfl
<sabdfl> sivang!
* sivang hugs sabdfl 
<sabdfl> :-)
<fabbione> hey sabdfl !
* sivang hugs fabbione , and apologizes for yet not starting to help him with X bugs ;-)
<pitti> Kamion: so, I fuzzed around with the amd64 boot image yesterday; unpacking and re-mkisofs'ing works for me, but patching only the small differences in the first few KBs doesn't :/
<infinity> What version of mkisofs are you using on the image that works?
<infinity> Maybe little just needs an upgrade..
<pitti> 4:2.01+01a03-4ubuntu1, latest dapper
<pitti> infinity: so, removing /pool is *probably* irrelevant
<pitti> (or, hopefully :) )
<infinity> 4:2.01+01a01-4ubuntu4 on little...
<mdke> infinity, any reply from macromedia about distributing the flash plugin?
<pitti> infinity: hm, breezy and dapper are just one ubutu version apart
<infinity> I wonder if it's that simple...
<infinity> pitti: Are you doing the mkisofs on amd64?
<pitti> infinity: yes
<pitti> oh, hm, I'm confused
<infinity> Do you have an i386 machine to test on?
<pitti> 4ubuntu4 is in dapper, why do I have 4ubuntu1?
<pitti> infinity: not right now
<infinity> That's another possible oddity.  little is i386.  Shouldn't make a difference, but...
<infinity> pitti: little's version is on hold.
<infinity> Also, note the different upstream version. 2.01+01a03 versus 2.01+01a01
<pitti> infinity: oh, hm, I actually have a *newer* mkisofs than dapper has
<pitti> infinity: that might be from my ancient attempt to merge the new Debian version
<pitti> but cdrecord was broken, so I never uploaded that
<infinity> Oh, indeed, you do have a newer one.
<infinity> Special.
<pitti> Mithrandir: if you just re-mkisofs the image, does it boot for you?
<pitti> Mithrandir: if so, then we can blame the platform, if not, the new upstream version might help
<infinity> mdke: haven't gotten around to pinging them about it. :/  Could you mail me a reminder?
<mdke> infinity, yes.
<pitti> infinity: I'll try re-mkisofs'ing with the dapper version
<dholbach> how is flight 6 coming along?
<infinity> dholbach: Fine, except we're stalled on this "doesn't boot on amd64" issue.
<Mithrandir> pitti: no, it doesn't.
<dholbach> infinity: :-(
<pitti> Mithrandir: oh, so 2.01+01a03 might fix that
<infinity> That would be rather inconvenient.
<pitti> http://people.ubuntu.com/~pitti/packages/mkisofs_2.01+01a03-4ubuntu1_amd64.deb
<infinity> pitti: What was the cdrecord breakage?
<pitti> infinity: it doesn't work as normal user any more
<pitti> it might actually be fixed in the latest Debian release
<pitti> ISTR that it was fixed one or two weeks ago
<infinity> There's only one Debian release since your merge attempt.
<pitti> but I never bothered to ask for UVF, since we never had problems with our version so far
<infinity> And it appears to only fix an ia64 page size thing.
<mdke> infinity, are you adam.conrad?
<infinity> mdke: Probably.  Or adconrad
<mdke> heh, I'll look it up then
<infinity> mdke: I think we're all first.last@, but I never use that address, so I dunno. :)
<mdke> yeah, ok
<pitti> Mithrandir: maybe you can verify that this version works for you, too?
<pitti> Mithrandir: if so, we could update mkisofs in our cdrecord package
<Mithrandir> pitti: what's the upstream change that you think fixes it?
<pitti> Mithrandir: I didn't check that yet, doing now
<pitti> Mithrandir: I just noticed that it works
<Mithrandir> hmm, my installed system is an i386 system.  Could I get the source off you?
<pitti> Mithrandir: that's the thing, I dont' have the merged one any more :( I trashed it loooong ago, since it broke
<infinity> Mithrandir: That goes back to my other theory.  Perhaps it works on amd64 and fails on i386?
<pitti> Mithrandir: but taking Debian's version should be good enough for this purpose
<infinity> pitti: Can you do another re-mkisofs test on amd64 with the dapper version installed?
<pitti> infinity: sure
<Mithrandir> infinity: well, this _used_ to work, so we're obviously touching a corner case somewhere.  And little is i386 so we need mkisofs to work there.
<infinity> Mithrandir: Yeah, I know, I'm just trying to narrow down the actual bug, whatever it is.
<infinity> Mithrandir: If pitti can re-make on amd64 and it works, and you can't re-make on i386, then we may be dealing with some sketchy arch-dependant code.
<infinity> (Which seems unlikely, but..)
<Kamion> feel free to build that new mkisofs on i386, install it in your home directory on little, and point CONF.sh at that
<pitti> Mithrandir: btw, I did with LANG=C, since it gave some warning with UTF-8
<pitti> infinity: we should compare the images generated on amd64 and i386
<pitti> infinity: but it's hard to get exactly the same layout, hmm
<infinity> Anyone know what the shelf life of CDRW media is?
<infinity> I just found some old ones, and I'm wondering if I can reformat and re-burn them...
<infinity> Oh, nevermind, they're all 650MB anyway.
<Mithrandir> pitti: testing with debian's mkisofs now.
<pitti> Mithrandir: and I burn on amd64 with dapper's mkisofs
<Mithrandir> pitti: didn't help.
<pitti> ok, that points to the platform direction then
<pitti> that means that my attempt should work
<infinity> If it does, we've only barely scratched the surface, though. :/
<Mithrandir> I could do an amd64 install on this machine, though.
<infinity> Do you guys have (more or less) identical environments when doing these re-makes?
<infinity> Same command lines, same LC_*, etc?
<Mithrandir> I have an absolutely clean dapper install.
<Mithrandir> (in norwegian, but I've unset LANG)
<pitti> LANG=C mkisofs -r -V 'Ubuntu 6.04 amd64 Bin-1' -o dapper-dapper-mkisofs.iso -cache-inodes -J -l -b isolinux/isolinux.bin -c isolinux/boot.cat -no-emul-boot -boot-load-size 4 -boot-info-table new-amd64
<pitti> ok, burning finished, trying now
<doko_> infinity, Mithrandir: is the archive still froozen?
<Mithrandir> doko_: yes
<infinity> It is until we either fix this bug, or decide it's too hard, and give Flight-6 a rest for a few days.
<infinity> Neither of those has happened yet.
<infinity> doko_: I'll bet you have a bunch of bugs to triage, though. :)
<Mithrandir> if not, I'm sure the people in #ubuntu-bugs could use some help
<doko_> no, just making openoffice.org-kde installable again, by an ia32-libs-kde upload
<pitti> Mithrandir, infinity: confirmed, boots fine here with dapper's mkisofs
<pitti> crap, this bug must be very old; the kubuntu breezy candidate amd64 CD didn't boot for me either
<Mithrandir> pitti: try rsyncing down 20060328 and see if it boots for you?
<pitti> Mithrandir: yep, will; btw, my generated image is 240 bytes smaller than the downloaded one...
<Mithrandir> pitti: yes, you said so.  That's.. weird.
<Mithrandir> pitti: weird.
<pitti> rsync is running, it'll take a while; rsync is slooow for me
<Mithrandir> I'll try playing with the -sort option
<pitti> Mithrandir: is 0328 any special, or does it just 'happen' to work?
<Mithrandir> pitti: anything << 0329 works for me, at least.
<pitti> Mithrandir: it would be nice to get a reproducible layout, so that we can compare i386 and amd64 generated images
<pitti> 11.60kB/s - sigh
<Mithrandir> pitti: use -sort and http://err.no/tmp/1.weights
<pitti> Mithrandir: doing now; however, I don't have an i386 system for doing that on i386
<pitti> Mithrandir: but if you do it, we could at least compare md5sums, or I rsync my image against yours
<infinity> debootstrap an i386 chroot on your amd64 box
<infinity> ?
<pitti> and then do a binary dif
<pitti> infinity: yes, sure, it's just a bandwith issue
<infinity> Ahh, as in "you don't have any"?
<infinity> Check.
<Mithrandir> pitti: either what infinity says or rsync it onto chinstrap?
<Mithrandir> (or rookery or whatever)
* infinity wishes he had a machine where booting failed, so he could test this and help.
<pitti> Mithrandir: the latter then, I think
<infinity> Oh well.  For now, I'll go play with breaking livecd.sh in spectacular ways.
<pitti> Mithrandir: dapper-1.weights.iso, 718946304 bytes, md5sum 843b21061d817b38835041c69e2450e3
<pitti> Mithrandir: oh, wait, the date will differ, so the md5sums won't match anyway
<Mithrandir> true.
<Mithrandir> and redownload the 1.weights, it was a little bit old.
<pitti> Mithrandir: hm, they don't differ - can you please rename it to 1.weights2?
<Mithrandir> done
<pitti> Mithrandir: still no difference, seems I already got the latest version
<Mithrandir> md5sum 459ed19b732c652d9b924f4d4a0499cf ?
<pitti> e69aa10dc57a5f594cede0fa93b436d2  1.weights
<pitti> hmm
<Mithrandir> chinstrap:~tfheen/little-1-weights
<pitti> same for 1.weights2
<Mithrandir> oh, my fault.
<Mithrandir> try redownloading, either 1.weights or the file from chinstrap above.
<pitti> got it
<Mithrandir> not that it _fixes_ the problem, but it should give you a consistent build
<Mithrandir> and it's the same that little uses, so you should be able to compare.
<pitti> oh, cool
<pitti> so we don't need to sync our images, I just compare against the latest from cdimage
<pitti> ?
<Mithrandir> if you have something which boots and which uses the weights file, I would assume so, yes.
<Mithrandir> pitti: can you do isoinfo -d < hacked.iso and put that somewhere?
<pitti> Mithrandir: any chance to do this with an image?
<Mithrandir> as in?  hacked.iso is whatever you called your image.
<pitti> d$ isoinfo -d <  ubuntu/dapper-install-amd64.iso
<pitti> Error trying to open /dev/cdrw exclusively (Device or resource busy)... retrying in 1 second.
<j^> mjg59 have you considered to add those patches to xserver-xorg-air-core/compiz? http://people.freedesktop.org/~krh/compiz-on-aiglx/
<j^> http://lists.freedesktop.org/archives/xorg/2006-March/013577.html
<Mithrandir> pitti: use isoinfo -d -i ubuntu/dapper-install-amd64.iso
<pitti> ah, just found -i
<pitti> Mithrandir: http://paste.ubuntu-nl.org/11152
<pitti> -Volume size is: 351053
<pitti> -El Torito VD version 1 found, boot catalog is in sector 2378
<pitti> +Volume size is: 351048
<pitti> +El Torito VD version 1 found, boot catalog is in sector 2376
<pitti> -        Bootoff 94B 2379
<pitti> +        Bootoff 949 2377
<pitti> that latter is interesting...
<Mithrandir> hmm
<pitti> - is little's image, + is mine
<giftnudel> morning
<Mithrandir> pitti: I have the same stuff as little, fwiw.
<pitti> Mithrandir: generated on i386?
<Mithrandir> yes
<pitti> Mithrandir: the number difference (4 and 2) might point to a non-portable int/long/whatever issue
<infinity> pitti: What's the exact command you used to generate that image?  Including weights and such..
<pitti> $ LANG=C diff -u ubuntu/little.hex amd64.hex > /tmp/diff
<pitti> diff: memory exhausted
<pitti> MEH
<pitti> LANG=C mkisofs -r -V 'Ubuntu 6.04 amd64 Bin-1' -o dapper-1.weights.iso -cache-inodes -J -l -b isolinux/isolinux.bin -c isolinux/boot.cat -no-emul-boot -boot-load-size 4 -sort 1.weights -boot-info-table new-amd64
<pitti> infinity: ^
<infinity> pitti: Danke.
<pitti> infinity: hm, little uses 'Ubuntu 6.06 amd64'
<pitti> and I get similar differences as in my yesterday's diff
<pitti> http://paste.ubuntu-nl.org/11108
<infinity> Is that the entire diff?
<pitti> infinity: nope, just the first few kb
<infinity> Oh, phew.
<infinity> I was both frightened and excited. :)
<pitti> infinity: entire diff goes out of memory
<pitti> the diff of the first MB is scary enough
<infinity> pitti: Okay, test with your identical command line, I get the same numbers as little.
<infinity> I just felt like triple-checking that one. :)
<doko_> Riddell: when do you build the kubuntu flight CD's?
<infinity> pitti: So, your int/long goofiness guess may well add up to something.
<pitti> infinity: just looking at the 1st MB diff; the content list seems to suffer from an offset, and some names are differently chopped
<pitti> infinity, Mithrandir: http://people.ubuntu.com/~pitti/tmp/1st-mb.diff.gz that's the diff -y of the first MB; see the offsets; the small diffs in the first KBs don't seem to matter
<pitti> Mithrandir: any chance we can build the amd64 image on an amd64 box, to finally get flight-6 out of the door?
<Mithrandir> pitti: as in, technically?  Yes.  As in "would it make me happy to do it?"  No. :-)
<pitti> Mithrandir: ack :)
<infinity> It would make me more happy to do that than to spend the next day hunting this bug while everyone else whines about the archive being stalled. :/
<Mithrandir> pitti: but yes, the freeze is getting really painful.
<Kamion> pitti: what am I looking for in 1st-mb.diff?
<pitti> Mithrandir: so let's build that image and give it full installation test
<Kamion> don't think I've ever used diff -y before
<pitti> Kamion: I just wanted to check whether there are any remarkable offsets, and apparently there are
<Kamion> pitti: whereabouts?
<pitti> Kamion: that's the xxd diff between the first MB of little's and my re-mkisofs'ed amd64 install CD
<pitti> Kamion: scroll down to a800
<Mithrandir> Kamion: how unhappy would you be with building on pitti's or my machine and using that as the amd64 flight-6?
<Kamion> ah, right
<Kamion> Mithrandir: we've not done that since sounder-1 ;-)
<pitti> a8000 even
<Kamion> Mithrandir: if it's a straight re-mkisofs that then gets rsynced back to little, I could just about live with it, as long as we get it fixed before flight-7
<Mithrandir> Kamion: yes, it would be something I spend the rest of my day tracking down.
<Mithrandir> pitti: can you sync to chinstrap or little or something?
<pitti> Mithrandir: sync what?
<pitti> Mithrandir: my rebuilt image?
<Mithrandir> pitti: a pure re-mkisofs-ed image
<Kamion> with little's volume label ('Ubuntu 6.06 amd64')
<pitti> yep, just fixed that, rebuilding
<pitti> but I only checked that it boots, I didn't try to install it
<ogra> hmm, still no flight 6 ? did you wait for me to come back ? 
<Mithrandir> ogra: read scrollback.
<ogra> just doing that
<Kamion> pitti: um, does your tree contain .disk?
<pitti> Mithrandir: can we do that on ronne, maybe? rsyncing from here would take ages
<pitti> Kamion: no, it doesn't
<Mithrandir> pitti: sure.  Can you get the tools installed and do it?
<Kamion> pitti: why not?
<Kamion> (that's a fatal bug, btw)
<pitti> Kamion: just because cp -a didn't catch it..., sorry
<ogra> hmm, weird ...
<Kamion> pitti: that will certainly cause a fair bit of that diff
<Mithrandir> nuking .disk gives me the same bootoffs as you get.
<Kamion> right, so it would be good to see a diff between little's image and a re-mkisofs'd image that does contain all the right files
<pitti> yep, doing that now
<pitti> any other hidden files I need to watch out for?
<Kamion> just do a cp -a of the whole tree
<Mithrandir> I'm afraid we're chasing a red herring here.. but I'm testing it.
<Kamion> rather than *
<lucas> are there some plans to rebuild the whole archive before dapper release ?
<Mithrandir> lucas: as in test rebuild?  Yes, afaik.
<Kamion> lucas: test-rebuild, yes; not a rebuild that goes out to mirrors though
<lucas> for some packages, the last build was done on warty
<Kamion> lucas: so?
<lucas> will the results be listed on launchpad ?
<infinity> pitti: Yeah, always cp -a on the mountpoint, rather than in it.
<Kamion> if it hasn't been uploaded since warty, then that's when the last build will have happened; we don't make mirrors download extra stuff just for the fun of it
<lucas> I'm not _that_ confident that they still build ;)
<Kamion> we've done test-rebuilds since warty, and fixed problems arising from them
<Kamion> they should at least have built successfully on breezy
<infinity> lucas: A test build will be done very soon.
<lucas> ok
<infinity> lucas: But, as Kamion said, we did test rebuilds during the breezy cycle too, old souces aren't allowed to bitrot.
<Kamion> anything that hasn't needed an upload from warty to breezy probably isn't part of any complicated changes
<Kamion> stuff that uses libc and nothing else doesn't tend to bitrot that much, e.g.
<lucas> and what's the proper way to trigger rebuilds for packages which are listed as FTBFS on LP ?
<infinity> (except when it does)
<infinity> lucas: By asking me.
<lucas> ok
<infinity> lucas: And I will often look at the log, say "there's no way that will build", and ask you to fix it instead of asking for rebuilds. :)
<pitti> Kamion: http://people.ubuntu.com/~pitti/tmp/1st-mb.diff.gz updated; it's not really smaller than before, though
<lucas> will the test rebuilds hit the build logs on launchpad ?
<infinity> lucas: No, the test rebuild will end up logged to people.ubuntu.com this time around.  During dapper+1, the testruns may be fully integrated into LP.
<lucas> ok
<pitti> Mithrandir: burning clean re-mkisofs'ed image now (with all hidden files), will test that
<Mithrandir> pitti: well, removing .disk makes the image boot for me.
<pitti> Mithrandir: ok, so if it's .disk, my current image shouldn't boot then; let's check that
<pitti> hm, I need to wait for that 0328 install image rsync, it's at 91%
* ogra doesnt understand why he has no problems with the edubuntu images
<pitti> ogra: it's a really weird error, we have it at least since breezy
<pitti> ah, there, finished
* pitti tries to boot, brb
<ogra> pitti, ah,  but it doesnt show up in edubuntu for me, amd64 boots fine ...
<ogra> hm
<Mithrandir> ogra: yes, and?  This seems hardware-dependent
<ogra> ah, k
<infinity> It's also really, really sketchy and rare, it seems.
<infinity> Curious that we've found a fileset that triggers it.
<Mithrandir> hmm, when I actually renamed the directory tree to CD1 (so the -sort option is used), that fixes it.
<infinity> pitti: Verdict?
<pitti> Mithrandir: confirmed, re-mkisofs'ing *with* .disk breaks booting
<Mithrandir> pitti: can you rename your new-amd64 to CD1 and retry?
<Mithrandir> (with -sort)
<Mithrandir> that fixes it for me, which is really, really odd.
<infinity> Mithrandir: But then, it should work on little, no?
<infinity> Mithrandir: Cause little does build with the correct tree, I hope.
<Mithrandir> infinity: yes, it should.
<Mithrandir> infinity: which is why I go "wtf?"
<Kamion> suggests that having .disk earlier than isolinux in the image causes breakage
<Mithrandir> Kamion: botoff is 94a 2378 with -sort, so yes.
<infinity> Kamion: This does not surprise, really, but Mithrandir's using the same weights file as little's last run, afaiu.
<Kamion> or, no, that having the extra directory entry for .disk causes it
<Kamion> infinity: many files don't have explicit weights
<Kamion> and directory entries themselves aren't covered by -sort; they always go at the start
<infinity> Erm, but wait.
<infinity> Mithrandir's working build (out of CD1) had .disk, no?
<infinity> Mithrandir: ?
<Kamion> I'm going through pitti's diff trying to justify each entry
<Mithrandir> infinity: yes.
<pitti> Mithrandir: uh, that new-amd64 name makes it to the CD actually?
<Kamion> pitti: no, the problem is that the weights file includes 'CD1'
<infinity> Kamion: So, yeah.  Applying the weights fixed Mithrandir's image, even with .disk intact.
<Kamion> so you either have to sed it, or rename the directory
<Mithrandir> pitti: no, but the -sort file has CD1 in it.
<Kamion> infinity: well, it seems clear-ish that there's some architecture-dependent issue with the build machine, so ...
<Mithrandir> Kamion: I'm testing on i386.
* Kamion is going through pitti's diff trying to justify each discrepancy
<pitti> LANG=C mkisofs -r -V 'Ubuntu 6.06 amd64' -o dapper-install-amd64 -cache-inodes -J -l -b isolinux/isolinux.bin -c isolinux/boot.cat -no-emul-boot -boot-load-size 4 -boot-info-table -sort 1.weights CD1/
<Kamion> Mithrandir: what version of mkisofs?
<infinity> pitti: Indeed.
<Mithrandir> Kamion: dapper's
<Kamion> ...
<Kamion> COSMIC RAYS
<Mithrandir> aka 2.01+01a01-4ubuntu4
<infinity> Note that little isn't running dapper's version (unless you have it unpackes elsewhere)
<infinity> But it should be close enough.
<infinity> s/unpackes/unpacked/
<Kamion> is too
<Kamion> hi  mkisofs                  2.01+01a01-4ubuntu4      Creates ISO-9660 CD-ROM filesystem images
* infinity scratches his head.
<pitti> dapper and breezy differ only by the JTE patch
<Kamion> hmm, hang on a sec
<infinity> Oh, no.  That was me being confused by pitti earlier. :)
<Kamion> little's currently using a patched version that I put together to try to get Intel Macs working
<Kamion> but the patch should only affect HFS hybrid images
<Mithrandir> Kamion: when did you do that change?
<Kamion> March 23
<pitti> NB that we had this issue for kubuntu breezy already, and we can reproduce it with dapper's mkisofs, so the mactel patch shouldn't hurt
<Kamion> http://people.ubuntu.com/~cjwatson/tmp/31_hfs_bless_file.dpatch if you're curious
<Kamion> since that doesn't actually work, I'll go back to using the system mkisofs
<Mithrandir> pitti: true, so mkisofs doesn't seem to be at blame here.
<Kamion> pitti: can we actually reproduce it? I thought that turned out to be due to new-amd64 vs. CD1
<Mithrandir> hmm, no, true.
<Kamion> let me rebuild on little with the system mkisofs
<Kamion> if that fixes it then my brain hurts
<pitti> Kamion: I'm currently burning with above command, with CD1 and exact label, let's see whether it works
<Kamion> because then it must be due to a miscompile in my dapper chroot at home
<Kamion> which is, uh, scary
* Kamion makes the URL above actually world-readable
<Mithrandir> Kamion: have you rebuilt?
<Kinnison> Mithrandir: How's F6 going?
<Mithrandir> Kinnison: we're still wrestling with the "can't boot" problems.
<Kinnison> Mithrandir: Anything I can do to help?
<Mithrandir> Kinnison: if you can do install testing, try espresso installs on the arches you have?
<Kamion> Mithrandir: yes
<Kinnison> Mithrandir: I can certainly do that
<Kinnison> Mithrandir: which image should I download?
<Mithrandir> Kinnison: the live one
<Kamion> daily-live/current/, pick your architecture
<Mithrandir> Kinnison: (daily-live/current/)
<Mithrandir> Kamion: still no boot.
<Kinnison> righty
* Kinnison wasn't sure if f6 was being staged elsewhere
<Mithrandir> Kamion: http://err.no/tmp/typescript is a script(1) run of what I did to make a bootable one.
<Mithrandir> Kamion: do you want to take a look at the generated image?
<Kamion> hmm, I wonder if the difference is due to jigdo
<Kamion> let me do that mkisofs logging thing
* pitti tests March 28 image and a purely regenerated one with s/new-amd64/CD1/
<pitti> brb
<mantas_> Hello all
<Mithrandir> hmm, removing boot.cat didn't help either.  I'm kinda running out of ideas.
<Mithrandir> pitti: any luck?
<pitti> Mithrandir: so, March 28 image boots fine, the currenly regenerated one doesn't (with CD1 directory name)
<Mithrandir> pitti: hmm.  Can you verify that you built it the same was as I did in http://err.no/tmp/typescript ?
<pitti> Mithrandir: I used s/Ubuntu 6.04 amd64 Bin-1/Ubuntu 6.06 amd64/, but that shouldn't hurt
<pitti> Mithrandir: yep, I used the same
<pitti> Mithrandir: that didn't boot for me; did it for you?
<Mithrandir> pitti: yes.
<Harti> hello
<Harti> when comes flight-6? *impantiently* :)
<Mithrandir> Harti: when we manage to fix the amd64 boot problem
<Mithrandir> as you would have guessed if you'd read scrollback
<Harti> Mithrandir: ah, ok
<pitti> Mithrandir: ah, and instead of fixing permissions, I used sudo mkisofs
<Mithrandir> pitti: retrying with sudo.  Not that I think it matters.
<pitti> so, after these experiments, is Kamion's theory about file ordering the most plausible one so far?
<pitti> hm, but why did the March 28 image boot then...
<Mithrandir> because _some_ file ordering changed.  Somewhere.
<Mithrandir> though, I would think that the +1 and +2 the we give should be enough
* Kamion is trying runs with and without jigdo
<Mithrandir> Kamion: hmm, why isn't the isolinux directory inside the CD1 directory (/srv/cdimage.no-name-yet.com/scratch/ubuntu/daily/tmp/dapper-amd64) ?
<Kamion> hmm, not clear, there are pretty big differences either way
<Kamion> Mithrandir: so that it can easily be -jigdo-exclude'd
<Kamion> it's in boot1
<Riddell> doko_: did you update ia32-libs-kde?
<Mithrandir> Kamion: ah, ok
<Mithrandir> Kamion: bingo, I think I know what it is.  Change CD1 to boot1 in 1.weights.
<Kamion> ah-HAH
<Kamion> a very good point
<Mithrandir> I _should_ be able to duplicate the failure here now; burning DVD.
<Mithrandir> pitti: I have no idea how you manage to make it fail, though
<Mithrandir> Kamion: you're fixing and remaking the ISOs?
<Kamion> yes
<Mithrandir> excellent. :-)
<Mithrandir> I wonder how this used to work, though.
<Mithrandir> did it work by pure chance?
<Mithrandir> if so, slightly scary.
<doko_> Riddell: did prepare it, package is on ronne
<infinity> We're awfully good at pure chance sometimes. :/
<Mithrandir> infinity: well, we've been building on little for how long?  A year and a half?
<infinity> Yeah, but the bug is obviously intermittent.
<Kamion> nearly two years
<infinity> Depends pretty crucially on CD contents du jour.
<Mithrandir> it's been _very_ consistent over the last few days.
<Mithrandir> but yeah.
<Kamion> I still have no real idea why it fails
<infinity> pitti claims it happened once on kubuntu/amd64/breezy
<pitti> yep, but we didn't investigate it that time
<Kamion> I don't get why just having isolinux.bin a bit earlier on the CD makes a difference
<pitti> AFAIK someone else had it too
<Mithrandir> Kamion: it shouldn't, but it does.  Apparently.
<Riddell> I suspect pitti's old problem with kubuntu CDs is unrelated
<infinity> Kamion: TBH, I'm not sure I want to know why, if this fixes it.
<pitti> Riddell: entirely possible
<Mithrandir> so now we "just" need to regenerate amd64 ISOs for edubuntu and kubuntu and get those tested too.
<Riddell> I've never had a problem with amd64 CDs until 2 days ago
<Mithrandir> Riddell: have you tested the kubuntu i386 and ppc images?
<Kamion> infinity: me neither
<Kamion> amd64/install regenerated
<ogra> Mithrandir, i'm not sure i need a whole new set, Riddell uploaded new kdelibs
<ogra> s/i'm not sure/i'm not sure but i think/
<Mithrandir> ogra: you need new amd64 ones, at least.
<ogra> yep, thats clear
<Mithrandir> if you want i386 and ppc, I can make you those.
<Kamion> sounds like we need new kubuntu as well then
<Kamion> ?
<ogra> yep
<Mithrandir> at least amd64, yes.
<Riddell> yes, remake all kubuntu ones please
<Mithrandir> Riddell: you wanted a full kubuntu set because of new KDE or something?
<Kamion> across the board, if there are important changes in kdelibs
<Mithrandir> ok
<Kamion> I'll start rebuilding
<Mithrandir> thanks
<ogra> Mithrandir, full set for me as well pleas
<pitti> Kamion:  20060331.1 should be good now?
<Riddell> it wasn't a major change, but may as well be consistent
<Kamion> ogra: will do in a bit
<ogra> or Kamion... woever does it
<Kamion> pitti: whatever current is ...
<pitti> Kamion: yep, that one
<Kamion> yeah, 20060331.1
<ogra> it think i'll also need a new livefs because of kdelibs
<Mithrandir> ogra: ok, I'll spin you new livefs-es.
<ogra> thanks :)
<Kaloz> 'lo :)
<ogra> i can care for the isos myself if somebody notifies me if little is free
<pitti> meh, new OO.o packages...
<ogra> (for live)
<Kamion> easy for me to do them while I'm logged in anyway
<ogra> ok
<Mithrandir> Kamion,Kinnison: I think I forgot to actually make new live images for ubuntu yesterday, so we might want to do those.
<Kaloz> Mithrandir: did You have any luck with squashfs-lzma? Or do I remember wrong and someone else was about to play with it?
<Kamion> Mithrandir: livefs or CD?
<Mithrandir> Kaloz: I didn't actually get around to fully testing it, I'm afraid.
<Mithrandir> Kamion: CD.
<Kamion> I'll do those as well then
<Mithrandir> thanks again
<Kinnison> okay, once they're done, yell so I can rsync down the changes
<Kaloz> Mithrandir: so it will be dapper+1, I see.. I will try to get some free time and help in it
<Mithrandir> Kinnison: sorry about not remembering that. :-(
<Mithrandir> Kaloz: I'm a bit worried about the compatibility issues since iirc squashfs doesn't have a way to know which compression scheme is used.
<ogra> wow, i just ran out of diskspace... cleaned my evo trash, now i got 1G free space ... impressing, i run this laptop only since january...
<Kinnison> Mithrandir: not a problem
<Kamion> amd64/install current boots for me
<Kamion> (woo)
<Kinnison> Mithrandir: I don't have a huge pipe, but 2Mb is enough to rsync a days changes in not too long
<Kinnison> Kamion: rock on
<pitti> Kamion: rock 
<ogra> yay
<Mithrandir> Riddell: do you want new livefs-es as well?
<Mithrandir> Kamion: yay.  I'll do a full install test.
* pitti taps foot while jigdo'ing down the new OOo debs
<Kaloz> Mithrandir: well, we simply don;t use the other :p but honestly, I see no big deal supporting only lzma on it
<Kamion> --r--r--r--   1    0    0            2048 Mar 31 2006 [   2378 00]   boot.cat
<Kamion> +-r--r--r--   1    0    0            2048 Mar 31 2006 [   2385 00]   boot.cat
<Kamion> --r--r--r--   1    0    0           12720 Mar 16 2006 [   2379 00]   isolinux.bin
<Kamion> +-r--r--r--   1    0    0           12720 Mar 16 2006 [   2378 00]   isolinux.bin
<Kamion> ^-- isoinfo -lR differences
<Kamion> so apparently isolinux.bin *must* come before boot.cat
<Mithrandir> Kamion: evil.
<Kamion> (the bit inside []  is the ISO9660 extent number)
<infinity> Bizarre.
<Riddell> Mithrandir: sure
<Kamion> (dunno what the 00 bit is, don't immediately care)
* Kamion does an install test while he's here
<Mithrandir> infinity: did you get around to adding progress information to mksquashfs?
<Kinnison> does the live cd disable readahead?
<Mithrandir> yes
<Mithrandir> it ended up giving me worse performance and triggered loads of bugs in squashfs/unionfs.
<ogra> Mithrandir, did you get a chance to look at my login problem on the livecd ?
<ogra> anything i can do to help debugging it ? 
<Mithrandir> ogra: what login problem?
<Mithrandir> IOW, no
<ogra> Mithrandir, before i left on wednesday ..
<infinity> Mithrandir: No, but if you file a bug and assign it to me, I will.
<ogra> th eedubuntu livecd drops me to a gdm login 
<ogra> logging in with "ubuntu" and no password works flawless though
<Mithrandir> ogra: oh, you're doing evil stuff with the gdm.conf, aren't you?
<ogra> Mithrandir, nope, i use gdm-cdd.conf now 
<ogra> sinc our gdm supports cdd changes now
<pitti> alright, will do amd64 test installation now
<Mithrandir> ogra: well.  That's evil.  Casper doesn't touch gdm-cdd.conf, it touches gdm.conf.
<ogra> Mithrandir, thats bad 
<ogra> gdm-cdd.conf is the way for derivatives now
<Mithrandir> nobody has told me about that.  File a bug.
<ogra> where is the code for that, so i can send you a patch 
<Mithrandir> in the casper package.
<ogra> ok
* ogra looks
<Mithrandir> the .bzr directory is in there too
<Kamion> Riddell: new Kubuntu install CDs up
<Kamion> rebuilding Edubuntu
<ogra> Mithrandir, http://people.ubuntu.com/~ogra/casper.diff
<ogra> ok like that ? 
<ogra> err
<Mithrandir> ogra: given that you have syntax errors in it, no. :-P
<ogra> Mithrandir, yes, just discovered :)
<Mithrandir> ogra: please, just file a bug.  It's trivial, so no need to give me a patch.
<ogra> fixed
<Mithrandir> I want the bug so I don't forget, it's not that I don't know how to do it.
<ogra> ok, i wanted to not put the workload on you
<pitti> Mithrandir: CD boots, yay. test-install running
<Mithrandir> pitti: excellent. :-)
<ogra> Mithrandir, bug 37467 for you :)
<Ubugtu> Malone bug 37467 in casper "needs to respect gdm-cdd.conf for derivatives" [Normal,Unconfirmed]  http://launchpad.net/bugs/37467
<lucas> I have a strange build failure for libgpgme-ruby on amd64
<lucas> https://launchpad.net/+builds/+build/180323
<lucas> it's marked MANUALDEPWAIT, and it seems it can't find ruby1.9 and ruby1.9-dev
<lucas> however, according to https://launchpad.net/distros/ubuntu/+source/ruby1.9/1.9.0+20050921-1, it's available
<lucas> infinity / Kamion , any ideas ?
<Mithrandir> ok, edubuntu livefs-es done
<ogra> oki ...
<Mithrandir> ogra: don't start the live image builds please
<Mithrandir> Kamion: can I do the live ubuntu builds on little now?
<ogra> i wont, Kamion wanted to do them all
<Kamion> Mithrandir: go ahead
<Kamion> I'll let you do all the live builds then
<Mithrandir> sure
<Kamion> ogra: Edubuntu install CDs done
<ogra> thanks
<Mithrandir> Kamion: we wanted ports too?
<Kamion> Mithrandir: yeah
<infinity> Looks like ruby1.9 was removed on amd64... WTF?
<mantas_> I wanna talk about ppp/pppoe connections configuration in Ubuntu Dapper. Are there any ubuntu developers, who are resposible for this ?
<infinity> Kinnison: A moment?
<neuralis> mantas_: do you have a question about how to use the functionality, or are you requesting new functionality for dapper?
<Mithrandir> doko_: you broke kubuntu-desktop, you know?
<neuralis> mantas_: the former belongs in #ubuntu, the latter won't happen in this version, but your best bet is to either file bugs or write a spec for dapper+1.
<Kinnison> infinity: sure
<Kinnison> infinity: here, or elsewhere?
<infinity> Kinnison: Here is fine.
<infinity> Kinnison: https://launchpad.net/distros/ubuntu/+source/ruby1.9/1.9.0+20050921-1
<infinity> Kinnison: If I'm reading that right, it claims to be published on all arches, yes?
<Mithrandir> ok, amd64 ubuntu install seems good.
<infinity> Kinnison: The amd64 binaries don't seem to exist in the Packages file.
<Kinnison> it certainly claims to be built on all arches
<doko_> Mithrandir: I asked if the archive was still frozen and if I could upload a fix
<Kinnison> and the amd64 build seems to have been accepted
<infinity> Oh, wait.  Nevermind.
<infinity> Kinnison: Unword.
<mantas_> neuralis, at first I wanna know what is recomended way to configure ppp/pppoe ? Problem is, that I don't see any way to configure PPPoE/ADSL connection in Ubuntu, also I don't see an ability to configure non-standard ppp connection, for example ppp connection for EDGE/GPRS PCMCIA cards (modems)
<infinity> Kinnison: It doesn't build all binaries on amd64.  Feh.
<Treenaks> mantas_: PPP over EDGE/GPRS is just like a normal PPP connection, except with the 'phone number' *99#
<Kamion> 09:34 < doko_> infinity, Mithrandir: is the archive still froozen?
<Kamion> 09:34 < Mithrandir> doko_: yes
<Kamion> you asked if it was frozen; you were told it was
<Treenaks> mantas_: and those PCMCIA cards are just serial ports, afaik?
<infinity> lucas: Look closer.  ruby1.9 and ruby1.9-dev only build on i386 and powerpc (for whatever reason)
<mantas_> Treenaks, yes, I can configure EDGE/GRPS connection with text mode tool - pppconfig, but not with network-admin. Should I report a bug about this ?
<infinity> No, wait again.  WTF?
<lucas> it's listed as Successfully built on LP
<lucas> but there's no build log for it
* infinity pokes harder.
<infinity> Oh, there I go looking at ports.  Silly me.
<doko_> <doko_> no, just making openoffice.org-kde installable again, by an ia32-libs-kde upload
<infinity> lucas: Check the "resulting binaries" part.
<doko_> Kamion: ^^^
<Kamion> that wasn't a question, that was a statement
<infinity> lucas: amd64 only builds some binaries.
<Kamion> busy people will miss that
<infinity> lucas: Not ruby1.9{,-dev}
<lucas> ah
<lucas> so it shouldn't be "Successfully built"
<infinity> lucas: Why not?
<Kamion> doko_: go ahead and upload the fix now, might as well
<infinity> lucas: The source package only builds some binaries on some arches.
<lucas> because it only built some binpkg
<infinity> lucas: This is perfectly common.
<lucas> mmh
<infinity> lucas: The build didn't fail, it just doesn't build everything everywhere.
<lucas> ok
<infinity> lucas: Look at the source package to find out why, I have no idea.
<lucas> doing that now, ok
<lucas> thank you
<lucas> ruby1.9-dev is Arch: any
<lucas> all binpkg in ruby1.9 are either arch:any or arch: all
* infinity has proven to himself that he needs to stop working and start eating/sleeping.
<lucas> the only packages that were built on amd64 are those which are arch: all
<Mithrandir> ok, ubuntu live images are done.  Go wild and test them
<Mithrandir> Kinnison: ^^
<doko_> Kamion: done
<infinity> OH!
<Kamion> thank you
<infinity> This /is/ a Kinnison bug.
<infinity> Kinnison: re-ping.
<mantas_> doko_, Hi, I've backported openoffice.org 2.0.2 to Ubuntu Breezy ;) do you wanna my changes ?
<Kinnison> infinity: yes?
<infinity> Kinnison: gins eats kittens.  God unimpressed.
<infinity> s/gins/gina/
<Kinnison> gina has had nothing to do with ubuntu in months
<infinity> Kinnison: Source packages that general arch:all and arch:any binaries that were out of date when gina ran appear to be "successfully built" in soyuz.
<doko_> mantas_: did you rename the packages back using the *2 suffix?
<infinity> s/general/generate/
<infinity> Kinnison: Yes, this is from ages ago.  Never caught until now.
<infinity> Kinnison: https://launchpad.net/+builds/+build/125937
<infinity> Kinnison: Those are all "arch:all" packages listed there...
<infinity> Kinnison: So, why is that "successful" on amd64?
<Kinnison> infinity: urgh
<Kinnison> infinity: at this point, a -2 with the changelog "Gina eats kittens, God unimpressed" may be necessary
<infinity> Kinnison: That does seem likely, yes.  I'm just wondering how many other kittens may have been lost.  Oh well.
<infinity> Anyhow, a new uplod will make the current state more obvious, but of course won't fix the fact that ruby1.9 is FTBFS on amd64. :)
<infinity> lucas: Either way, you're screwed. :)
<mantas_> doko_, no, just patched debian/rules, debian/control and some other files to get working with gcc/gcj 4.0 and older version of some libraries
<Kamion> infinity: this should show up in a quinn-diff run, shouldn't it?
<infinity> lucas: But if you could do a no-change upload of ruby1.9, so launchpad starts reporting on it correctly, that would be nice.
<infinity> Kamion: Yeah, it should.  I haven't yet done one for universe.
<lucas> infinity: wouldn't just re-triggering a build be enough ?
<infinity> lucas: Due to some LP hilarity, you can't retrigger a build if it thinks the package has already been successfully built.
<lucas> oh ok
<lucas> I'll first see if the ftbfs is not fixed in debian
<infinity> Kamion: I got so far as copying a quinn-diff binary to ~adconrad on drescher, then found something shinier to play with, I think. :)
<infinity> lucas: It doesn't look fixed.  Debian's amd64 packages are lagging.
<Mithrandir> infinity: aka "food"? :-P
<infinity> No, food is about to happen now.
<mantas_> neuralis, Treenaks: so, what about PPP/PPPoE configuration in Dapper ? Should I report a bug agains network admin or there are some other tools in Ubuntu main for PPP/PPPoE configuration ?
<infinity> Finally.
<lucas> infinity: there was a similar problem with ruby1.8 I think
<Mithrandir> yeah, ruby in debian is 1.9.0+20050623-2 for the amd64 build.
<infinity> mantas_: The recommended way to configure PPPoE is (currently) the "pppoeconf" tool from the command line.  Works well.
<doko_> mantas_: yes, please email, started the backport as well, but it's low priority for me
<mantas_> infinity, there are no way to call pppoe configuration tool without typing pppoeconf command in terminal ? I think this is big usability bug
<ogra> i think there are seveal open bugs about it since warty
<infinity> mantas_: Yes, but we're not about to fix it now.
<infinity> mantas_: If you'd like to hack on NetworkManager to support PPP and PPPoE in a Debian context, we'll happily take patches for dapper+1
<Mithrandir> pitti: any chance you could test ppc live?
<pitti> Mithrandir: sure, I will; as soon as my amd64 install finished (sorry, it hang at the X resolution question while I was at lunch)
<pitti> Mithrandir: yesterday's was good, any particular changes I should watch out for? or just general test?
<Mithrandir> pitti: espresso testing is needed too, which I don't think was ok?
<Mithrandir> ogra: edubuntu live images done
<pitti> Mithrandir: yep, will test
<mantas_> infinity, maybe there are some plans/specifications about this ? What are future Ubuntu plans about PPP/PPPoE configuration in Dapper +1 ? Maybe I could help :)
<Mithrandir> Kamion: we don't do edubuntu/kubuntu ports too, do we?
<ogra> Mithrandir, thanks ... i'm not sure if i want them for a flight on this state though
<Kamion> Mithrandir: no
<ogra> s/on/in/
<Mithrandir> Kamion: so just bin/cron.ports_daily{,-live} with no for-project or anything?
<Kamion> pitti: if you didn't see, your espresso bugs appeared to be due to libparted not liking one of your partitions
<Mithrandir> ogra: that's your call.
<Kamion> Mithrandir: 'for-project ubuntu' is a no-op, otherwise yes
<Mithrandir> ogra: I would advise you to take them and document the login problem in the errata, but again, your call
<pitti> Kamion: no, I didn't read my bug mail yet today; nice that it's fixed now (and funny that it affected both of my boxes and nobody else's)
<ogra> Mithrandir, yes, i'm still pondering that 
<Mithrandir> ogra: you can still get useful testing out of it.
<ogra> given that the new NM doesnt work on *any* card over here...
<ogra> so no networking and no autologin ...
<pitti> ogra: NM-> not even for wired?
<ogra> pitti, didnt try with wired
<ogra> will do in this test run 
<pitti> ogra: it works well here with both the AE (modulo the initial dhcp timeout) and with ethernet
<ogra> pitti, the current 0.6.X ?
<infinity> ogra: When did you last test it?
<ogra> infinity, wednesday afternoon
<infinity> ogra: You may have been suffering from "no wpasupplicant available" issues, if it was an old livefs.
<pitti> ogra: I think I tested it with 0.6, too, will do again to check it
<infinity> ogra: Your new livefs should have wpasupplicant installed, so it should work.
<ogra> infinity, i think it had thw wpasupplicant already
<ogra> it was the second build on wednesday that was specifically waiting for wpasupplicantr
<ogra> -r
<ogra> so that should have been there ...
* ogra looks at the old iso
<mantas_> btw, it seems Ubuntu dapper has outdated network-manager version, bugfix version 0.6.2 was released some time ago, in lauchpad there are bug about this in network-manager section 
<Kamion> pitti: it's not fixed
<infinity> mantas_: We know.
<Kamion> merely diagnosed
<mantas_> are there any plans to include network-manager 0.6.2 in Dapper or not ? I'm asking, because I don't know which version would be better to backport for Breezy
<Kamion> mantas_: yes, it will probably be upgraded.
<j^> mantas_ currently no version is in a state that it could/should be backported
<ogra> backporting it will likely also require new dbus, hal etc ...
<ogra> (or a lot of hacking)
<ogra> hmm
<ogra> edubuntu-daily-live-20060329.log  has a +wpasupplicant
<ogra> edubuntu-daily-live-20060329.1.log  has a -wpasupplicant
<giftnudel> hehe
<ogra> thats strange 
<ogra> hmm, and i see no log for edubuntu-daily-live-20060331
<j^> ogra possible that you run into bug 37396 or bug 37419 if wireless does not work
<Ubugtu> Malone bug 37396 in network-manager "orinoco/prism54 cannot connect to WEP networks" [Critical,Confirmed]  http://launchpad.net/bugs/37396
<Ubugtu> Malone bug 37419 in network-manager "ndiswrapper. cannot connect to unencrypted networks" [Critical,Confirmed]  http://launchpad.net/bugs/37419
<ogra> j^, what about the other cards then (2x broadcom 1x iwp2200)
<ogra> i dont use ndiswrapper btw
<ogra> i think the cd buildlog indicates that wpasupplicant was removed in 20060329.1, i just dont understand why 
<j^> ogra without wpasupplicant it will not work
<ogra> j^, i know ... the 20060329.1 build was specifically done to *add* wpasupplicant, thats what bothers me
<mantas_> j^, network-manager is very buggy now ?
<thesaltydog> How can I add an override to this lintian warning: W: bum: menu-command-not-in-package /usr/share/menu/bum:4 /usr/bin/gksu
<j^> mantas_ right now its broken
<mantas_> ogra, network manager 0.6.x will not work with breezy dbus and hal ?
<ogra> hmm, network-manager depends on wpasupplicant now it seems ... 
<ogra> why was it removed from that build ... strange strange 
<giftnudel> ah, when I scroll in firefox and someone says something in this channel, it will get focus
<ogra> mantas_, no idea, but its very likely that you need a newer version 
<j^> is madwifi or madwifi-ng in dapper?
<mantas_> j^, very broken ? which bugs ?
<j^> mantas_ https://launchpad.net/distros/ubuntu/+source/network-manager/+bugs
<mantas_> j^, thanks, yesterday I looked there, but didn't noticed critical bug ;)
<pitti> Mithrandir: amd64 install works fine here, I tested some desktop stuff, too
<Mithrandir> pitti: nice, thanks.
<Kamion> ogra: it's weird, but I'd ignore it if I were you, tasks aren't really relevant for live builds any more
<Kamion> thesaltydog: there's documentation on lintian overrides in the manual in /usr/share/doc/lintian/
<Kamion> section 2.4
<thesaltydog> Kamion, yes, tnx. While waiting for a reply, I found it!
<Kamion> thesaltydog: but I wouldn't override that warning
<thesaltydog> Kamion, ??? it is complaining for gksu...
<Kamion> thesaltydog: I think it's probably a lintian bug, since gksu's used all over the place; it should recognise gksu and check (a) for a dependency and (b) that the thing after gksu is in your package
<Kamion> thesaltydog: so please don't override it
<thesaltydog> Kamion, ok. I won't override it. gksu is in package's dependecies...
<Kamion> sure, but lintian should still check for that
<Kamion> I'll file a bug
<thesaltydog> Kamion, I could post a bug on lintian...
<Kamion> I'll do it, I'm one of the lintian developers (although kinda retired)
<thesaltydog> Kamion, ok. Thank you very much!
<sabdfl> phwoar. just used the volume buttons on my thinkpad. and got on-screen display. phwoar.
<sabdfl> mjg59: ^^^
<sabdfl> :-D
<thesaltydog> sabdfl, very nice the new hotkeys-setup..
<thesaltydog> sabdfl, I finally ended my troubles with tpb on my ThinkPad
<Kamion> bug filed
<thesaltydog> Kamion, great.
<thesaltydog> Kamion, by the way... the thing after gksu is bum, the package itself.
* mvo misses his tpb
* mvo used to have a terminal on his thinkpad key, but that no longer works with the hotkey stuff in gnome
<seb128> GNOME stuff didn't change recently
<seb128> so go blame something else :p
<torkel> mvo: I miss tpb too... 
<Kamion> thesaltydog: right, as I'd expect
<Kamion> thesaltydog: so lintian should check to make sure that the command you give after gksu is in the package it's checking
<thesaltydog> right
<torkel> mvo: especially that I can't change the hw volume of my T40p without changing the "alsa" volume 
<Mithrandir> yay, amd64 espresso and live works.
<Mithrandir> pitti: you're testing ppc espresso?
<pitti> Mithrandir: rsync is at 83%
<Mithrandir> pitti: 'k
<pitti> Mithrandir: but since that libgparted bug is not yet fixed, I doubt that espresso will work 
<Kamion> libparted
<Kamion> and it's at least possible that it's a bug in your partitions :-)
<mvo> seb128: I blame hotkey-setup
<pitti> Kamion: hm, I don't even have any ext2 partition (on neither computer)
<pitti> Kamion: I have reiserfs and xfs, and hfsplus on the Apple
<pitti> Kamion: I think I created an ext3 partition for the to-be-installed system (since that happens to be the default and I can't change it anyway)
<pitti> so this is still strange...
<Kamion> pitti: odd, yes
<Kamion> I haven't had time to really dig yet :(
<pitti> Kamion: no problem; if I knew a way to work around that, I'd happily take it
<pitti> Kamion: so the reason for the early exit is that partman exits with 10 instead of 0?
<pitti> Kamion: since I didn't see any exception or so
<mantas_> Kamion, ~3 monts ago you added ttf-dejavu font to ubuntu-desktop metapackage, but it seems forgot to remove ttf-bitstream-vera (ttf-dejavu are the same bitstream-vera fonts, just extended with more unicode characters, look at http://dejavu.sf.net ). Should I report a bug about this ?
<jdub> mantas_: the inclusion of vera is intentional
<Kamion> mantas_: I just did an auto-refresh, I did not particularly care about why ttf-dejavu was added and have no idea about anything related to your question
<mantas_> Kamion ;)
<Kamion> if you want to know who added it, look at bzr log of the seeds
<Kamion> which was in fact me, but teleoperated by jdub
<Kamion> ('cos he hadn't got a seed commit setup)
<mantas_> Kamion, it's not important who added ttf-dejavu, it's important do not have duplicate fonts in ubuntu-desktop ;)
<Kamion> it's not important to me :)
<jdub> mantas_: it's important to have the vera font name available
<Treenaks> Kamion: duplicate = double disk space ;)
<jdub> mantas_: and the metrics to go with it
* Kamion types /part and then rethinks
<mantas_> jdub, ttf-dejavu fonts could provide ttf-bitstream-vera
<jdub> mantas_: they have different names and metrics
<Mithrandir> ok, i386 live and espresso seems to work for me
<Riddell> Mithrandir: did you remake the kubuntu livefs?
<mantas_> jdub, we can make some aliases and gnome will see vera fonts after ttf-dejavu are installed ;)
<Mithrandir> Riddell: yes, but it broke since doko uploaded some ooo stuff yesterday, so the AMD64 livefs is broken.
<Mithrandir> Riddell: I need to check out if the new ia32-libs-kde is through yet
<jdub> mantas_: a) the fonts are different, whether you alias the name or not, b) the metrics are different
<jdub> mantas_: you can't just swap fonts around, call them different names, and hope for the best
<mantas_> jdub, about metrics - I don't know why ttf-dejavu metrics should be different from ttf-bistream-vera, because ttf-dejavu are made from ttf-bistream-vera
<jdub> mantas_: well, they are
<mantas_> jdub, in any case users now have usability problems, because identifically looking fonts have different names and ttf-bistream-vera fonts has too little characters to use them in Europe
<jdub> mantas_: that's precisely why we're using dejavu as the primary selection for all of the generic aliases
<Riddell> Mithrandir: looks like ia32-libs-kde-5 is in the archive
<mantas_> jdub, so, ttf-dejavu is primary font for Ubuntu Dapper and ttf-bitstream-vera are deprecated, right ?
<jdub> mantas_: i wouldn't describe it as deprecated, but it is included.
<mantas_> ;)
<Kamion> jdub: (see doko's mail today about dejavu problems)
<jdub> Kamion: u-d?
<mantas_> jdub, I understand, that vera fonts are included now, but I think, that this is an usability problem when there are 2 identifically looking (from users view) fonts in the system as default
<Mithrandir> Riddell: indeed.
<Kamion> jdub: think so, just skim-read it
<Mithrandir> Riddell: I'll kick off livefs builds for kubuntu, then
<jdub> mantas_: the way fontconfig works, there are a lot of identical-looking fonts on the system by default (because the empty glyphs fall back to the generic aliases)
<mantas_> jdub, Yes, and this is nor user-friendly, nor professional, so, I think it would be wise to report a bug about removing ttf-bitstream-vera fonts from ubuntu-desktop in future :)
<jdub> mantas_: it happens across *all* the fonts, not just between those two
<mantas_> jdub, you allow me to report a bug ;)
<jdub> mantas_: it is important to keep vera there for metric-compatibility and name-compatibility
<mantas_> jdub, who needs this metric-compatibility ?
<Treenaks> jdub: only for the metric compatibility. names can be mapped.
<Treenaks> mantas_: People who write documents and expect them to be the same across machines/platforms
<jdub> Treenaks: they impact each other
<mantas_> Treenaks, hehe, AFAIK you are talking about msttcorefonts :-P
<pitti> yay sound on ppc live
* pitti hugs Mithrandir 
<Mithrandir> pitti: nice.
<jdub> mantas_: this is important for *every* font a user chooses. most of my presentations would have to be double-checked if the metrics of 'Bistream Vera Sans Bold' changed behind my back.
<Mithrandir> I was wondering for a second why that suddenly worked until I realised I uploaded a fix for it a few days ago.
<pitti> Mithrandir: yep, that manual snd-powermac module loading
<Mithrandir> pitti: yeah, I'm just very, very tired now.
<mantas_> jdub, so, you think ttf-bitsteam-vera fonts should remain in Ubuntu for ages ?
<jdub> mantas_: yes
<mantas_> Even when majority will use other fonts ?
<jdub> yes
<mantas_> ok, I understand your point of view ;)
<Mithrandir> pitti: ok, no I'm just waiting for ppc to be confirmed working before doing the release and mailing u-a
<Mithrandir> maswan: around?
<Mithrandir> Riddell: have you had a chance to do installation testing of flight-6 yet?  I suspect it's broken due to the ia32-libs-kde stuff
<maswan> Mithrandir: yes
<Mithrandir> maswan: ravel seems to be unhappy.
<Mithrandir> as in, ssh times out
<Mithrandir> ogra: are you happy with the current edubuntu images?
<maswan> indeed.
<maswan> I'll go down and poke it, I guess
<Mithrandir> thanks.
<pitti> Mithrandir: ppc/live boot, OO.o, FFox, USB hotplug, sound, help, video, and n-m with ethernet are good
<pitti> Mithrandir: so I'd declare this as good enough
<Riddell> Mithrandir: both amd64 and ppc broke on package install, 386 was fine
<Riddell> probably scratched cds at fault on the ppc at least
<Mithrandir> pitti: excellent.
<pitti> amd64/install chokes on my second ethernet
<pitti> $ sudo ifup eth1
<pitti> run-parts: /etc/network/if-pre-up.d/0_wpasupplicant exited with return code 1
<pitti> but oh well...
<Mithrandir> pitti: hmm.
<Mithrandir> Riddell: ok, so you want new installation images rolled?
<pitti> Mithrandir: it's just for my second ethernet card, actual install and apps are fine
<Riddell> Mithrandir: yeah, please
<siretart> pitti: I have a fix for that ready, I'm just waiting for main to reopen again
<pitti> siretart: cool
<Mithrandir> pitti: ok, I'll just let that pass, then
<siretart> pitti: I just have that package uploaded to unstable. it just needs to be synced
<pitti> Mithrandir: it still hangs after ejecting the CD (pressing enter helps, as usual), but that's no showstopper, I'd say
<infinity> pitti: That should be fixed next week, I suspect.
<fabbione> Mithrandir, infinity: any objection if i upload wacom-tools? it's not on CD atm, and i will wait after F6 to create the proper X depends:
<infinity> fabbione: Go nuts.
<fabbione> i need it to fix a couple of regressions from breezy
<fabbione> infinity: cheers mate...
<infinity> fabbione: If it turns out it IS on a CD, I'll let Mithrandir deal with you. :)
<sladen> Kamion: I don't have Mactel to test it with, is creating an iso and seeing if it will mount as HFS+ in Linux a good enough way to test it
<fabbione> infinity: it's not :)
<Kamion> sladen: yes
<Kamion> sladen: has to not mount as HFS though
<Mithrandir> ogra: prod?
<sladen> Kamion: funky.  Any idea how mactel-linux built their images?  Or do they just have a raw HFS+ filesystem written to a CD?
<Kamion> sladen: they used OS X to help
<ogra> Mithrandir, only did i386 install so far, seems fine
<Kamion> and yeah, raw HFS+
<Mithrandir> ogra: ok, do you want me to wait for you?
<Kamion> sladen: to my knowledge (I looked last week) there is no GNU/Linux code capable of writing to HFS+ usefully
<Kamion> sladen: except for the kernel, which of course requires root access
<ogra> Mithrandir, it will still take 1-2h i guess
<Mithrandir> ogra: that wasn't my question. :-P
<Kamion> sladen: the stuff in the hfsplus package can't do formatting or anything much in the way of writing except for removing files
<Kamion> sladen: mkisofs is where we really need it, so it's probably easiest to do it there
<ogra> Mithrandir, yes please, if it doesnt cause trouble 
<Mithrandir> Kamion: do you have any known bugs about espresso you want to get into the announcement?
<sladen> Mithrandir: when are you actually building the images?
<Mithrandir> sladen: they are already built.  Unless something really nasty pops up.
<sladen> Mithrandir: I have a small fix for LenovoPads that I'd like on them
<Kamion> sladen: also, we need a "bless boot file" option; I tried http://people.ubuntu.com/~cjwatson/tmp/31_hfs_bless_file.dpatch, but turns out that doesn't really work properly with HFS
<sladen> Mithrandir: okay, no problem
<Kamion> it would look somewhat different on HFS+
<Mithrandir> sladen: flights are snapshots, not releases.
<Kamion> Mithrandir: might be worth noting that the manual partitioner still assumes ext3 (will be fixed in Flight 7)
<sladen> Kamion: blessing is an EFI thing rather than a HFS+ thing?  Since the boot file now points at a file, rather than a folder (IIRC)
<Mithrandir> sladen: so while I appreciate the "I'd really like to get this in", if it wasn't there on Wednesday morning, you were too late.
<Kamion> sladen: right
<Mithrandir> Kamion: ok
<Kamion> sladen: well, sort of
<Kamion> sladen: it *is* an HFS+ thing
<Kamion> HFS only really supported blessing a system folder; HFS+ allows blessing a boot file as well
<Kamion> EFI's the first Apple thing to interpret that though
<sladen> Mithrandir: nah, it's not an issue, the X stuff should work out of the box now which is a much bigger issue for people testing them for resale.
<Mithrandir> Kamion: are you aware that when pressing "reboot" after espresso doesn't cause splashdown, etc to happen?
<dholbach> ogra: did you plan to do a gcompris upload anywhere in the not-too-distant future?
<dholbach> ogra: pitti complains that it doesn't have a .pot-file :-)
<Kamion> Mithrandir: yes
<ogra> oh ?
<Kamion> it's on the to-do list :)
<Mithrandir> Kamion: ok. :-)
<ogra> dholbach, i didnt plan changes to gcompris ...
<dholbach> ogra: it's usually just running   cd po/; intltool-update -p   in debian/rules somewhere
<ogra> dholbach, pitti i'm not sure there is a pot file, the ranslations are in separate packages 
<pitti> ogra: oh, in which? I just see -sound-lang files
<ogra> yes, they also have text translations ...
<pitti> ogra: oh, I see; but the source package builds/has .mo files, so there are certainly po files around?
* pitti checks
<pitti> ogra: yep, lots of them
<dholbach> gcompris-sound-de doesnht have translations
<pitti> ogra: so it should be reasonable to build a pot
<pitti> dholbach: pkgstriptranslations
<dholbach> arg.... bitten by the old assumption again :-)
<Mithrandir> Riddell: new dailies up
<stewart> can anyone tell me where dapper picks up its list of available modes for the system > preferences > screen resolution app?
<Mithrandir> stewart: from the X configuration
<stewart> as in /etc/X11/xorg.conf? odd as I have modes available not listed in my conf
<Mithrandir> stewart: sure the colour depth matches?
<stewart> and it ignores the 1900x1080 hdtv mode I just added
<stewart> yep
<Mithrandir> check the log and see if it got removed for some reason or another?
<infinity> Mithrandir: Actually, I don't think it does come from the "X config", per se, but rather from X's detected valid resolutions.
<infinity> Mithrandir: Since my RandR applet has WAY more resolutions listed than my xorg.conf has.
<Mithrandir> infinity: probably, yes.
<stewart> so how would you add new modes?
<infinity> stewart: A mode that X considers invalid shouldn't show in there.  So you should see in you X log that X has decided your custom mode was no good for one reason or another (not enough video RAM to render it, broken video firmware, who knows)
<stewart> colour depth is not available to be set through gnome, its set to 24 by default via my xorg.conf I assume
<sladen> stewart: also, the video BIOS may not know how to setup the mode... eg. 915resolution
<infinity> stewart: If this is an Intel chipset, you may want to try installing 915resolution
<infinity> sladen: Jinx.
<stewart> its an nforce chipset
<Mithrandir> infinity: I have a trivial patch to mksquashfs to print progress information, but it's a tad overzealous for now.
<stewart> with integrated gfmx4 NV18 I believe
<infinity> Mithrandir: One dot for every block? :)
<Mithrandir> infinity: no, for every file.  I was actually writing out the current position
<infinity> Heh.
<infinity> Just make it less granular, and you win.
<Mithrandir> yeah.
<infinity> No one's lookin for an accurate timeline, just ANYTHING VISUAL, ARGH.
<Mithrandir> Every megabyte or so should be fine.
<stewart> thats annoying my log says it drop the mode (no mode of this name)
<stewart> but my monitor and card are good for it and its the new hidef tv format
<sladen> Mithrandir: making output each file name would make sense, much the same as  tar v  
<sladen> Mithrandir: and preferably not by default (unix utilties by default should be quiet
<maswan> Mithrandir: fixed. it seemed to just have lost it's network devices. an ifdown -a; ifup -a later and all is great.
<Mithrandir> Riddell: live images published too.
<Mithrandir> maswan: excellent, thanks
<Riddell> thanks Mithrandir 
<janimo> Mithrandir, so with flight 6 done today you think starting xubuntu install images could begin on Monday?
<Mithrandir> janimo: ask Kamion about that, but yes, I presume so.
<Mithrandir> or assume
<janimo> thanks
<mgalvin> Mithrandir: flight 6 about ready? i just wanted to know when to move the review to the main site... i didn't want to move it over there to early
<Mithrandir> mgalvin: it's about ready, yes.  And hour or two; I'm syncing the images to a mirror so cdimage doesn't die.
<seb128> Mithrandir: uploads still frozen?
<Mithrandir> seb128: yes.  Waiting for edubuntu to report back at least.
<Mithrandir> seb128: maybe also kubuntu, but I think those'll be released a bit later.
<seb128> k
* infinity notes someone just uploaded lprng.
<Mithrandir> seb128: if Riddell is fine with us opening the gates, we can do it once edubuntu is confirmed good.
<dholbach> infinity: that is universe
<Riddell> I'm still testing
* ogra as well
<infinity> dholbach: Oh, so it is.  I just assumed it wasn't.
<dholbach> i thought so first too :)
<Mithrandir> ogra: any ETA?
<Mithrandir> Riddell: any ETA?
<Riddell> Mithrandir: couple of hours at least
<bddebian> Can we please get Malone to require a Distro and maybe get it to tell universe from main?  Or does it already exist and I just don't see it?
<dholbach> bddebian: the main/universe distinction is planned
<dholbach> and what do you mean by "require a distro"?
<seb128> dholbach: it's already implemented
<bddebian> Make the submitter specify dapper/breezy/etc
<seb128> the query form has a "Component"
<seb128> main, universe, multiverse, etc
<dholbach> Ubuntu should be enough for "current development" release
<dholbach> ah ok
<bddebian> dholbach: ?
<dholbach> bddebian: hm?
<seb128> bddebian: bugs apply to dapper
<bddebian> Why?
<seb128> bddebian: if they don't apply to dapper you can use the "Backport Fix to Releases" on the right frame
<Mithrandir> Riddell: which means we could wait for you to complete testing.  Do you want us to?
<seb128> bddebian: because that how the tracke is designed?
<seb128> tracker
<bddebian> seb128: But how do I know if the user submitted it against Breezy or Dapper?
<dholbach> bddebian: because the current development release is what we work on, so it makes sense to call that "Ubuntu"
<dholbach> for everything else you have to ask
<seb128> atm it should describe that with his comment
<dholbach> if they don't specify it already
<Kamion> it would be exceedingly useful to at least have a way for submitters to specify the version number of the package they're using in a way we can automatically parse (i.e. not free text)
<Riddell> Mithrandir: if you're ready to go then don't wait on me, it might all fail yet and there's enough interesting things in this for a separate announcement
<Kamion> *that* is how Malone was *originally* designed
<Mithrandir> Riddell: I'm waiting for ogra, but ok.
<bddebian> Kamion: Aye, even that would help
<Kamion> bddebian: that's better than specifying a release because you can tell transient bugs in development releases
<bddebian> True
<herzi_x41> fabbione: ping
<fabbione> herzi_x41: pong
<Mithrandir> if somebody wants to proofread http://err.no/tmp/flight-6.txt , I'd be grateful
<doko> jdub, seb128: I see that opensuse uses DejaVu for the gnome UI although they list the Nimbus fonts as preferred. Do yo know why?
<seb128> no
<herzi_x41> fabbione: wacom tablets won't work with the new wacom-tools package
<herzi_x41> see my comment to one of the bugs
<fabbione> herzi_x41: how so?
<fabbione> what bug?
<Keybuk> Mithrandir: reads ok
<herzi_x41> it broken with linux-source2.5.15-16
<herzi_x41> https://launchpad.net/distros/ubuntu/+source/linux-source-2.6.15/+bug/35101
<Kamion> Mithrandir: "obiviously"
<Ubugtu> Malone bug 35101 in linux-source-2.6.15 "Wacom support completely broken now" [Normal,Unconfirmed]  
<fabbione> herzi_x41: so that's a kernel bug
<herzi_x41> yes
<Mithrandir> Kamion: fixed, thanks.
<fabbione> herzi_x41: we will get there...
<fabbione> herzi_x41: the wacom-tools userland was missing completely the X driver
<Kamion> Mithrandir: let's say "should now work on PowerPC" - I haven't actually had confirmation that the yaboot support works
<fabbione> so there was nothing working
<Mithrandir> Kamion: fixed.
<fabbione> herzi_x41: so i see no problem.. 
<Kamion> Mithrandir: "When rebooting after installing using espresso" ... you forgot to finish the sentence
<herzi_x41> fabbione: i just wanted to tell you that there will be "no wacom support even with the new wacom-tools"
<bddebian> yaboot hasn't been replaced yet? Ugh :-)
<Mithrandir> Kamion: true.  Fixed.
<fabbione> herzi_x41: if i was going to fix the kernel, somebody would have come here complaining about userland.. we need to start somewhere :)
<schlurchz> Mithrandir: flight-6.txt: 's/Flight 5 cd/Flight 6 cd/'
<fabbione> herzi_x41: and the pnpacpi regression is already fixed in our git tree
<Mithrandir> schlurchz: indeed.  Fixed.
<fabbione> herzi_x41: with kernel 2.6.15-20 it will be ok
<herzi_x41> great news
<Kamion> (I'd also say CD rather than cd)
<fabbione> herzi_x41: the serial ports (generally) are just broken.. so don't worry too much
<fabbione> well it was broken at least
<fabbione> herzi_x41: does this make you more happy?
<herzi_x41> yes
<herzi_x41> so i can use the tablet in class the next semester
<fabbione> probably from next week...
<fabbione> :)
<schlurchz> Uhm, the listed bugs in fligth 6 look pretty tough :-/
<Mithrandir> well, it's a snapshot.
<_mvo_> Kamion: where does the installer sets a global proxy configuration (does it support this)?
* schlurchz will probably install it anyway. 
<stewart> OK gnome is running like a dog
<Keybuk> schlurchz: it's a "this is where we're at today" release, not a polished one
<pitti> Riddell: ping
<seb128> stewart: how does a dog run?
<stewart> Im running the nvidia-glx from synaptic
* Keybuk throws a stick for stewart's GNOME
<stewart> haha seb in my case its a fat dog
<schlurchz> well, I understood that the flight releases _are_, to some degree, polished. Okay, they're clearly labelled alpha.
<siretart> Keybuk: wpasupplicant 0.4.8-1 got uploaded to sid earlier today. it is ready to be synced to dapper.
<pitti> Riddell: http://www.cups.org/str.php?L1527 -> "The final CUPS 1.2 release includes (temporary) compatibility functions with the old names, but they will be removed in a future 1.2.x patch release."
<stewart> on a fresh install on a decent spec machine and still its dogish
<pitti> Riddell: so there's hope :)
<Keybuk> siretart: were there any further changes from what we discussed yesterday?
<Mithrandir> schlurchz: very coarse sand grinder, I suspect.
<pitti> Riddell: assuming that we can upgrade to the final version
<siretart> Keybuk: no. only a one line bugfix: don't remove the /etc/network/if-up.d/wpasupplicant symlink in postinst :/
<stewart> after using synaptic to download nvidia-glx I had to update my xorg.conf from driver "nv" to "nvidia" is that still the case?
<siretart> but no further functional/semantic/docu changes at all
<Riddell> pitti: ooh :)
<Riddell> pitti: any idea when that final version will be out?  or can we upgrade to an SVN version?
<_mvo_> stewart: that sound be enough
<Keybuk> siretart: ok, looks good; you happy to upload to dapper once the freeze is over?
<stewart> _mvo_ dot sure what you mean?
<schlurchz> Mithrandir: mind to put in other words? I'm not native english? 
<pitti> Riddell: RC1 is current, I need to check whether it breaks anything before I ask for UVF
<stewart> not
<Kamion> _mvo_: it doesn't - the proxy question's just for the benefit of the installer AFAIK
<pitti> Riddell: no idea about the date for the final
<siretart> Keybuk: I'm just waiting for the freeze to end. the upload is prepared and signed and waiting for green light :)
<pitti> Riddell: should be RSN
<Keybuk> siretart: cool, thanks
<Mithrandir> schlurchz: not polished.  Cut into rough shapes rather than being a nice surface you can use as a mirror.
<Kamion> _mvo_: although it does write it into apt.conf
<Kamion> ./generators/50mirror.ubuntu:55:                        echo "Acquire::$protocol::Proxy \"$proxy\";" >> $ROOT/etc/apt/apt.conf.new
<schlurchz> Mithrandir: ah, okay thx
<_mvo_> Kamion: right, thanks. 
<Keybuk> siretart: which version did you use?  0.4.8-1build1 ?
<stewart> simple question - after apt-get nvidia-glx are users still expected to update xorg.conf settings from "nv" to "nvidia"?
<Mithrandir> stewart: yes
<Mithrandir> stewart: or nvidia-glx enable
<stewart> OK thnx
<Riddell> pitti: yeah, that's what they said in december
<pitti> :/
<pitti> but now they have an RC, so chances are higher :)
<Chipzz> Mithrandir: actually that nvidia-glx enable is nasty and should probably happen automagically or be a debconf question
<stewart> any reports of the nvidia-glx running poorly (Im using an nvidia nv18 nforce2 integrated)?
<pitti> stewart: nv34 integrated works fine here
<Kamion> Chipzz: (debconf questions are not a panacea, and we won't add extra questions to the installer so in fact adding a debconf question would be just as much work for users)
<siretart> Keybuk: yes, thats what I intend to upload
<stewart> well it works nv18 but dragging a window about quickly is right jerky
<stewart> something I didnt notice earlier with flight3
<Chipzz> Kamion: we could also let every xserver-xorg-driver (and the nvidia package) add themselves to a debconf list of available x server drivers
<Chipzz> and let every package do custom config itself
<Chipzz> but whatever :)
<Chipzz> pipedream or something ;)
<Kamion> Chipzz: pipenightmare
<Mithrandir> ogra: AWTY?
<ogra> Mithrandir, ppc missing, the rest is fine (apart from NM not working with my wireless cards and the gdm prob)
<Riddell> ppc users: is there a way to tell it to eject the CD on boot?
<Lathiat> JaneW: FYI, i updated my testing team info
<Lathiat> ergh
<Lathiat> and i just broke the page
<pitti> Riddell: press enter
<mdz> fabbione: I didn't realize tspc was in main until I saw that bug.  perhaps we should investigate and possibly reconsider?
<pitti> Riddell: if you mean the live CD shutdown
<pitti> Riddell: oh, wait, it does automatically for me
* Lathiat wonders how to revert a wiki page change
* Lathiat figures it out
<Kamion> Riddell: many mac keyboards have an eject button; hold that down during boot
<Kamion> Riddell: failing that, hold down cmd+opt+o+f during boot and type 'eject cd' at the OF prompt
<fabbione> mdz: reconsider to move it to universe?
<fabbione> mdz: i don't even recall why it was moved ot main in the first place.. 
<mdz> fabbione: right
<fabbione> mdz: i will need to check tho, but the bug is fixed
<fabbione> linux-2.6$ time make -j
<fabbione> real    1m35.013s
<fabbione> not too bad, is it?
<Lathiat> what machines that?
<Mithrandir> Riddell: traditionally, hold down the mouse button while booting.
<Mithrandir> Riddell: or what Colin says.
<_mvo_> what should we do with the fade-effect of gksu? should it be removed?
<fabbione> mdz: the point is a delicate one
<fabbione> mdz: if we start moving the tunnel broker outside main, we need to remove them all or none
<fabbione> mdz: iirc we have 2 or 3, because they cover 99.9% of internet
<fabbione> mdz: and the clients are tiny
<fabbione> anyway i don't have a strong opinion on it
* fabbione pats his ASNO
* Mithrandir ruffles openvpn
<Mithrandir> (which should probably be in main, given it's usefulness and being quite common)
<fabbione> bbl
<Riddell> thanks, kamion's method worked after mapping mac keys to this pc keyboard
<infinito> does anyone know why gnomeapplet has disappeared from python2.4-gnome-extras ???
<dholbach> infinito: pythone-gnome-extras was split up into pythone-gnome-extras and python-gnome-desktop
<infinito> umm, packages.ubuntu.com shows bad info about files inside pkgs...
<infinito> dholbach: thanks
<doko> carlos, pitti: is #4452 still an issue?
<pitti> bug 4452
<Ubugtu> Malone bug 4452 in firefox "translation tools - request oo2po --multifile option be abstracted to moz2po" [Unknown,Unknown]  http://launchpad.net/bugs/4452
<pitti> doko: carlos wanted to start looking into ffox po generation soon
<carlos> right
<infinito> dholbach: what are the exact names of the packages? i cant find them on ftp.ubuntu.com pool
<pitti> doko: the request sounds useful, I just don't know the status of the current translation tools - carlos, do you?
<mdke> Diziet, ping?
<carlos> pitti: hadn't time yet to look into it
<dholbach> infinito: python2.4-gnome2-desktop, python-gnome2-desktop-doc, python-gnome2-desktop-dev, python-gnome2-desktop
<Kamion> mdke: he's on holiday this week
<dholbach> infinito: apt-cache search knows :)
<mdke> Kamion, ah thanks. I'll mail.
<infinito> dholbach: sorry ;)
<ogra> Mithrandir, edubuntu is fine apart from the known errors with the livecd ...
<jcole> is this what ubuntu dapper uses for gui installation? -> http://wiki.debian.org/DebianInstaller/GUI
<seb128> jcole: no
<pitti> jcole: no, we have our own GUI installer which works in an entirely different way
<jcole> hmm
<pitti> jcole: https://wiki.ubuntu.com/UbuntuExpress
<phanatic> hi people
<phanatic> Kamion: ping
<jcole> pitti: thanks
<Kamion> phanatic: hi
<phanatic> Kamion: i'd like to ask about the @ubuntu.com addresses. are they created automatically? i became a member on 7th march, but i don't know if i have my address or not :)
<Kamion> phanatic: they're supposed to be, yes
<Kamion> phanatic: try it with your launchpad id in the local-part and see :)
<Kamion> could be it's broken though, I don't have access to that part of the system
<phanatic> Kamion: i tried it, but didn't get the mail to my registered mail address (or there's a huge delay)
<phanatic> Kamion: then sorry, i was told, that maybe you can help with this
<jcole> we use the debian installer to net-install various distros (nicluding ubuntu) and i wanted to attempt a gui makeover... looks like http://wiki.debian.org/DebianInstaller/GUI is my easiest option
<jcole> hey TomB_ !
<ogra> phanatic, did you try #launchpad ? 
<siretart> jcole: I cannot image a net-install use case which would require a gui. could you please give me an example one?
<ogra> thats the proper channel for this question rather 
<phanatic> ogra: not yet, but i'll do it :)
<ogra> :)
<jcole> siretart: partitioning?
<jcole> siretart: we use this to create our images -> http://linuxcoe.sourceforge.net/
<Pygi> ogra is alive ;) joy :-P
<gouchi> Hi 
<gouchi> sorry to bother you 
<gouchi> just to report some news
<gouchi> Ulteo will use Kubuntu for making test
<Riddell> gouchi: what's Ulteo?
<gouchi> according to GD : http://ulteo.org/forum/viewtopic.php?id=23
<Kamion> phanatic: sorry, you were directed to the wrong person; elmo would be a better bed
<Kamion> er, bet
<gouchi> Riddell : www.ulteo.com
<phanatic> Kamion: thanks :)
<gouchi> I think maybe some of you, maybe will be interested in the project
<phanatic> elmo: are you here? :)
<gouchi> GD asks for some help, advice
<Riddell> aah, gduval's new crack.  excellent
<Riddell> gouchi: sure, I'm happy to advise however I can, find me in #kubuntu-devel for development chat
<gouchi> Ridell : yep that's it and I think there is an #ulteo and GD approved
<Kamion> pitti: for bug 8048, what do you think about using the owner option in fstab, and setting the ownership of the device nodes with udev rules or something?
<Ubugtu> Malone bug 8048 in partman "Mounted vfat partition is not writeable for non-root users" [Normal,Confirmed]  http://launchpad.net/bugs/8048
<Kamion> somebody in the bug log said that Fedora does that, although they seemed confused about its meaning
<trappist> Kamion: tjere
<pitti> Kamion: hm, but whom to assign it to?
<Kamion> pitti: or, actually, the group option, and make the device node group plugdev
<trappist> oops... there's a similar bug for ntfs where it's suggested we mount as the plugdev
<pitti> Kamion: just assume uid=1000? that sounds hackish
<Kamion> pitti: group option
<Kamion>               group  Allow an ordinary (i.e., non-root) user to  mount
<Kamion>                      the  file system if one of his groups matches the
<Kamion>                      group of the device.   This  option  implies  the
<Kamion>                      options  nosuid  and  nodev (unless overridden by
<Kamion>                      subsequent  options,  as  in  the   option   line
<pitti> Kamion: right, that's why I proposed in the third-last comment
<Kamion>                      group,dev,suid).
<Kamion> pitti: oh, will pmount let you mount a device if you share its group?
<pitti> Kamion: I'd be fine with umask=077,group=<plugdev gid>
<Kamion> no, you're confusing options
<Kamion> you're thinking of gid=
<Kamion> group= is the mount option above
<Kamion> not group= actually, just group, it's a flag
<Kamion> gid= sets the group ownership of the files once mounted
<pitti> ah, that one, right
<Riddell> Mithrandir: kubuntu amd64 install had a corrupt apt package, presumably a bad CD burn but I'll need another 90 minutes to download again and check
<pitti> Kamion: yes, once the partition is in fstab, pmount will use mount
<Riddell> all others fine
<pitti> Kamion: so that'll work
<Kamion> hmm, I guess that might not set uid= and gid= though
* Kamion goes to test
<pitti> Kamion: that's why you need gid=<plugdev gid>
<trappist> should this and bug 25071 duplicate each other?
<Ubugtu> Malone bug 25071 in partman-basicfilesystems "More reasonable defaults for ntfs mounts during installation" [Major,Unconfirmed]  http://launchpad.net/bugs/25071
<pitti> Kamion: so that group will allow plugdev users to mount it
<pitti> Kamion: argh, bs
<Kamion> oh, plugdev is a static group, that helps
<pitti> Kamion: I mean, udev needs to put them into plugdev
<Kamion> (I thought I was going to have a problem with getting the gid at that stage in the installer
<pitti> Kamion: not sure how to achieve that, though
<Kamion> )
<Kamion> trappist: I'm deliberately keeping the vfat bug and the ntfs bug separate, although chances are I'll fix them both at the same time
<pitti> Kamion: TBH, I think that the user option might be easier
<Kamion> Keybuk: any ideas?
<pitti> Kamion: or, don't do user/group at all, and just set it to 'auto'
<pitti> Kamion: or do you prefer to dynamically mount those partitions instead?
<pitti> Kamion: so far the partitioner set up an fstab in a way that they are just moutned at boot
<Kamion> pitti: auto still means the can of worms of which uid to assign them to
<pitti> which is fine for me
<pitti> Kamion: root/plugdev
<Kamion> oh, hmm, and umask=007?
<pitti> yep
<jcole> don't get enough sun working indoors all day? here's your solution! http://www.thinkgeek.com/stuff/41/usbtanner.shtml
<Kamion> ok, good point, that works
<pitti> Kamion: back in 5 minutes, door bell
<doko> seb128: does gnome-panel have an option to show hidden menu files?
<seb128> doko: no
<dholbach> doko: you can enable them with alacarte or by editing the menus, but that's it
<seb128> "menu files", you mean "menu items", no?
<Amaranth> items with Hidden=true can't be shown with alacarte
<Amaranth> NoDisplay=true is a different story
<seb128> doko: how do you flush your clipboard selection?
<doko> yes, I think we should have a policy to add Hidden=true instead of remving the desktop file
<doko> seb128: by closing OOo :-)
<seb128> - gedit has the Paste menu entry enabled
<seb128> that's not true
<seb128> oh, you use the top menu, not the context one
<LaserJock> doko: do you have any idea if vnc4 is going to be able to be fixed for Dapper?
<j^> how comes pam is so outdated and highly patched?
<ogra> seb128, did you note that i said edubuntu is ready for flight-6 ? since only kubuntu is missing now, i think gnome uploads should be fine again ...
<seb128> doko: you are not bored enough that you file details like that? :)
<ogra> (you asked for uploads before)
<seb128> ogra: right, I didn't notice, thank you
<KaiL> libpythonize0 depends on python2.4-dev? Bug or feature? ;)
* ogra hopes Mithrandir noted it :) since i had network probs before 
<doko> seb128: just checking the OOo copy&paste thing ...
<seb128> doko: yeah, and the not coherent is not limited to gedit and g-t, evo behaves differently too
<seb128> dunno which one is right
<seb128> so dunno what half of the apps to bug
<Kamion> Riddell: since ogra mentioned it ... how goes the Kubuntu testing?
<doko> seb128: dunno as well, just noticed
<Riddell> Kamion: I had a problem on the amd64 CD, apt .deb was corrupt, probably a bad CD burn but it'll take another  couple of hours to download and check
<Riddell> otherwise all fine
<Kamion> Mithrandir: ^--
<Kamion> Riddell: mm, right, corrupt .debs usually are
<Mithrandir> Riddell: thanks.
<Kamion> Mithrandir: worth just going for it?
<Mithrandir> Riddell: can't you rsync -c ?
<Fjodor> Please excuse if this is the wrong channel, but it seems the libstdc++5-3.3 is having trouble getting malloc declared:
<Fjodor> /usr/include/c++/3.3/cstdlib:103: error: `malloc' not declared
<Riddell> Mithrandir: alas the ISOs were on the amd64 which now has a broken install
<Mithrandir> Riddell: hmm..  We could just wait if you prefer that.  I'm fairly sure it's not a problem, but your call.
<Riddell> Mithrandir: if you don't mind waiting a couple of hours that would be good
<Mithrandir> Riddell: sure, that's doable.
<Riddell> I'll try and rescue the ISO using a live CD
<dholbach> Mithrandir: was the assumption right, that gnome uploads should be ok now?
<Mithrandir> dholbach: no, please not yet.
<dholbach> ok
<dholbach> thanks
<Mithrandir> dholbach: not until http://cdimage.ubuntu.com/releases/dapper/flight-6 200 and not 404
<Kamion> Riddell: is that both install and live images, or is the amd64 live CD OK?
<dholbach> hehe
<ogra> Mithrandir, but the gnome distros are both gold ...
<ogra> Mithrandir, i think you couild allow it for gnome only stuff :)
<Mithrandir> ogra: true, but I prefer to be conservative.
<ogra> heh
<ogra> ok
<Riddell> Kamion: live is fine
<Kamion> pitti: hmm, how come hda1 isn't showing up on my desktop or in Places?
<Kamion> oh, it's not mounted
<Kamion> pitti: think I should make it automount (pass 1 in fstab)?
<Keybuk> Kamion: sorry, phased out there :)  ideas about?
<Kamion> Keybuk: it's OK, superseded :)
<Kamion> Keybuk: was thinking of making some hard disk device nodes be group plugdev (but not writable by that group)
<Kamion> but I think we'll go with a different solution
<Keybuk> any particular reason?
<Kamion> vfat and ntfs
<Riddell> Kamion: would you be able to get knetworkmanager past NEW so we could include it in the flight announcement?
<Kamion> so that people can mount their Windows filesystems
<Keybuk> why would you need to read directly from the device node for those?
<pitti> Kamion: we agreed to only show volumes in /media
<Kamion> Keybuk: sorry, I should have said not readable by that group. I had been thinking of using the 'group' mount option
<Keybuk> it'd somewhat default the object of people who try to make their home directories not read-only though :)
<Kamion> pitti: it is in /media
<Keybuk> ohh
<pitti> Kamion: and then it must have been mounted before gnome start
<Keybuk> group mount option is a metric light year away from changing the group of the device nodes, which is what you were sounding like implying ;)
<pitti> Kamion: that's sort of a gnome-vfs bug
<Kamion> Keybuk: group mount option requires changing the group of the device nodes in order to be useful
<pitti> Kamion: I think 'auto' is fine
<Kamion> Keybuk: it's the option that says "allow the user to mount this device if they're a member of the owning group"
<Kamion> I don't think it requires read access to the device node
<Kamion> pitti: restarted GNOME, still doesn't appear
* Kamion tries rebooting
<Keybuk> Kamion: so you'd make the devices 0600 root/plugdev ?
<Kamion> Keybuk: that was my original thought before pitti suggested an alternative, yes
<Keybuk> *nods*
<Keybuk> it's not necessarily evil, though I don't know whether anything truly cares about the "disk" group -- might break those things
<pitti> Kamion: hmm, odd, can you please file a bug with the lshal output?
<pitti> I think dynamically setting the device node group according to fstab parsion is pretty evil
<Kamion> pitti: it appears after reboot, FWIW
<KaiL> Riddell, displayconfig (from kde-guidance) is far away from being usable, or?
<Riddell> KaiL: sound be fairly usable
<KaiL> how many bug reports do you want? 20? 40? 100? ;)
<KaiL> here it makes arround everything wrong, it could :(
<Lure> KaiL: ping Sime in #kubuntu-devel when online
<KaiL> ok
<pitti> Kamion: I nead to leave soon, are there still any things to be discussed?
<Kamion> pitti: nope, I think I can do this now
<pitti> Kamion: cool; so after all the udev/group alternatives, we end up with the simple gid=plugdev/umask=077/auto way?
<Kamion> pitti: umask=007, but yeah
<pitti> erm, yes, tpyo :)
<pitti> alright, then good night everyone!
<Kamion> I'll sort you out with the lshal stuff in a bit
<Kamion> or possibly Monday
<pitti> Kamion: yep, thanks
<KaiL> 7 bugs on intel i810
<KaiL> let's see, how many are on the ATi radeon driver too...
<Lure> Kamion: [19:59]  <Riddell> Kamion: would you be able to get knetworkmanager past NEW so we could include it in the flight announcement?
<Kamion> oh, yeah, give me a second
<Lure> Kamion: thanks
<Kamion> Riddell: source NEWed, sorry for the delay; unfortunately I'll probably be away for a fair chunk of the evening so I can't promise quick binary NEWing
<Kamion> but I'll try to do it at some point tonight
<Kamion> so you can say "will be available within the next 24 hours" or something if need be
<G0SUB> will Xen 3.0 be available off the shelf with Dapper?
<neuralis> G0SUB: no.
<G0SUB> neuralis: dapper+1 ?
<neuralis> G0SUB: possibly, but i don't think i'd support it. there's significant value in waiting for upstream to merge xen into kernel proper, and providing unofficial packages until then.
<Riddell> Kamion: thanks
<neuralis> G0SUB: it's a security/maintenance nightmare to provide it out of the box.
<G0SUB> neuralis: I agree ... but if Fedora can do it ....
<neuralis> G0SUB: that's not really a strong argument.
<G0SUB> neuralis: yes, but Xen could have been a big USP for us ... wrt Bigirons
<neuralis> G0SUB: we all want it, but given present developer resources, we can't do it. have you looked at how invasive xen patches are? we need to support our releases for at least 18 months.
<G0SUB> neuralis: I understand ... *sigh*
<neuralis> G0SUB: we had nice unofficial xen packages for breezy. if you wanted to win a few beers, make us some for dapper!
<G0SUB> neuralis: where are those?
<G0SUB> neuralis: in Universe?
<neuralis> G0SUB: no, they were produced by some of the COSI guys at Clarkson University. the website seems down at the moment, but is xen.cosi.clarkson.edu
<G0SUB> oh, btw, ESR has accepted Mark's offer of joining Ubuntu Technical Board
<G0SUB> I have no idea sabdfl invited him here ...
<Burgwork> G0SUB, this is an april fools joke, right?
<sladen> G0SUB: is this the latest ELER
<G0SUB> sladen: no
<sladen> matthew and eric will get along SO NICELY together
<neuralis> :-D
<G0SUB> sladen: the latest was on Monty Python
<G0SUB> Burgwork: it was a april fools' joke ... and I was the one who was fooled
<sladen> buuu, buuuut, it's not April 1st for another 4hours
<ogra> sladen, in other TZs it is :)
<G0SUB> sladen: I am in +0530
<Burgwork> G0SUB, got a linky?
<neuralis> G0SUB: the key to a good april fool's joke is the hint of believability. ESR joining the TB doesn't have it, in my book ;)
<G0SUB> Burgwork: heh, no links ... somebody told me on IRC
<sladen> neuralis: oh, it does...
<G0SUB> neuralis: IMO, it's quite possible
<sivang> Burgwork: me burfing at you is soon now :)
<sladen> Ian Murdock would be even better
<G0SUB> heh, yeah
<neuralis> sladen: nah. esr has no contribution history to the project. and he's crazy in the coconut. :)
<zul> heh daniel robbins would be funny..
<sladen> lalallalalala
* neuralis *whistles*
<jpatrick> sladen: evening to you too
<soumyadip> zul, Daniel Robbins ? we'd have Ubuntu from Scratch then
<G0SUB> soumyadip: Dapper from stage 1 debs
<sladen> sabdfl: superb timing, G0SUB was just giving us the low-down on your pending annoucement for tomorrow that ESR had been appointed to the Technical Board
<G0SUB> sladen: we better wait for the official announcement
<Keybuk> I thought ESR was joining the Community Council
<G0SUB> Keybuk: possibly ... it's just a speculation
* sivang lols at the april fool's jokes running here inspied by "Who Loves Eric Raymond" :-)
<LaserJock> is there a policy about where a browser plugin should be linked to to get it recognized?
<G0SUB> sivang: ``Everybody Loves Eric Raymond''
<Keybuk> "Everybody Loves Matthew Garrett"
<sivang> ROTFL
<Keybuk> I've been trying to persuade jono to name Matthew's talk at LRL to be "Matthew's Angry Hour"
<sivang> Keybuk: what's LRL ?
<neuralis> Keybuk: dude. awesome.
<neuralis> sivang: lug radio live.
<Keybuk> http://www.lugradio.org/live/2006/index.php/Image:Basicposter.png
<Keybuk> ooh, Simon Phipps
<Keybuk> time to get those "If Sun Truly Believed In Free Software, They'd Open Source Java!" t-shirts made up
<sivang> Keybuk: hehe
<sivang> Keybuk: I thoguht java is an open standard no?
<sivang> (and thus anybody can implement it and release the source)
<Keybuk> that's still rather missing the point
<neuralis> sivang: sun's vm is closed.
<sivang> neuralis: who cares? we can make our own :)
<neuralis> sivang: what keybuk said, about missing the point? that.
<Keybuk> sivang: people have been trying for years, and are still nowhere near completion
<jcole> why don't they open source it? do they make money from it? if so, how?
<sivang> Keybuk: I see, maybe they're holding details from the spec that they have put into the implementaion?
<Keybuk> jcole: because they don't Truly Believe In Free Software
<neuralis> sivang: no. it's just enormous.
<sivang> neuralis: I see
<sivang> neuralis: what's the state of qjc ?
<sivang> err, gjc
<neuralis> sivang: gcj?
<sivang> yes, mind my dyslexia :)
<neuralis> sivang: classpath implements a good majority of the classes from j2se 5 and 1.4
<neuralis> sivang: so it's decent, but it's a bloody shame people had to expend the man years of work to reinvent that whell.
<neuralis> s/ell/eel/
<sivang> neuralis: indeed :-(
<sivang> just for the sake of that they should have open sourced it
<sivang> they would probably still earn from support and integration
<jcole> Keybuk: ya, but why are they holding back java? they open sourced suff people pay for already - openoffice, solaris, etc... why not java?
<jcole> Keybuk: i can't figure it out... do they make money from java? is there copyrighted code in it?
<jcole> it's like microsoft open sourcing windows and office, but not activex
<neuralis> jcole: there's probably concern about things like the hotspot server vm optimization routines becoming open and getting studied and copied in competing platforms (.net, e.g.).
<neuralis> jcole: anyway, it's off-topic here, so let's call it eod.
<jcole> neuralis: heh
<Keybuk> jcole: I have no idea why; I tend to ask Simon every chance I get and he runs away from me
<jcole> Keybuk: :)
<Pygi> Keybuk: I really doubt we want that kind of project integrated into Dapper :-P
<_ion> There's plenty of time. ;-)
<Keybuk> Pygi: wpasupplicant udeb?  Why not, would be cute
<Keybuk> netcfg already does WEP
<Keybuk> just a matter of detecting a WPA network, and then prompting for the key phrase, etc. and seeing /e/n/i
<Pygi> yes, but we are still not on "ok" with wpasupplicant ;)
<Keybuk> what's up with wpasupplicant?
<Pygi> well, nothing actually.... but bugs, issues, thingies...
<Keybuk> such as?
<Keybuk> excluding anything touching NM, which isn't in the scope of what I suggested
<Pygi> yes, yes, I know
<Pygi> so, find someone to do it then? :-P
<Keybuk> and I thought you were volunteering :p
<Pygi> bah, so much work to do 
<Pygi> perhaps for dapper+1, sure  ;)
<Keybuk> Kamion: ok, earlier conversation looks possible ... might even have it done by Monday depending what time David turns up (and I get up) tomorrow :p
<Keybuk> though not promising anything
<Riddell> Mithrandir: kubuntu is good to go
<siretart> Keybuk: how about wpa initramfs integration, so that you can boot via nfs on wpa secured networks ;)
<Pygi> siretart: bah :-P
<Keybuk> siretart: first we'd need to put the wireless chipset firmware in the initramfs ;)
<Keybuk> the principal problem with that though is that anything started in the initramfs needs to be killed before the main system is started
<Keybuk> the wpa suppository started in the initramfs couldn't continue to run while the main system booted
<siretart> Keybuk: err, this doesn't include udev, does it?
<Keybuk> siretart: yes, it includes udev;  check /usr/share/initramfs/scripts/init-bottom/udev
<Keybuk> uh, stick -tools in there :p
<Pygi> Keybuk, siretart: and I assume you have people to do that? ^_^
* Keybuk doesn't have any people to do anything
<siretart> interesting
<Keybuk> the police found my dungeon and took my slaves away :'(
<Pygi> Keybuk: joy, buy a new ones? ;)
<Keybuk> siretart: so I guess you could say the very (AND OH SO CRACKFUL) design of WPA prevents you from remote-mounting a root filesystem across a WPA-secured network
<siretart> Keybuk: well, I think a few seconds without connection to the server wouldn't hurt too bad. 
<Keybuk> unless you did WPA in a kernel module or something
<Keybuk> siretart: the trouble with those few seconds, is how do you start WPA supplicant again, which is on the NFS server? :)
<Keybuk> it's not actually that bad in reality
<Keybuk> it doesn't matter too much if the suppository runs during boot, provided it's killed eventually
<Keybuk> usplash runs through boot, for example
<Keybuk> so you'd have a hand-over point where you killed the running one after starting a new one
<siretart> yes. this sounds like it could work..
<Keybuk> it'd be easy
* Pygi hides, so Keybuk couldn't ask him to do this...
<Keybuk> just create /usr/share/initramfs-tools/scripts/nfs-premount/wpasupplicant
<Keybuk> make it run wpasupplicant with the right options
<Keybuk> and create /usr/share/initramfs-tools/hooks/wpasupplicant
<Keybuk> that made sure wpasupplicant was copied over
<siretart> I think it is more likely that someone wants to use wpa on his wired network than netbooting on wpa secured wireless..
* Riddell publishes kubuntu flight 6
<siretart> yay! \o/ 
<Keybuk> and also probably copied /lib/firmware, /etc/udev/rules.d/80-programs.rules, /lib/udev/firmware_helper so you can actually start the cards <g>
<Keybuk> you can't use wpa on a wired network, no? :)
<Keybuk> wired network cards don't tend to understand WEP
<siretart> Keybuk: you can. you use then -D wired on wpasupplicant
<siretart> wpa has nothing to do with WEP
<Keybuk> I thought WPA was a "magically change the WEP keys every few seconds" thing?
<siretart> though, the use of xsupplicant is more common for wired networks
<siretart> Keybuk: wpa has very litte to do with wep. what you describe is sometimes called 'dynamic wep'
* j^ thought it had to do with killing kittens
<Pygi> aka 802.1x
<siretart> which wpasupplicant supports as well
<j^> which was added to network-manager in 0.6.2
<siretart> xsupplicant, too, I think. but I never used that
<siretart> Pygi: you can use 802.1x authentication without encryption as well
<Pygi> siretart: yes, yes...
<Keybuk> j^: I think it still does
<Hwyvar> buh
* netjoined: irc.freenode.net -> brown.freenode.net
<Riddell> maswan: please mirror /kubuntu/releases/dapper/flight-6/
* netjoined: irc.freenode.net -> brown.freenode.net
<Mithrandir> Riddell: excellent, thanks.
<Mithrandir> maswan: ravel:/org/tmp/*-flight-6 has the images.
<bddebian> Bah, I should be looking at bugs again.. :-(
<Kamion> Mithrandir: we good to unfreeze the archive, then?
<Mithrandir> Kamion: yup
* ..[topic/#ubuntu-devel:Mithrandir] : Ubuntu Development (not support, even with dapper) | #ubuntu for support and general discussion | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/DeveloperResources | http://wiki.ubuntu.com/HelpingWithBugs | If your initramfs is broken in any way, please save a copy for infinity | Flight 6 released
<Kamion> rah
<Mithrandir> Kamion: I guess few enough people will pick up the image before tomorrow morning, so I'll just hold off the announcement until it's automagically mirrored.  Unless maswan shows up
* Pygi grabs image
<lamont> Mithrandir: does that mean that the torrents are up?
<Kamion> Riddell: network-manager-kde binaries newed
<bddebian> newed? :-)
<Mithrandir> lamont: I'm actually doing the release stuff on little now.
<Kamion> processed through the new queue
<bddebian> No definitions found for "newed"
<bddebian> ;-P
<lamont> Mithrandir: ah, ok
<lamont> because release/dapper/flight-6 doesn't exist yet... :-(
<lamont> just say when
<lamont> Mithrandir: they're really close to the current daily, yes
<lamont> ?
<Mithrandir> lamont: they are the current dailies
* lamont does some syncage
<Kamion> bddebian: *shrug* niche jargon ...
<bddebian> Kamion: I know, sorry, I'm just being a nudge
<lamont>  /dev/hda                631962    631962         0 100% /media/cdrom0
<lamont> /dev/hdd                642554    642554         0 100% /media/cdrom-1
<lamont> \
<lamont> neat naming convention.....
<sivang> heh
* sivang plays spot the differences
<lamont> cdrom0 vs cdrom-1
<lamont> the hdd instead of hdc thing is all me.
<mgalvin> Mithrandir: review is up on ubuntu.com
<Mithrandir> mgalvin: thanks
<mgalvin> np
* Mithrandir runs publish-release for each arch, etc
<debugger> hi
<Mithrandir> lamont: when
<ajmitch> morning
<lamont> Mithrandir: lying
* lamont screams and beats the $^(%*)($^%_^ proxy
* lamont downloads the .torren%74 files instead
<lamont> Mithrandir: ENO ports/releases/dapper/
<Mithrandir> lamont: true dat.
<Mithrandir> Kamion: how do I release ports?  for-project ports?
<sladen> Mithrandir: I love your -*- zone -*- response to the Vim leets
<Mithrandir> I doubt they'll catch it, though
<sivang> who do I email for admin request proposals?
<sivang> hmm, is there no more plain CD only DVD to download for breezy release?
<mdke> sivang, what sort of request?
<mdke> rt@admin.canonical.com if it's a Znarl/elmo job
<mdke> -> bed
<_mvo_> sivang: on releases.ubuntu.com ?
* _mvo_ need to go and do his laundry
#ubuntu-devel 2006-04-06
<sivang> _mvo_: yes
<sivang> mdke: okay, thanks
<sivang> _mvo_: I just want a cd iso
<sivang> _mvo_: you know where I can download one?
<Pygi> sivang: ISO of what?
<KaiL_> oh, cool
<KaiL_> eh - wrong window ;)
<sivang> Pygi: 5.10 
<sivang> Pygi: breezy, not DVD. releases.ubuntu.com has only DVD images
<Burgwork> sivang, I believe that is due to the isntaller vuln
<sivang> Burgwork: okay, so I better start downloading...
<Mithrandir> sivang: uh?  http://releases.ubuntu.com/5.10/ ?
<Pygi> sivang: torrents?
<sivang> Mithrandir: I arrived at http://cdimage.ubuntu.com/releases/5.10/ from cdimage.u.c
<sivang> Mithrandir: thanks
<Pygi> damn, espresso just failed to install ubuntu :(
<Pygi> people, wake up...flight 6 doesn't work
<sladen> Pygi: how did it fail?
<sladen> Pygi: what error messages were there?  Can you please file a bug at:  https://launchpad.net/distros/ubuntu/+source/espresso/+filebug
<Pygi> sladen: grub installation failed, and once I fixed it, the system refused to boot at all
<Pygi> sladen: I fixed everything with live cd, but Xserver refuses to load
<sivang> good night all!
<Pygi> night sivang
<Pygi> bah, nevermind, drop that failing things, etc.
<Pygi> everyone is sleeping mostly anyway or working :P
<Fjodor> Does anyone know why I am having trouble linking against code compiled with the libstdc++5 things and gcc-3.3? Is this a bug that I need to file with you guys?
<Seveas> you should recompile - everything in Ubuntu is compiled with 4.0 which is abi-incompatible with 3.3
<Fjodor> Well, the whole point is to compile against the 3.3 things. I am trying out pathscale, which is based on 3.3
<Fjodor> What made me think I might trouble you guys with it was, that dapper provides the 3.3-things, so I guess it should be possible to use it
<Fjodor> Actually, it compiles fine, but fails on referenced in section `.rodata' of seti_boinc-schema_master.o: defined in discarded section
<Fjodor> when linking
<Fjodor> However, I won't hold it aginst you if you tell me to seek advice elsewhere :-)
<Seveas> I'm no C++ expert, but as I understand it it's not possible to do what you want
<Fjodor> Hmm, that's sort of a let-down. Can I ask you some questions in private about this, or are you busy?
<Fjodor> ... and/or not interested :-P
<Seveas> neither busy nor interested - but I'm off anyway (bedtime)
<Fjodor> Fair enough. Thanks for your time anyway :-)
<Fjodor> And sleep well
<robertj> does anyone else get a warning dialog between the time they open the theme preference dialog and the time it appears but it goes away automatically?
<jdong> guys, no Ubuntu april fools joke yet?
<yves> a few
<yves> @#ubuntu-motu: <kbrooks> has canonical merged with mandriva/
<yves> :-D
<whiprush> I'm waiting for the joke gdm splash like last time. :D
<yves> I've just helped this canonical/mandriva merge joke to spread hehe
<OgMaciel> anyone seen this yet?  http://linustorvalds.typepad.com/the_kernel_blog/2006/04/account_created.html   sounds like an April's fool joke to me
<Lathiat> no kidding :)
<gonffen> oh noes nubuntu
<Keybuk> English please on here
<gonffen> Keybuk: nubuntu is no more
<gonffen> is that good for you?
<Keybuk> what was nubuntu?
<gonffen> nubuntu.org
<gonffen> maybe it's part of this whole conical/mandirva merger?
<Keybuk> this is all a bit off-topic for this channel
<gonffen> you sure?
<gonffen> it is related to the development of ubuntu
<gonffen> or did I get the topic wrong?
<Keybuk> it doesn't matter too much at this time of night and weekend of course, I guess
<Keybuk> most people are asleep or being forced to spend time with their partners :p
<Amaranth> nubuntu was ubuntu for script kiddies?
<Keybuk> Amaranth: heh, that was my opinion at first glance too :)  I thought I'd be more diplomatic though
<gonffen> lol
<gonffen> ubuntu is linux for people who don't want to learn it :)
<Amaranth> windows is for people who don't want to learn DOS
<Keybuk> blenders are for people who don't want to use a whisk
<Amaranth> a keyboard is for people who don't want to learn how to flip switches to generate hex codes
<gonffen> 
<gonffen> windows is for people too stupid to learn dos
<Keybuk> a dog is for life, not just for christmas
<gonffen> never heard that one before :)
<Amaranth> hehe
<Amaranth> If you're going to be annoying and try to 'r00t' me at least know what you're doing
<gonffen> lol
<gonffen> ya I hear ya
<Keybuk> Amaranth: I just set my root password to "god"
<Keybuk> for some reason, kiddies never try that oine
<Amaranth> haha
<gonffen> that and sex
<Keybuk> yeah, script kiddies never try sex
<Keybuk> it explains a lot about them
<gonffen> I make all my secure passwords sex
<Amaranth> 'password' works for me
<Keybuk> "...so, would her holiness mind changing her password?"
<gonffen> wow it's sad when you can actually quote Hackers :\
<Keybuk> I can quote pretty much any film I've seen, or any book I've read
<Keybuk> you'd think it'
<whiprush> hi Keybuk 
<Keybuk> d be useful at dinner parties, but it usually results in me getting stapped
<Keybuk> stabbed too
<Keybuk> whiprush: heyhey
<gonffen> lol
<whiprush> you think bug 37128 is a dupe of 37084? 
<Ubugtu> Malone bug 37128 in network-manager network-manager-gnome "nm-applet doesnt start" [Normal,Confirmed]  http://launchpad.net/bugs/37128
<Keybuk> I've no idea
<Keybuk> I must admit that I've tended to ignore most nm bugs
<whiprush> It's currently crashing when there are entries in /etc/network/interfaces.
<infinity> whiprush: Not entries, entries with extra info in the iface stanza.
<Keybuk> looks the same
<Keybuk> and looks like the bug infinity told me about
<infinity> whiprush: (ie: anything more than just "iface eth1 inet dhcp")
<whiprush> I fixed 95% of my n-m problems by replacing the madwifi in my X40 with an ipw2200. I recommend spending the money.
<whiprush> infinity: k.
<whiprush> So should I dupe these reports or .. ?
<Keybuk> yeah if you like
<Keybuk> fix it too :)
* infinity figures that if Keybuk doesn't fix it in the next week, he will.
<Amaranth> the firmware needed for the latest ipw2200 driver isn't redistributable, is it?
<infinity> Amaranth: No less so than any previous version we've shipped.
<Keybuk> infinity: I've pretty much decided NM isn't getting seeded at this point
<Amaranth> infinity: It sounds like older vesions were ok
<Keybuk> so I'm kinda slacking on bugs in it, and instead looking at better fruit
<Keybuk> yeah
<Amaranth> from this blog i'm reading
<infinity> Keybuk: ... To desktop, or do you mean you're removing it from suported?
<Keybuk> *my* patch to disable interfaces was fine
<Keybuk> looks like the upstream functionality isn't
<Keybuk> infinity: leave it in supported, just not in a meta package
<infinity> Right, I assumed that's how it would end up.
<infinity> (Well, it still seems a good fit for live...
<infinity> )
<infinity> Amaranth: And where is this blog?
<Keybuk> yeah, less user configuration to get in the way of
<Keybuk> NM is just *such* a bitch to get going when it's decided to be horrid
<Amaranth> oh, i read it wrong
<Amaranth> the problem is just that it needed new firmware
<Keybuk> requires a degree in advanced fuckery just to get a working machine
<whiprush> the wpa bugs keep piling up too.
<Keybuk> wpa bugs?
<Keybuk> on NM or suppository?
<whiprush> on NM I mean
<Keybuk> yeah
<Keybuk> I still can't get it to work
<infinity> It worked over here, in testing.
<Keybuk> it's worked for some people
<whiprush> It works great for some people
<Keybuk> but for me, it just sits in a "yeah, associated, BUT NO CIGAR" state
<Keybuk> I think it's NM being stupid
* infinity nods.
<Keybuk> because WPA works perfectly if I just put the appropriate suppository stanzas in /e/n/i
<infinity> Well, "it works great for some people" seems to be a good argument for the "ship it, but don't install it by default" state.
<Keybuk> with the changes to wpasuppository itself though, I'm entirely happy for that to be seeded
<Keybuk> want it in the minimal seed
<Keybuk> along with wireless-tools
<whiprush> Keybuk: a month ago you were kind of against this whole nm .6 thing. And at the time I thought you were crazy.
<Keybuk> I'm still against it
<whiprush> Now I'm thinking you were probably right
<Keybuk> :o)
<whiprush> now people assume that dapper will have working gui WPA support and whatnot.
<whiprush> now you guys are kind of screwed. :-/
<Keybuk> my experience of NM is not good
<Keybuk> it's some of the worst code I've ever seen
<Keybuk> I really do not like it
<Keybuk> but hey
<Keybuk> it's the second coming apparently
<Keybuk> so I guess we have to ship it
<whiprush> though, I think those guys from the community working on the problem is a good thing.
<whiprush> Pity they weren't around like, 2 cycles ago. :-/
<Amaranth> what ever happened to wifigui or whatever that project was called
<Amaranth> it an ubuntuforums community project thing, written in python
<Amaranth> gtkwifi
<Keybuk> what did it do?
<Amaranth> http://sourceforge.net/project/screenshots.php?group_id=132677&ssid=18920
<Amaranth> not dapper material but maybe something to take a look at for dapper+1
<Amaranth> last release was almost a year ago though :/
<Amaranth> May 15th, 2005
<Amaranth> comments like "good job bsoft, works perfectly and is lighter weight the networkmanager" make me interested
<Keybuk> that looks like what NM is trying to solve
<Keybuk> and I don't see how that's addressed the permissions problems
<Amaranth> sure, it has it's own problems
<Amaranth> but it actually seems to work :P
<infinity> mdz: Was requesting X SWAT membership and then deactivating same an intentional thing?
<mdz> infinity: that is the only way for me to add bug contacts right now
<mdz> by temporarily joining the team
<infinity> Oh, special.
<CarlFK> Kamion: preseed - partitioner is stuck in a loop or something 
<CarlFK> http://dev.personnelware.com/carl/temp/Mar31/d/
<_TomB> http://ubuntuforums.org/
<Amaranth> is it trying to be gentoo?
<_TomB> it's changed again
<Amaranth> purple and green, same as the first time i looked
<LaserJock> hmm, some sort of sick April 1st joke?
<_TomB> purple and musturdy color for me
<YokoZar> does anyone here know something about reprepro?
<zyga> hello
<zyga> did you guys see the news, microsoft is buying cannonical!
<_TomB> lol
<nictuku> ah ok
<Burgundavia> zyga: got a link?
<zyga> Burgundavia: yes, just a moment
<zyga> Burgundavia: http://www.shibumi.org/eoti.htm
<CarlFK> pasteland went crazy: http://paste.ubuntu-nl.org/11211
<jsgotangco> happy april fools
<CarlFK> tee hee
<CarlFK> apparently if you submit the jibberish, you get goodness: http://paste.ubuntu-nl.org/11212
<Burgundavia> CarlFK: rot13
<CarlFK> should that "Brokenpackages" be bugged?
<Treenaks> omg... slashdot HAS ponies!
<Treenaks> And we don't!
<TomB|> ubuntuforums.org has powerpuff girls
<Treenaks> TomB|: that's not a pony!
<Lathiat> haha
<TomB|> hehe
<jsgotangco> haha
<HiddenWolf> slashdot is pink?!
<Treenaks> UbuntuStudio, a wiki for using Ubuntu Linux for a digital music studio, redirects to FruityLoops.com, a Windows application.
<Treenaks> ... http://www.nubuntu.org/
<TomB|> hehe
<jsgotangco> yeah go canonical go to a suing spree
<Treenaks> What's it with all these sites turning pink and ponyish :)
<Treenaks> Lots of sites seem share the same joke :)
<TomB|> because its the new trend
<jsgotangco> its becoming pretty lame after a few hours though
<Treenaks> jsgotangco: yeah..it's only funny once.. if at all
<jsgotangco> the first one i saw was with /. and it was funny
<jsgotangco> but when i saw the forums have strange colors i wasn't that much surprised at all
<jsgotangco> there's also the one with planet debian having linus
<spoob> Is jdub aruond these days? Or is he away overseas?
<Kamion> Mithrandir: I believe you just give ports/daily as the source rather than daily and publish-release will work the rest out for itself
<Kamion> Mithrandir: oh, and you'll probably need to say ARCHES='hppa ia64 sparc'
<sivang> morning all
<maswan> Mithrandir: sorry, went to bed early. the cron job is running now, and ubuntu seems to have been synced, working on kubuntu now
<giftnudel> is flight 6 the daily from yesterday?
<Kamion> giftnudel: yeah
<giftnudel> thanks
<jsgotangco> my download suddenly died
<jsgotangco> :/
<ogra> no flight 6 announcement ? or is my mailserver dizzy ?
<maswan> ogra: waiting for me
<ogra> ah, k
<maswan> my mirroring should be done in 15 minutes or so, then it is up to Mithrandir, Kamion or someone else to push out a release
<maswan> cdimage is horribly slow to mirror from, otherwise the croned mirror would be done by now
<ogra> i didnt want to be pushy :) just noted there is no announcement yet :)
<maswan> I meant to be pushy wrt cdimage slowness. ;)
<ogra> heh
<infinity> Not everyone has more free academic bandwidth than they know what to do with. :P
<torkel> infinity: just wait till we have 10G :-)
<ogra> torkel, wait until we drop CDs and switch to DVDs :P
<giftnudel> oh, if you install, pay attention that you don't select the wrong partition to be formatted
<giftnudel> (at least for me, it did select the wrong as default ...)
<HiddenWolf> Hm, isn't cdmirror a hefty little machine?
<HiddenWolf> main archive is still pretty snappy.
<infinity> HiddenWolf: Nothing wrong with the machines, the bandwidth out of the DC is crap.
<HiddenWolf> infinity: oh, fun. 
<infinity> (You may think it's great, but you don't have as much of a pipe as maswan does...)
<HiddenWolf> infinity, I couldn't care less, I have a straight 100mbit line to the isp across the street, which has a mirror. :)
<HiddenWolf> Living in a converted office building across the street from my isp. ;)
<HiddenWolf> I was just imagining what the dapper release would do, when we look at the stats from breezy. :)
<Mithrandir> maswan: yeah, I noticed.  No worries. :-)
<Mithrandir> Kamion: ok, let's try that, then. :-)
<Mithrandir> ogra: the announcement was sent several hours ago, but it needs to be approved.
<ogra> ah
<maswan> Mithrandir: done
<maswan> infinity: you guys should get more mirrors to take the load, and perhaps a mozilla-style bouncer for the images? :)
<Mithrandir> maswan: we should, yes.
<maswan> Mithrandir: Can it be the "OMG!! Ducklings!" release? ;)
<Mithrandir> maswan: haha.  Dragonettes if so.
<HiddenWolf> Mithrandir: any plans in that direction?
<HiddenWolf> Mithrandir: the site was dead-slow for a week after breezy, imagine what Dapper will do.
<maswan> Mithrandir: pfft. the poll on the fridge clearly showed that the dapper drake is a duck. :)
<Mithrandir> HiddenWolf: not that I know of.  Flight 6, while announced today was released yesterday and is a very real release.
<Znarl> maswan : It's slow not because of the data centre bandwidth but because one of the cdimage machines has poor disk IO.
<Znarl> maswan : We plan to upgrade the machine in the next few days.
<maswan> Znarl: Ah, ok. Great.
<Mithrandir> maswan: that's just the plebe talking.
<maswan> Znarl: What kind of new storage are you putting in?
<Mithrandir> Znarl: now that we're doing some sort of QoS-ing, would it be possible to put maswan in the "free bandwidth" class?
<maswan> Mithrandir: That'd only help network though, not disk
<Znarl> Mithrandir : We are not yet doing QoS either. 
<Mithrandir> maswan: true, but I think network is a limiting factor.
<Mithrandir> Znarl: we're just limiting bandwidth in total?  Or did we stop?
<Znarl> We've stoped limiting bandwidth.  We had to limit before because a flight was released and a number of security updates at the same time.  We gave the bandwidth to the security updates and limited the flight.
<Mithrandir> ah, ok.
<maswan> Znarl: Btw, you guys could go back to dumping more of cdimage releases traffic our way. We don't mind. :)
<Znarl> There's a fast full mirror of cdimage here : http://ie.archive.ubuntu.com/ubuntu-cdimage/
<maswan> Znarl: ftp.heanet.ie?
<Znarl> maswan : Yes.
<Mithrandir> Znarl: is that triggered by publish-release too?
<Mithrandir> uh, sync-mirrors
<Mithrandir> sorry.
<Znarl> Mithrandir : Not setup as a trigger or push mirror yet.
<Znarl> http://mirror.mcs.anl.gov/pub/ubuntu-iso/DVDs/ is a mirror in the US that has flights too.
<Mithrandir> hmm, we didn't do ubuntu-server flight 6.  Should we?
<jsgotangco> id love to test that
<Kamion> no harm in it, if you want to
<Kamion> although post-flight-6 uploads have already started
<Mithrandir> it'd be fairly untested, but I don't see why not.
<Mithrandir> sure, but that seems to mostly be gui stuff
<Kamion> installer too
<Mithrandir> hm, ok
<Kamion> should be safeish though
<Mithrandir> we do kubuntu ports too?
<Mithrandir> I'll just tag it and we can we test it and see if it's good.
<Kamion> not so far, AFAICR
<Mithrandir> 1 15 * * *      for-project kubuntu cron.ports_daily; for-project kubuntu cron.ports_daily-live
* Kamion stands corrected by his own code. :)
<Mithrandir> doesn't seem to be in the tree, though
<Mithrandir> also, should we do flight releases of the DVDs?  (Next time, that is)
<Kamion> not so keen on that for bandwidth reasons
<Mithrandir> ok
<Kamion> no objection to people actually starting to *test* the damn things, but ...
<Mithrandir> we could just publish the torrents and rsync urls for them?
<Kamion> s/ and rsync urls/ I think
<Kamion> s/ and rsync urls// I think (er, yeah, mornings)
<maswan> Mithrandir: or just publish the ie location? ;)
<maswan> well, you might want to ask the mirror admin first, of course
<Mithrandir> maswan: if they're fine with that, we could.  Else, it would be a bit harsh. :-)
<Mithrandir> we don't have ubuntu-server live images? ;-P
<maswan> I think they put that on the main image, but I'm not sure
<maswan> server live = debsums, chkrootkit, other forensics
<Mithrandir> jsgotangco: do you want to test before or after I mark ubuntu-server as flight-6?
<Znarl> cdimage preformance should improve shortly.
<Mithrandir> there, ubuntu-server flight 6 released too
<maswan> Mithrandir: should I mirror those too?
<Mithrandir> maswan: I doubt we'll have a ton of interest, but please do feel free.  Both ports and ubuntu-server would be nice to have.
<maswan> hmm.. I don't have an rsync line for ubuntu-server yet.
<Mithrandir> it's just edubuntu with s/edubuntu/ubuntu-server/.
<maswan> Mithrandir: Yeah, syncing now. Ports first.
<Mithrandir> thanks.
<Kamion> did you just build ubuntu-server on the spot and release it? :)
<Kamion> or were there sensible dailies available?
<maswan> "If it mkisofss, it's releasable - If it boots, it's perfect"?
<Kamion> speaking of, I hope you at least rebuilt amd64 ... :)
<maswan> Mithrandir: So, 1M/s sync speed, you can guess when it's done
<Mithrandir> Kamion: I just built it and released it.
<Harti> hello. is the package "wpasupplicant" now per default installed?
<Mithrandir> based on the "what could possibly go wrong?" assumption
<jsgotangco> ekk
<jsgotangco> didnt notice
<jsgotangco> i'm grabbing it anyway
<jsgotangco> sorry
<Mithrandir> jsgotangco: if it's utterly broken, I'm not fussed to do flight-6.0.1 for ubuntu-server.
<jsgotangco> no worries at least we'll know
<Kamion> Mithrandir: cool.
<Kamion> Harti: it will be in dapper; technical problems with the archive maintenance software mean it isn't quite installed by default yet
<Kamion> (AFAIK)
<Harti> Kamion: ok, thx
<Kamion> (bug 37156, if you care)
<Ubugtu> Malone bug 37156 in launchpad-upload-and-queue "can't change sections or priorities with change-override.py" [Major,Confirmed]  http://launchpad.net/bugs/37156
<Kamion> oh, hey, actually it's not blocked on that right now because somebody moved wpasupplicant to standard, so a new ubuntu-meta upload would sort it out
<Kamion> but we really need to get the above bug sorted because wpasupplicant should be alongside wireless-tools in minimal
<ploum> Hello..
<ploum> I think this bug must be adressed before Dapper release :
<ploum> https://launchpad.net/distros/ubuntu/+bug/37579
<Ubugtu> Malone bug 37579 in Ubuntu "Ubuntu doesn't urge enough users to contribute to OpenSource" [Normal,Unconfirmed]  
<j^> ploum 2006-04-01
<jsgotangco> nice advocay bug though
<jsgotangco> i'd download an ubuntu server to fix that :P
<G0SUB> ploum: is that a april fools joke?
<tseng> hm, my network manager is insiting on using /sbin/wpa_supplicant
<tseng> not /usr/sbin
<tseng> thusly failing on all encrypted networks
<Lure> tseng: that is correct - install wpasupplicant from offical repo 
<tseng> Lure: ah, I knew it had to be that pre stuff
<tseng> i checked version on nm only
<Lure> tseng: I think even version is the same - remove and install again and it should work
<ploum> G0SUB, guess...
<tseng> thanks, couldnt find a bug report.
<slomo_> hm, what happened to the buildds?
<G0SUB> ploum: oh! I am a fool ... I rejected the bug :(
<Kamion> slomo_: looks like they all fell over with socket errors - https://launchpad.net/+builds
<Kamion> infinity: around?
<giftnudel> where can I file bugs against the live cd? (under which component)
<Kamion> giftnudel: casper if it's the live CD startup process; if it's a particular application on the live CD, then just file on that application
<giftnudel> cool
<giftnudel> thanks
<giftnudel> than I will write some bug reports
<giftnudel> then
<jsgotangco> lol someone from the united nations list picked up the nubuntu joke
<ploum> jsgotangco, what is the nubuntu joke ?
<Yagisan> ploum: it's supposed to be a "security tools" version of ubuntu
<ploum> G0SUB, any objection that I mark this bug as confirmed for today ?
<Kamion> er ... nubuntu has been around for a while longer than April 1
<ploum> well, it seems so.. I don't understand where the joke is
<jsgotangco> Kamion, yeah but check out the site
<jsgotangco> Canonical has asked for nUbuntu to Cease Development
<Kamion> ah, heh
<Yagisan> how long is it supposed to take gconf2 (2.14.0-1ubuntu1) to set up ? it's 20 minutes so far on a 2GHz amd64
<azeem> Yagisan: gconf2 doesn't compute the answer to the question about life, the universe and everything
<tseng> jsgotangco: is that the same guy who thought canonical was going to fund and host his project any day?
<jsgotangco> nahhh
<tseng> there are two projects called nubuntu, btw
<jsgotangco> oh?
<tseng> yeah.
<_ion> azeem: Of course not, that would be rather redundant.
<_ion> Instead it is computing the question.
<Pygi> _ion: hi :)
<_ion> Hi Pygi
<_ion> What's up?
<tseng> jsgotangco: .com and .org
<bpuccio> wait, the nubuntu thing is an april fools? (I saw it on digg hours ago, but was waiting to see what the word from canonical was, but didn't see anything on the lists)
<Pygi> _ion: nothing, made a joke on forum about nm ;)
<_ion> pygi: URL please? :-)
<jsgotangco> tseng, oh that's him then, doing the joke (.org)
* _ion is lazy.
<Yagisan> azeem: it would be nice if it works soon. I'd like to use that box for motu related work
<Pygi> _ion: sec pls
<Pygi> http://ubuntuforums.org/showthread.php?p=881226#post881226
<Pygi> http://ubuntuforums.org/showthread.php?p=881416#post881416
<Pygi> find it somewhere pls
<Pygi> I'll be back asap ;)
<Kamion> bpuccio: guess
<azeem> Yagisan: is it hung, or does it take up CPU tie?
<azeem> time
<_ion> pygi: Hehe.
<_ion> Thomann (a company i ordered monitor speakers from) made a nice april fools joke. http://johan.kiviniemi.name/pictures/monitorit/
<Yagisan> azeem: I think it's hung
<G0SUB> ploum: please go ahead
<G0SUB> _ion: what is the joke in damaged speakers?
<maswan> Mithrandir: ports done, doing server now
<Pygi> _ion: by monday, we need 0.6.2 ;)
<_ion> g0sub: Well, i ordered non-damaged speakers. :-)
<G0SUB> _ion: bah!
<_ion> The speakers in the pictures are actually the ones they sent after i returned the ones they sent initially  those were faulty. :-D
<G0SUB> agh!
<G0SUB> _ion: the fault was with the courier guys I guess
<_ion> g0sub: I wouldn't blame the postal service. Thomann had neglected to put some protective styrox over the speakers inside the cardboard box.
* Pygi waits for ion_s commented
<G0SUB> I see
<G0SUB> _ion: is it a german company?
<_ion> g0sub: Yes.
<_ion> pygi: I'll try to build and upload j's 0.6.2 package to tonio's repo today.
<G0SUB> _ion: have you tried Bose?
<Pygi> _ion: no, no need for that ;) 
<Pygi> we need patches for 0.6.1 to 0.6.2
<Pygi> that's all
<_ion> You mean diff -Nru the-nm-0.6.{1,2}-tree?
<_ion> g0sub: Bose?
<G0SUB> _ion: yeah, Bose speakers
<_ion> g0sub: Nope, i haven't.
<G0SUB> _ion: have you heard about them?
<_ion> g0sub: I have heard the name, but i don't know much about them.
<Yagisan> w00t. now metacity hangs in unpack
<Pygi> _ion: that, and we need to make sure the patches we applied against 0.6.1 are if some needed, make them work if they don't
<_ion> pygi: Hm, okay...
<Pygi> notice the "hm" :P
<azeem> lifeless: I've uploaded the first few plugins now
<G0SUB> _ion: http://bose.com/
<lifeless> azeem: sweet
<maswan> Mithrandir: done.
<Mithrandir> maswan: yay, thanks
<maswan> Mithrandir: thanks to Znarl too, for fixing me a bigger straw to suck bits through. :)
<Mithrandir> maswan: mmm, straws.
<bpuccio> http://episteme.arstechnica.com/eve/ubb.x?a=tpc&s=50009562&f=67909965&m=207098011 The Bose FAQ (it started on usenet I think)
<jsgotangco> fabbione, it seems we're getting some similar bugs regarding widscreen lcds for laptops not getting the correct rez with Intel 915?
<fabbione> jsgotangco: possible...
<fabbione> jsgotangco: ask them for the DEbuggingXAutoconfig thing
<jsgotangco> yeah consolidating them as well
<giftnudel> fabbione: what do you need exactly
<giftnudel> everything on the wiki page?
<fabbione> giftnudel: yes
<giftnudel> fabbione: good, one nautilus bug to go, then I will do that
<giftnudel> oho, ok, I have a 2 installs on my laptop, on just done with dapper, and one old one
<giftnudel> with the installation, I get a hda1 mountpoint in /media/, which is on the desktop with the label "/", this is rather confusing
<giftnudel> (I thought it was my root system, while it was the other installed system)
<giftnudel> now my question: is this rather a installer bug, a desktop bug or something else?
<j^> seb128 have you seen the problem with xv overlays beeing hidden by a gray square? the video only shows up after using something like alt-tab
<seb128> no
<j^> since i see it in gtk apps it might be some gtk issue
<seb128> I doubt of it
<seb128> do you have a bug number?
<j^> i.e. i have a simple pygtk based player using gst
<j^> that has that problem
<j^> did not file a bug so far
<j^> possibly i am just missing to call some repaint function,
* j^ googles
<Thingi> is anyone having trouble burning flight 6 on os x?
<giftnudel> fabbione, jsgotangco: bug 37596 with all information regarding the i915 laptop
<Ubugtu> Malone bug 37596 in xorg "Flight 6: Wrong resolution with live cd (i915, 1400x1050)" [Normal,Unconfirmed]  http://launchpad.net/bugs/37596
<Mithrandir> giftnudel: what does sudo ddcprobe on the live cd say?
<giftnudel> Mithrandir: before I do that, any other commands/files to recover (need to reboot)
<Mithrandir> giftnudel: depends on what that gives you back. :-P
<giftnudel> hehe
<giftnudel> ok, I will boot my other pc
<giftnudel> the cd needs way to much time to boot ...
<Mithrandir> I know.
<Mithrandir> it helps if you have plenty of memory though
<ogra> many widescreen displays report the wrong size (i cant use 1280x800 on any of my laptops here with the new liveCD)
<jsgotangco> yeah i'm collecting them they seem to be all i915
<ogra> nope, i have one with ati and one nvidia based one 
<jsgotangco> ohh
<ogra> both fell back to ask the resolution in breezy and now simply go to 1024x786
<jsgotangco> seems prevalent among wxga displays
<ogra> yep
<Mithrandir> I wonder if it'd helped if we used the newer edid/ddc vesa calls
<ogra> what bothers me is that we had the resolution question in the old CD, and the new one has no possibility to set a widescreen res at all ...
<ogra> if we could have widescreen vesa modes and preseed from this, we could have them in the gfxboot menu ...
<ogra> probably something to look at for dapper+1
<Mithrandir> get me a few of the machines with problematic chipsets and I might be able to fix it.
<ogra> s/vesa/framebuffer/
<ogra> you wont get more out of dccprobe than the display reports :)
<ogra> both i have here dont report it right ... it will need either manual override or a new form of probing ...
<Chipzz> ogra: yea, grub was totally fucked up on my widescreen laptop
<giftnudel> Mithrandir: what was the command you wanted?
<Chipzz> ogra: actually, I think it is *necessary* for dapper
<ogra> btw, for both the dexconf configuration on install falls back to ask for the resolution, i wonder how daniels solved to find out that it doesnt report it right
<Mithrandir> giftnudel: sudo ddcprobe.  From the console, not in X.
<Chipzz> ogra: grub did *not work at all* on my widescreen laptop, had to boot with livecd and fix
<giftnudel> Mithrandir: which lines do you need
<ogra> Chipzz, i fear its a bit to late to add such a feature in dapper, i guess it will require intrusive changes to dexconf ...
<giftnudel> Mithrandir: highest resolution is 1280x1024, edidfail
<ogra> Chipzz, a normal grub should just use textmode (80x24)... which shoult work everywhere 
<Mithrandir> giftnudel: edidfail is kinda bad.
<Chipzz> ogra: everyone installing dapper on a laptop with widescreen may have that problem... do you want to risk fucked up bootloaders for all these people who install dapper?
<Mithrandir> giftnudel: all of it, preferably.  Redirect it to a file and upload it to pastebin.com or something.
<giftnudel> ok, I'll do that
<ogra> Chipzz, grub is fine on all my machines here ...
<Chipzz> ogra: I couldn't even boot windows...
<ogra> usplash looks a bit stretched though
<Mithrandir> Chipzz: grub is in text mode.
<Chipzz> well local problem then I guess
<Chipzz> Mithrandir: text mode is the default? hrrmm
<ogra> yep
<jsgotangco> yeah
<Mithrandir> Chipzz: yes, unless you upgraded in the short time span when we tried the gfx stuff in which case you still have it.
<Chipzz> Mithrandir: ah then that will have been the problem...
<giftnudel> Mithrandir: http://pastebin.com/634209
<Mithrandir> giftnudel: it's probably the "cut out the best mode because that often doesn't really work".
<giftnudel> Mithrandir: the fun part is, that doing a sudo dkpg-reconfigure xserver-xorg and just enter on each step does give 1280x1024
<Mithrandir> giftnudel: that's basically what the live cd does, though
<giftnudel> Mithrandir: well, xresprobe shows 1400x1050
<j^> pam_keyring would be nice to have... it depends on pam 0.99 though(http://www.hekanetworks.com/index.php/publisher/articleview/frmArticleID/25/staticId/31/)
<jsgotangco> ciao guys goodnight
<siretart> is there a trick with rsync iso images?
<siretart> my rsync gets always stuck on the last few bytes
<ogra> siretart, works for me 
<ogra> (i use a script for rsyncing http://people.ubuntu.com/~ogra/rsyncer.sh )
<siretart> ogra: for me, rsync gets always stuck at about 90% :(
<ogra> strange
<ogra> which options do you use ? 
<siretart> rsync --partial --progress  --size-only --stats  cdimage.ubuntu.com::cdimage/releases/dapper/flight-6/dapper-live-i386.iso .
<ogra> hmm 
<ogra> did you try archive mode ? ( -a )
<siretart> hm.. cdimage.ubuntu.com now resets my connection :( - I assume it just hates me now
<ogra> or you have an rsync zombie somewhere 
<ogra> c.u.c only accepts max two connections from one IP 
<siretart> that could be it. I killed some rsync connections
<siretart> well, have to leave anyway now. will try again on monday
<siretart> cu
<ogra> bye
<zul> heylo
<infinity> Kamion: pong.  I assume it'a sbout the builddmaster deciding all the build-slaves were offline?... Drunk, but fixing nonetheless.
* Pygi points sabdfl at network-manager-kde in universe ^_^
<Kamion> infinity: right ...
<Kamion> happy drunkenness :)
<infinity> Kamion: Fixed, cheers (in more ways than one).
<Chipzz> ok, I know this isn't a support channel, but does anyone know what is up with firefox? It renders characters with a small width too small, like i and l (http://nighty.safehex.be/fle.png)
<Chipzz> anyone else seeing this?
<slomo_> that's a known problem and not only in firefox... but i don't have a bug number at hand ;)
<Chipzz> it started after fontconfig pulled in the extra set of fonts...
<slomo_> Chipzz: bug #34178
<Ubugtu> Malone bug 34178 in pango1.0 libpango1.0-0 "Pango kerning is bad" [Normal,Unconfirmed]  http://launchpad.net/bugs/34178
<gouchi> Hi
<gouchi> is there a reason why Ubuntu didn't have iteractive boot ? (pressing I at boot time)
<Chipzz> probably cause no-one has come around to implementing it yet?
<gouchi> ah ok, because it will be good feature
<Chipzz> and most likely because ubuntu is debian-based and debian doesn't have it either ;)
<gouchi> yep ;-)
<Chipzz> is there any reason to have it appart from "I want it"? ;)
<Chipzz> afaik that's a rh specific feature, too :)
<gouchi> I didn't want, it was a friend who is using Ubuntu request it
<gouchi> Chipzz : gentoo has, mandriva too IIRC
<Chipzz> what would be nicer is to have usplash being able to accept input at all ;P
<gouchi> yep
<Chipzz> like the passphrase for the key to mount a partition
<infinity> Chipzz: Usplash can handle input fine, if you know what you're doing.
<Chipzz> infinity: hrrm I should rephrase: allow a nice input box or sth ;)
<infinity> (It won't echo it back, but who wants a passphrase on their screen anyway?)
<Chipzz> are there actually other use cases for input in usplash?
<infinity> Yeah, hitting <enter> to eject the CD on reboot in the livefs. ;)
<infinity> (This is where we first started looking at "hey, can the thing accept input?" a few days ago.
<infinity> )
<Chipzz> yea, but you don't need an input box or anything for that ;)
<Chipzz> you can just echo "Press enter to eject cd-rom" and read an enter ;)
<infinity> You don't NEED an input box for passphrases either, I suspect.
<Chipzz> no not /need/, but it would be nice, since you're actually typing more than one character
<infinity> Same argument, "Type your passphrase for foo:", read, check, echo response, carry on.
<Chipzz> uhu, except if you want stars to appear instead of your pasphrase
<infinity> Proper password entry (despite current trends in GUIs) shouldn't echo anything anyway, IMO.
<Chipzz> that's a matter of taste I guess :)
<infinity> It's not terribly helpful to security to announce to everyine that your password is exactly N characters long.
<infinity> eevryone, too.
<infinity> Or whatever.  Drinking and typing don't mix.
<Chipzz> gdm does it too ;)
<infinity> Yes, hence my reference to "GUI applications"
<giftnudel> infinity: you can reboot the lifecd with enter
<giftnudel> but it doesn't show
<infinity> You won't see "Password: *****" in many CLI apps, and you won't see it in usplash, unless my job is threatened over it.
<giftnudel> see bug 37602
<Ubugtu> Malone bug 37602 in initscripts "Flight 6: Live CD doesn't reboot" [Normal,Unconfirmed]  http://launchpad.net/bugs/37602
<infinity> giftnudel: Yes, this is being fixed in the next week, based on evidence gathered in the last few days. :)
<giftnudel> ok
<giftnudel> anyway, have to go
<infinity> jdong: Dude, register with nickserv, I can't send you private messages.  Tsk.
<infinity> jdong: Err, wait, it's me who's not logged in.  Feh.
<inflate> hello, somebody know how I can 'remaster' (k)ubuntu install CD? I want to add/remove some packages from CD to fill my needs, any help?
<lionelp> inflate: https://wiki.ubuntu.com/InstallCDCustomizationHowTo may help you
<ploum> lionelp, arf... I was looking for it !
<ploum> (nice name ;-) )
<lionelp> ploum: :-)
<inflate> lionelp: I've tried it, for some reason, it cannot install kubuntu-desktop package
<inflate> in the modified image
<inflate> every thing is installed except the main thing :(
<inflate> there is no other way?
<sladen_> infinity: crypted swap/root requires a password and usplash is in the initramfs so is already running by then
<nyu> hi
<nyu> what is the equivalent of incoming.debian.org in ubuntu?
<ploum> nyu, there is not AFAIK
<ploum> because repository is updated as soon as the package is build
<ploum> unlike debian where the repository is updated once a day
<nyu> ah
<ploum> (I might be wrong but it's how I understand things)
<crimsun> nyu: we upload to upload.ubuntu.com, but there's no public-facing view for it.
<nyu> but, the packages stay there for a while?
<crimsun> at most 6 minutes.
<nyu> a recently closed bug refers to an upload that isn't in ftp.ubuntu.com yet
<nyu> #37011
<nyu> or maybe i miss-understood it
<lionelp> nyu: it is said that it will be uploaded after Flight 6 released
<lionelp> and flight 6 as been released few hours ago
<nyu> uhm yes, i got the notification mail during the last hours too :)
<lionelp> so maybe it has not been released yet
<lionelp> s/released/uploaded/
<nyu> ah
<nyu> so what does the post with a changelog entry mean?
<crimsun> it means it's being uploaded
<crimsun> and in this case, it _has_ been uploaded.
<crimsun> crimsun@garnish:~$ apt-cache madison langpack-locales
<crimsun> langpack-locales |     2.3.13 | http://archive.ubuntu.com dapper/main Sources
<nyu> aah, ftp.ubuntu.com is not the master site? :)
<nyu> uhm curious.  there's source but no .deb
<crimsun> https://launchpad.net/+builds/+build/181349
<nyu> ah, you do source-only uploads and then buildds pick it?
<crimsun> yes.
<nyu> i see
<Amaranth> how else would you do it?
<crimsun> in Debian, binary packages are uploaded.
<Amaranth> wha?
<nyu> Amaranth: source-only uploads are forbidden, even
<Amaranth> uh
<Amaranth> april fools?
<nyu> no
<crimsun> Amaranth: take a look at incoming.debian.org
<Amaranth> what do you need a buildd for then?
<nyu> Amaranth: for the other arches
<nyu> normaly uploads just contain binaries for one arch
<Amaranth> ok so you upload source + the binary for your arch
<Amaranth> that seems...fragile
<HiddenWolf> complicated, too
<nyu> I don't like it either, but there are some advantages
<bddebian> nyu: When did you come to the "Dark Side"? :-)
<nyu> bddebian: I didn't, it's just a temporary visit ;)
<nyu> I'm contributing a pair of minor fixes
<Kamion> crimsun: bit longer than 6 minutes, but yeah
<Kamion> our archive cycle is an hour at the moment; if you upload just as the publisher run is starting, it'll take about an hour and 20 minutes to be visible
<nyu> hi Kamion 
<Kamion> Amaranth: the reason for it is that it forces developers to actually build it on at least one architecture - evidence from Ubuntu suggests that if you don't do that, developers will happily upload crap that doesn't build ...
<Kamion> nyu: hi
<Amaranth> Kamion: hehe, good point
<Kamion> nyu: the buildds were down for a while earlier; they're probably still catching up
<nyu> Kamion: ah fine.  I could check with the source already, so no prob
<Kamion> oh, but it was only uploaded at 19:40 anyway
<Kamion> ftp.ubuntu.com is the master (well, the master mirror; there's a hidden real master) although we normally call it archive.ubuntu.com
<bddebian> nyu: Ah :-)
<nyu> bddebian: one of them is done, it seems.  now i'm just waiting for Kamion to upload localechooser ;)
<Kamion> oh, yeah, I have some localechooser stuff queued up ...
<mgalvin> is there a way in lauchpad to determine how many bugs where closed during a given timeframe?
<mgalvin> i though it would be nice, since bug guts are flying all over the place, to include those numbers in the next release overview to provide an example of how much effort is *really* going into polishing dapper
<nyu> Kamion: :)
<Kamion> nyu: righto, fix on its way (will need a debian-installer upload before it takes effect, though; that'll be before Flight CD 7 at the latest)
<nyu> Kamion: nice, thanks!
<nyu> flight cd 7 == dapper 6.07 ?
<pitti> nyu: no, dapper will be 6.06 (the final release)
<nyu> ah.. so, 7.00 ?
<pitti> nyu: the flight CDs are intermediate and (semi)regular testing versions for the final dapper version
<nyu> ahm
<pitti> nyu: no, flight 7 is something like 6.06 alpha7
<nyu> ah i see
<Kamion> ("Flight" is the collective noun for drakes (whether dragons or ducks) ...)
<nyu> heh
<nyu> funny
<Kamion> urgh, localechooser's totally changed in trunk, that'll be fun to merge after dapper
<Kamion> oh well, will worry about that later
<Mithrandir> Kamion: again?  Urg. :-(
<Kamion> Mithrandir: well, this time at least it's a simplification
<Mithrandir> that might fuck us, though.  Given that we make it a fair bit more complicated.
<Kamion> nah, languagelist simplification
<Kamion> I think we can deal
* Kamion -> West Wing
<Kamion> (watching, not visiting ...)
<Mithrandir> oh, that'd be very nice, yes
<pitti> Kamion: soccer/football/whatever?
<Mithrandir> pitti: political soap opera
<G0SUB> on what basis does the update-manager decide if a restart is required or not?
<pitti> G0SUB: it doesn't. package maintainer scripts have to request this
<G0SUB> pitti: hmm, how?
<_ion> A postinst script may run /usr/share/update-notifier/notify-reboot-required
<G0SUB> is there anyway to know which package is requesting the reboot?
<G0SUB> btw, the Flight6 page says that the notifications and tooltips now have drop-shadows ... I am on dapper but I don't see those
<SteveA> anyone interested in looking into a problem getting vnc on dapper to talk to a mac mini?
<pajama> Hi, I'm trying to install Dapper Flight 6 booting with PXE... but it fails with an error while copying files: "base-installer: error: exiting on error base-installer/kernel/failed-install"
<pajama> it looks like it's the package linux-restricted-modules-2.6.15-19-386
<pajama> I have mounted the ISO to be served from Apache... and in the Apache logs I'm getting a 404 for "/ubuntu/dists/dapper-updates/" 
<pajama> the installer is looking for that directory in the ISO, but it is not there
<pajama> has anybody had any luck installing Dapper F6 using PXE??
<pajama> sorry, I've just read the Topic.... sorry..... I'm going to #ubuntu
#ubuntu-devel 2006-04-07
<dieman> wheres the tip jar for networkmanager?
<dieman> ;)
<Lure> dieman: fix some bugs... ;-)
<dieman> heh
<Pygi> has anyone tried running knm?
<BlueHeron> hi can somone help me i was told i have a memory leak in gam_server ?
<BlueHeron> it is using 500MB of memoy
<desrt> has benc gone awol?
* desrt misses the constant kernel image upgrades :)
<bluefoxicy> when is it appropriate to start discussing dapper+1 goals?
<bluefoxicy> on the ubuntu-devel@ list
<LaserJock> bluefoxicy: probably better to write a spec first, IMO
<neuralis> bluefoxicy: if you have a spec written, anytime's fine.
<bluefoxicy> LaserJock, neuralis:  I don't have a spec ready.  I would rather gather more information, especially as I have nfc what I'm really doing at the moment ;)
<bluefoxicy> Right now I'm trying to get pam_ldap to work with an openldap server (slapd) running behind me, just trying to get experience setting up centralized authentication
<bluefoxicy> and it ain't working
<bluefoxicy> and I'm at the same time thinking of the changes that would be needed to make ubuntu integrate well with ldap.. which I'd want to discuss on the list to get a better idea of before writing up a spec
<bluefoxicy> at least, that's the short version of it
<LaserJock> bluefoxicy: maybe sounder would be better then
<bluefoxicy> sounder?
<LaserJock> the mailing list
<LaserJock> it is for bouncing ideas around
<bluefoxicy> uhh... direction?
<bluefoxicy> should I subscribe or can i just throw a mail at some address?
<neuralis> bluefoxicy: re: pam_ldap, see http://times.usefulinc.com/2005/09/25-ldap
<neuralis> bluefoxicy: there's already a spec that covers this, but we deferred it to dapper+1.
<bluefoxicy> neuralis:  ah.
<LaserJock> bluefoxicy: https://lists.ubuntu.com/mailman/listinfo/sounder
<neuralis> bluefoxicy: see https://launchpad.net/distros/ubuntu/+spec/network-authentication
<bluefoxicy> neuralis:  integration with users-admin and the installer et al?
<neuralis> bluefoxicy: it's all in the spec.
<neuralis> bluefoxicy: rather, look at the spec for details; i haven't looked at it since ubz.
<bluefoxicy> nice
<neuralis> 'evening, Burgundavia
<Burgundavia> neuralis: salut
<CarlK> apt-get install libxt-dev = unmet dependencies. - is this the place to report? https://launchpad.net/distros/ubuntu/dapper/+package/libxt-dev
<Burgundavia> CarlK: assuming you are looking at a flight6 default install, yes
<CarlK> Burgundavia: how about yesterdays daily? ;)
<Burgundavia> CarlK: that works
<Amaranth> it's installed here
<CarlK> Amaranth: did you add repos?
<Amaranth> universe and multiverse
<CarlK> oh... do I need deb-src?
<Chipzz> CarlK: normally not,no
<CarlK> !paste
<CarlK> what am I missing? http://paste.ubuntu-nl.org/11286
<bddebian> CarlFK: Why do you have breezy and dapper repos mixed in your sources.list?
<CarlK> oh crap... cuz I am an idiot?
<bddebian> Nah, that's my job :-)
<CarlK> and thatwould be what I was missing
<CarlK> glad someone is doing there job :)
<bddebian> Heh
<Eleaf> hi!
<Eleaf> hi
<Eleaf> In the Ubuntu LiveCd (Dapper or any), where is the file stored that expresses the system hostname and default username?
<Eleaf> I know hostname is /etc/hostname ... But what defines this?
<Eleaf> On the actual livecd.
<Eleaf> Any ideas?
<Kamion> Eleaf: it's set in code in various scripts in /scripts/casper-bottom/ inside /install/initrd.gz (which is a gzipped cpio archive)
<Kamion> Eleaf: probably easier to do 'apt-get source casper' and look at that
<Eleaf> alright
<Eleaf> hmm
<Kamion> dapper differs from breezy here, we reorganised the live CD a fair bit
<Eleaf> alright, is that for dapper?
<Kamion> yes
<Eleaf> I'm not seeing a scripts dir, is that in the base?
<Kamion> have you unpacked /install/initrd.gz?
<Eleaf> yes, I just get another initrd thing.
<Eleaf> what is the best way to unpack it?
<Kamion> make a temporary directory, cd into it, 'zcat /cdrom/install/initrd.gz | cpio -id'
<Eleaf> great, one sec.
<Kamion> like I say, 'apt-get source casper' is easier ...
<Eleaf> Ok I'm in initrd
<Kamion> if you want to modify it, you can build and install a modified casper .deb, then 'update-initramfs', and copy out the /boot/initrd.img-`uname -r` you get
<Kamion> (that's what we do in the live CD build process)
<Eleaf> mmk
<Eleaf> ah.
<Eleaf> I think I got it
<Eleaf> is it scripts/casper-bottom/18hostname for the hostname I'm assuming?
<Kamion> yeah
<Eleaf> Sweet, thank you very much.  Just curios, what corrilation does casper have to do with this?
<Eleaf> curious*
<Kamion> note that update-initramfs will clobber your existing initrd.img in /boot; you may want to keep a backup
<Eleaf> correlation
<Kamion> (the new one should work anyway, it's just over-the-top)
<Eleaf> humm
<Kamion> casper is the package that implements the live CD boot process
<Eleaf> I see
<TheMuso> Speaking of which, Kamion, what flags are used for building the squashfs filesystem?
<Kamion> TheMuso: none, just mksquashfs
<TheMuso> Ok thanks
<glick> hello?
<glick> anyone here?
<sladen> there are always people here...
<sladen> just that sometimes they maybe asleep and shouting might wake them up
<glick> i have a question, there is a package, in ubuntu that no longer works, but it is never upgraded even though an upgrade exists, so effectively the package that comes with breezy is usless
<neuralis> package name?
<glick> gtk-gnutella
<neuralis> i'm seeing 0.95.4-1 in breezy and 0.96.1-0 in dapper. looks normal. what specific problem are you having?
<glick> neuralis: the .95x versions no longer connect to the network, they purposefully dont connect to the network anymore, when i run it, it says, this version of gnutella no longer works, please upgrade to .96x
<neuralis> so you're saying you want 0.96 for breezy? you'll have to make a request to the backports people to provide a backport for you.
<neuralis> otherwise, you'll have 0.96 in universe once you upgrade to dapper.
<glick> i mean considering that the one that ships with breezy no longer works, having a working version would be nice
<glick> c'mon no one should have to wait 4 months to have a working gnutella
<glick> upgrade their entire os?
<crimsun> there is no chance that 0.96.1 will be stuffed into breezy proper. breezy-backports is a possibility.
<glick> cant it be offered as an upgrade?
<Eleaf> you could compile it yourself or run a normal binary
<neuralis> glick: we will not introduce a whole new software version as a breezy update.
<neuralis> glick: ask for a backport, it's precisely what backports are for
<glick> neuralis: but what ships is dead software
<neuralis> glick: that's beside the point.
<neuralis> glick: backports are meant to solve this kind of problem, so ask for one, or wait until dapper (which is out in about 2 months, not 4).
<crimsun> glick: that is upstream's decision. There is technically nothing _broken_ with the version that ships in breezy proper. The viable recourse is breezy-backports, and there's a procedure for that.
<glick> so how an i make a request for a backport?
<neuralis> glick: http://backports.ubuntuforums.org/wiki/index.php/Requesting_A_Backport
<glick> looks like someone already filed a request for it
<glick> a while ago
<neuralis> glick: unfortunately, that's all that can be done at the moment.
<shadeofgrey> are any ogf the main developers for yubuntu currently here and awake?
<Lure> sladen: any new idea for bug 34592? I would really like this one to get away...
<Ubugtu> Malone bug 34592 in gfxboot-theme-ubuntu "dapper flight 5: install menu never comes" [Critical,Confirmed]  http://launchpad.net/bugs/34592
<Pygi> shadeofgrey: what happened?
<shadeofgrey> pygi:  well...  actually i just found out that i have like lewss than 6 months to live
<shadeofgrey> and id like an opportunity to say thanks tio them directly before i die
<shadeofgrey> if its noit too much troublke
<Pygi> uh :-/
<shadeofgrey> just...do me a favor
<shadeofgrey> give some of them my email addfress
<shadeofgrey> (shadeofgrey@gmail.com)
<Mithrandir> shadeofgrey: did you mean to say yubuntu or ubuntu?
<sladen> Lure: yeah, my personal hunch is that it's to do with crappy Video BIOS, or IDE enumeration
<shadeofgrey> ubuntu
<Mithrandir> shadeofgrey: well, I'm here and a member of the core team.
<Lure> sladen: it seems like infinite loop to me, as the fans are going on like mad...
<Mithrandir> shadeofgrey: sounds quite bad. :-(
<shadeofgrey> mith:  great...  can we speak in private for a minute?
<sladen> Mithrandir: if you'd like to tell lots of people and have it recorded so that everyone can see if (regardless of whether they're currently awake), you could email the sounder@lists.ubuntu.com which would be a wonderful testimonial to receive there
<sladen> s/Mithrandir/shadeofgrey/
<shadeofgrey> ah excellenty
<shadeofgrey> ill send an email straight away
<Lure> sladen: do you know which package is involved at that time of boot process (gfx-boot?) as I would like to inspect changelogs
<Lure> between Flight4 and first daily build I spotted the problem 20060312
<infinity> Lure: gfxboot and gfxboot-theme-ubuntu.
<Lure> infinity: thanks - I have seen that only theme has changed between Feb 17 and Mar 12
<infinity> Lure: Which would explain why the bug is already assigned to the theme.
<mdke> hiya. sorry to be slightly off topic, but it's a sunday :) I'm trying to install gnome-doc-utils from cvs, and it is complaining about two missing m4 macros: glib-gettext.m4 and intltool.m4. Any idea if these come with ubuntu somewhere?
<neuralis> mdke: they do. packages intltool and libglib2.0-dev
<mdke> neuralis, lovely, i'll try that: thanks
<neuralis> yep.
<Kaloz> hmz
<Kaloz> something is foobared in dapper, but no idea what package has the bug really
<neuralis> what's the problem?
<Kaloz> basically bringing up the wireless interface with wpa fails for the first time, as af_inet isn't loaded by default
<Lure> sladen: you are probably right regarding VGA BIOS - all have ATI cards from x700/x800 line
<Kaloz> so wpa_supplicant exits with an error. then dhclient is starting, af_inet gets loaded, and on the second try wpasupoplicant is runnig fine
<neuralis> kaloz: sounds like a NM issue? i suggest you talk to pygi or _ion and see what they make of it.
<Kaloz> okay, thanks :) I can simply use /etc/modules, but this isn't The Right Way (tm) to fix it
<Lure> Kaloz: or siretart - he is the wpasupplicant guy
<Kaloz> well, to be honest, i was wondering why the hell isn't this in the kernel statically :)
<Lure> Kaloz: bug 37697 looks similar to your problem
<Ubugtu> Malone bug 37697 in wpasupplicant "wpasupplicant only authenticates immediately after atheros kernel modules freshly loaded." [Normal,Unconfirmed]  http://launchpad.net/bugs/37697
<Kaloz> Lure: nope, that's a problem in the madwifi driver. I'm on centrino gear anyways :)
<Lure> Kaloz: is it really af_inet or af_packet? see bug 37121
<Ubugtu> Malone bug 37121 in wpasupplicant "ifupdown script 0_wpasupplicant assumes CONFIG_PACKET=y" [Normal,Fix released]  http://launchpad.net/bugs/37121
<Kaloz> ah,l af_packet, right.. it's too early in the morning here
<Lure> Kaloz: see also related bug 36634
<Ubugtu> Malone bug 36634 in wpasupplicant "fails to autostart using the if-preup.d script" [Normal,Fix released]  http://launchpad.net/bugs/36634
<Lure> siretart thinks it should be fixed with latest wpasupplicant...
<stockholm> are there backports for newer wireless drivers to breezy available somewhere?
<Kaloz> ah, the new version was uploaded yesterday night
<stockholm> preferably packaged?
<stockholm> mjg59: are you ubuntu's wireless driver person? are there backports of newer drivers (acx111 chipset) available?
<mdke> stockholm, they come with the kernel, so I think it is unlikely
<stockholm> yeah.
<Burgundavia> stockholm, new versions do not get backported, except in one specific case (Mozilla Firefox, due to upstream boneheadedness)
<infinity> 99% of problems people have with acx* drivers are usually issues with selecting the wrong firmware anyway.
<mdke> yeah, i have one of those cards, such a pain
<stockholm> infinity: i have a dlink G650+ here, which is rather new but can work with linux
<mdke> ah, that's the one I have
<infinity> stockholm: I suspect it will work fine with both the drivers in breezy and dapper, but needs a certain firmware image that either a) we don't ship, or b) we don't select by default for your PCI ID.
<stockholm> mdke: ah, how did you get it to work?
<mdke> it works with breezy, if you find the right firmware, I think.
<infinity> If you could figure out what that was, we'd love a bug. :)
<mdke> but i don't think it is shipped
<infinity> (so we can match PCI ID to firmware, and make it Just Work)
<stockholm> mdke: i have here a howto where you need to extract firmware from the windows drivers
<stockholm> once the binary file was installed this card here got mighty hot
<stockholm> so i am not 110% sure it is alife any more.
<stockholm> is that "normal"?
<mdke> i haven't used my card since hoary, but it worked ok then
<infinity> It's normal if the firmware cranks the Tx/Rx power sky high...
<infinity> Hopefully, this HOWTO isn't telling people to use AP firmware on desktop/laptop cards.
<stockholm> infinity: well, i never saw that before.
<infinity> (Since APs tend to have much better cooling solutions, and tend to have higher Tx levels)
<stockholm> no, it seems to mix the firmware supplied with the windows driver with a linux wrapper/driver
<enyc> Hrrrm.... ? where are UVF-exception requests made/listed ?
<stockholm> mdke: horay seems old for this card... i thougt this model was rather new
<mdke> stockholm, no, I don't think it's very new
<stockholm> *shrug*
<stockholm> i would like a precompiled package, but with the windows firmware that is unlikely i guess
<stockholm> mdke: um, do you remember if you have a acx111 or acx100 chipset?
<stockholm> the firmware i find here http://stef.tvk.rwth-aachen.de/~nazgul/debian/acx100/ only has firmware for acx100, not for 111
<stockholm> i just had a kernel crash with the lastest kernel for breezy (security upgraded). is that a known problem?
<stockholm> the system now crashes after max one minute after boot.
<neuralis> crashes, as in, panics?
<stockholm> neuralis: i dont see any oops, X covers it
<stockholm> neuralis: crashes as in not responding to anything (or pings or so) except for hard reset
<stockholm> mousepointer does not move, etc
<stockholm> when was that newest kernel security upgrade released?
<neuralis> if it's max one minute after boot, can you switch to a console and wait for it to freeze?
<stockholm> yes, i guess i can
* stockholm does that
<stockholm> it only crashed after i switched back to X. no luck.
<infinity> stockholm: dapper ships (lots of) firmware for acx100 and acx111... See /lib/firmware/`uname -r`/acx/readme.txt
<stockholm> and it is rather save to install drapper, since you are only polishing, right?
<infinity> Pretty much, yeah.
<neuralis> infinity: do you know why keyserver.ubuntu.com only syncs with 3 SKS peers?
<infinity> You've lived on the edge with sid before, I'm sure, this isn't much different.
<stockholm> cool, will try that, then
<infinity> neuralis: No idea.
<neuralis> infinity: that's elmo?
<stockholm> infinity: it is a friend of mine, he usually lives not on any edge. (c:
<stockholm> thanks for helping.
<infinity> neuralis: Indeed.
<neuralis> infinity: cool, i'll poke him. thanks.
<iceman> hi everyone
<iceman> I have a bug in dapper but I don't know in which component or package I have to report it
<iceman> I'm trying to install a network printer (SMB)
<Lure> iceman: you can report it w/o package on somebody from bug team will help
<Lure> iceman: see #ubuntu-bugs
<Lure> s/on/and/
<iceman> Lure: thanks but it's easier for devellopers if I file it correctly rightaway ;-)
<stockholm> infinity: what is the aptsources.list line for drapper?
<TheMuso> stockholm: What component?
<stockholm> TheMuso: i want to upgrade from breezy to drapper. the whole sytem
<TheMuso> Just replace every instance of breezy with dapper in /etc/apt/sources.list.
<neuralis> stockholm: $ sed -i s/breezy/dapper/ /etc/apt/sources.list; apt-get update; apt-get dist-upgrade
<stockholm> neuralis: i tried that with drapper instead of dapper. (c:
<stockholm> lol
<stockholm> ok
<stockholm> oh and by now it crashed again. not a fat chance that the update would go through in that time.
<stockholm> no oops, either. 
<azeem> stockholm: is this a notebook and do you have laptop-support on?
<stockholm> azeem: it is a notebook, yes
<neuralis> stockholm: mvo has a very good dist-upgrade tool that i recommend you use instead, unless you're very comfortable with the command line and fixing any problems that might arise during a dist-upgrade.
<azeem> stockholm: on battery or mains power?
<stockholm> neuralis: i am quite compfortable with the commandline,yes
<stockholm> azeem: main power
<azeem> ok, nevermind then
<stockholm> neuralis: i am used to fixing upgrade problems in debian, is it much differnet with ubuntu?
<stockholm> harder, better problems? (c:
<neuralis> stockholm: no, but the dist-upgrader tool can benefit from your testing.
<neuralis> stockholm: http://people.ubuntu.com/~mvo/dist-upgrader/
<stockholm> neuralis: right, good poiont.
<neuralis> on that note, i'm off to sleep. cheers, all.
<stockholm> but not on this box, it crashed again just now.
<stockholm> perhpas it is just dying. old one...
<stockholm> good night
<neuralis> stockholm: fyi, dist-upgrader instructions are here: https://lists.ubuntu.com/archives/ubuntu-devel/2006-January/014700.html
* neuralis *poof* in a sleepy smoke..
<mdke> stockholm, acx111 was my card
<iceman> Lure: It's quite bothering me: nobody's answering on ubuntu-bugs, and it doesn't feel right to report a bug without having searched if it wasn't already filed
<Pygi> _ion: around?
<mvo> stockholm: I'm on the phone right now, but can we talk about this in a bit?
<mjg59> stockholm: Not really, and not as far as I know
<giftnudel> mvo: is the update-manager from your site broken?
<giftnudel> let'a 
<giftnudel> ah, let's say this differently, for me it's broken
<mvo> giftnudel: broken in what way?
<giftnudel> mvo: I click on dapper upgrade, upgrade again, it downloads something and get a index out of bounds exceptio
<giftnudel> n
<giftnudel> mvo: it says: Preparing installation, the error is in the downloaded dapper.tar.gz
<mvo> giftnudel: what version of update-manager do you have installed?
<giftnudel> mvo: 0.42.2ubuntu9~bp1 according to dpkg -s update-manager
<ogra> ~bp1 ??
<giftnudel> I added "deb htp://people.ubuntu.com/~mvo/backports/update-manager /" to sources.list, according to the mail in ubuntu-announce
<Pygi> Mithrandir: I wanna talk to you about LDAP, so when you have time ^_^
<Ekushey> jdub: u there?
<mvo> giftnudel: hm, that should be the right one. could you please run it from a terminal and paste the exception to a pastebin?
<giftnudel> mvo: the exception comes in a dialog box, but I will do
<giftnudel> mvo: http://pastebin.com/635668
<ogra> mvo, you dont use the backports naming scheme ? 
<mvo> giftnudel: interessting, thanks. can you add your sources.list please
<giftnudel> of course
<ogra> (~breezy1 instead of ~bp1)
<mvo> ogra: this is just a private repo for now, but I should change this when it goes into the official backports/updates repo
<ogra> :)
<mvo> giftnudel: it seems to be choking on one entry in it
<ogra> mvo, btw OT, "realkauf" sells unicycles for 49 
<mvo> ogra: woooahhhh! get one ;)
<mvo> ogra: so we can have fun together at the next conf :)
<ogra> i was pondering ... dunno where a real is around here 
<giftnudel> mvo: http://pastebin.com/635692
<mvo> ogra: are you interessted in learning it? 
<ogra> mvo, if time permits :) i'm not sure if i have *any* spare minute the next months :)
<mvo> ogra: yes, a big problem :/ but I find it refreshing (for mind and body) to spend a bit of time on something else then ubuntu
<ogra> mvo, yep, but my sparetime will be "help susus take over the empire and prepare the move to kassel" the next months, no idea how much time is left there
<mvo> ogra: *ohhh* right
<mvo> giftnudel: thanks!
<ogra> but given that it wont break if its stored in the garage, i'll probably buy one :) i guess i wont get one this cheap usually
<mvo> giftnudel: anything in /etc/apt/sources.list.d/ ?
<giftnudel> mvo: I don't have that directory
<mvo> ogra: no, they are usually more expensive. it will be great fun to bring on to the next conference :)
<mvo> giftnudel: ok, thanks
<ogra> mvo, given we dont have to fly to the northpole for it or something :)
<ogra> who knows where it will be :)
<mvo> so true :)
* ogra sends hugs and kisses to Seveas, thats soo cool to finally have the forum gateway solved on -users
<mvo> giftnudel: strange, locally it seems to be working. what is the output of /var/lib/update-manager/meta-release?
<giftnudel> http://pastebin.com/635707
<giftnudel> mvo: ^
<mvo> giftnudel: looks fine too. very strange
<giftnudel> mvo: let me reboot the system, there might be a problem with a recent update?
<mvo> giftnudel: could you please file a bug against update-manager and assign it to me? include the three files? I don't have that much time today for it :/
<giftnudel> ok, I'll do that
<mvo> giftnudel: thanks
<mvo> giftnudel: the error indicates that there is a problem with reading your sources.list, but testing it locally didn't caused a error here
<giftnudel> mvo: ok, I will file the bug, a reboot didn't change anything (as expected ...)
<giftnudel> mvo: bug 37716, anything in there you want?
<Ubugtu> Malone bug 37716 in update-manager "Dapper upgrade chokes on sources.list" [Normal,Unconfirmed]  http://launchpad.net/bugs/37716
<stockholm> mvo: ping
<stockholm> mvo: back from lunch
<_ion> pygi: Pong
<stockholm> indish.... goood
<mvo> stockholm: I'm on the phone (again :), can we talk in ~5min?
<Pygi> _ion: N-M was indirectly mentioned in Tux ^_^
<stockholm> mvo: i am around for now
<_ion> pygi: Tux?
<Pygi> _ion: hm, LInux magazine? ^_^
<_ion> Ok. :-)
<stockholm> i look for an iso for dapper (i386). where are they?
<TheMuso> stockholm: Suggest you try flight 6 which can be found at cdimage.ubuntu.com/releases/dapper
<stockholm> TheMuso: thanks
<Pygi> _ion: bah, gah ^_^
<sladen> Lure: can you fix the bug report so that it reads  usplash/gfxboot/vgafb problem on ATI x700/x800  (you understand that the error is)
<Lure> sladen: I can change the summary, however I still do not understand what the error is ;-)
<sladen> Lure: I suspect it's because gfxboot is using 640x480 and/or not resetting the mode afterwards
<Lure> sladen: "install hangs on ATI x700/x800" and leave it on gfxboot?
<Lure> sladen: possible, but nothing beside the theme changed, so what could cause such regression?
<sladen> Lure: so, an earlier gfxboot theme worked?
<sladen> Lure: what happens if you follow the other questions on the bug report (eg, tell gfxboot to use text-mode)
<Lure> sladen: Flight 4 works
<Lure> and also 2 and 3 ;-)
<TheMuso> 
<sladen> Lure: oh right "flight5/6 theme breaks ATI..."
<Lure> sladen: no way to switch to text console, as it does not get that far
<sladen> Lure: what bug number is it?
<Lure> bug 34592
<Ubugtu> Malone bug 34592 in gfxboot-theme-ubuntu "flight 5&6: install hang on ATI x700/x800" [Critical,Confirmed]  http://launchpad.net/bugs/34592
<sladen> Lure: so it might be the kernel---can you remind me of the bug number and I have a feeling there were a few suggestions to try
<Lure> flight 4 has/had the issue that it installed only in text, due to unreleated bug  31974
<Ubugtu> Malone bug 31974 in gfxboot-theme-ubuntu "Kubuntu Dapper Flight 4 - Boot menu boots into a kernel panic" [Normal,Fix released]  http://launchpad.net/bugs/31974
<Lure> sladen: Kamion told me that it cannot be kernel, as it does not get started yet
<Lure> funny is that in both bugs you have more or less same reporters (=HW)
<sladen> Lure: that's what we'd expect.  It's only an issue with that particular hardware (eg. buggy hardware/firmware/BIOS)
<Lure> sladen: true, but we changed something in theme that now triggers it (and did not in Flight < 5)
<sladen> Lure: if you press Escape and then [enter]  ("yes, exit graphical mode and return to text mode"), and then press enter to boot the system, does that work?
<Lure> sladen: with Flight 5/6 I do not get to menu at all - just kubuntu image on top and fans go to full
<Lure> that was the issue on Flight4 (I am just doing install from F4 BTW)
<Lure> I was thinking to build custom CD with only gfxboot-theme change with F4, but not sure if that is possible 
<sladen> Lure: so, pressing escape, enter, enter was a workaround for F4
<sladen> Lure: but Flight5/6 just hang completely before the menu appears?
<Lure> exactly
<Lure> machine hangs as no key works, just power button 
<Lure> and it looks like a infinite loop as fans start to go full speed in couple of seconds
<sladen> Lure: yes, using a rewritable CD you should be just able to overwrite the /isolinux directory
<sladen> or wheve-ever it is
<Lure> sladen: problem is that I do not have CD/RW at home 
<Lure> I will try one CD-R, but I expect it will work
<tseng> Mithrandir: Kamion wow guys I am really impressed with Espresso in Flight 6
<azeem> is mmapr available in dapper?  It seemed to be in xserver-xorg-core in breezy, but no more?
<azeem> seems not
<fabbione> azeem: mmapr?
<azeem> http://openfacts.berlios.de/index-en.phtml?title=Tifm21-howtodump
<azeem> probably there is some other way to dump that information
<fabbione> azeem: if it's missing from a package it's  a regression for breezy (assuming it's not deprecated upstream)
<fabbione> azeem: could you please file a bug and assign it to me?
<fabbione> i will look at it on monday
<azeem> seems to be a case of random-binaries-not-makeing-the-switch-to-modular
<azeem> like ioport as well
<azeem> but ok
<fabbione> azeem: sure.. if you find them just put the list somewhere and i will look at it
<fabbione> unfortunatly our Contents files are broken
<fabbione> and it takes time to figure the stuff out
<azeem> well, it's debateably those should be in xorg I guess
<fabbione> yeah but if they were there before, they can still land in some xutils-extra-crap
<azeem> they look like some helper programs to figure out PCI information, but I doubt xorg support them officially
<azeem> ok
<ogra> oh, fabbione is around ...
<ogra> fabbione, you dont happen to have a bzr branch with thew 
<sivang> re all
<sivang> hey ogra , Fade 
<ogra> silo change to ltsp ?
<sivang> oops
<sivang> fabbione, even
<bddebian> Heya ogra, sivang
<bddebian> ogra: Do you happen to know if there is any website I can use to deposit to you?
<ogra> bddebian, nope, i dont think so, the bank/account data should be correct now though
<ogra> you 'll need to do a normal transfer i fear ...
<fabbione> ogra: the what?
<fabbione> ogra: i just added silo to the Depends:
<fabbione> nothing more
<ogra> ok
<fabbione> it was only, as i wrote in the changelog, to make it installable
<fabbione> and allow people to hack easily on it
<bddebian> ogra: Damn, OK, thanks
<ogra> its just that i missed to add it to my branch manually ... gets a bit tricky to merge the debian branches :) but i'll work around that 
<fabbione> ogra: just readd it in a commit?
<fabbione> it's not like it is soooo complicate
<ogra> fabbione, yep, thhats what i'm doing 
<fabbione> :)
<fabbione> -> movie
<fabbione> later
<fabbione> (bye sivang)
<ogra> its just that debian synced and made changes without the dep added :)
<ogra> i'll merge the debian sparc enhancements in my devel branch btw 
<ogra> in case you want to look at it
<fabbione> ogra: even if i wanted, i don't have time or desktop machines to look at
<fabbione> ogra: i only have server hw here for sparc
<ogra> oh, ok
<ogra> but you know the sparc community better than me :)
<j^> gstreamer-properties/gstreamer sound input is broken
<ogra> WFM
<j^> found the bug 34597
<Ubugtu> Malone bug 34597 in gst-plugins gstreamer-alsa "Cannot record using alsa + gstreamer framework" [Normal,Unconfirmed]  http://launchpad.net/bugs/34597
<j^> ogra gst-launch-0.10 alsasrc ! flacenc ! filesink location=test.flac  works for you?
<ogra> j^, also hier hoer ich das micro bis zum feedback pfeifen wenn ichs selecte 
<ogra> whoops
<ogra> sorry for the german 
* ogra is typing too much german today :)
<j^> geht schon
<ogra> heh
<j^> just tested on 2 cards that load i810 and both do not work
<ogra> it works on my ibook and my amd64 based acer laptop ...
<crimsun> j^: pastebin ~/.asound*
<j^> crimsun No such file or directory
<crimsun> j^: default [fresh]  dapper install & current?
<j^> crimsun up to date dapper, not a fresh install
<crimsun> j^: no /etc/asound.conf, correct?
<j^> crimsun nop
<crimsun> j^: asoundconf list
<crimsun> perhaps we should move this to #ubuntu+1
<j^> asoundconf list
<j^> Names of available sound cards:
<j^> I82801CAICH3
<j^> Modem
<crimsun> ah
<crimsun> yes, let's migrate this to #ubuntu+1
<bddebian> Is katie down, slow, etc?
<mjg59> Is it possible to add meta targets in Malone?
<ogra> mjg59, meta targets `
<ogra> ?
<mjg59> ogra: Things that don't correspond to a real package
<ogra> ah, like adding Provides to packages ? 
<mjg59> ogra: Sort, of, yeah. I'd like there to be a "suspend" thing that bugs can be filed against, before being reassigned to either the kernel or acpi-support or X or whatever
<ogra> ah, cool idea !
<wasabi> launchpad able to add enhancement bugs?
<wasabi> Not finding a "bug type" thingy
<mdke> wasabi, you have to do it after you file it, I think
<wasabi> mvo: https://wiki.ubuntu.com/GAptI
<Pygi> joy, Pan recoded in C++ instead of Python
<Eleaf> hello
<Pygi> KaiL: so many duplicate bugs :-/
<soumyadip> is the Ubuntu wiki theme copyrighted or under any restrictions ? Can we use a similar theme for ubuntu-in.org ?
<sivang> anybody has an idea if cdrecord can skip it's "last chance to quit" and waiting some seconds before startin a burn?
<mvo> sivang: IIRC it is not without patching the source, but it is possible that the source is patched already. suse had (IIRC) patches for this
<mvo> and it's pretty trivial anyway
<sivang> mvo: you sure there is no cmd line arg for that? that sounds way too much fuss for something so simple in other programs :)
<sivang> mvo: questions, who do I need to convince to have this patch applied to our cdrecord?
<sivang> mvo: *question is,
<wasabi> mvo: https://launchpad.net/distros/ubuntu/+spec/apt-third-party
<wasabi> in case you ever want to take a look at it.
<wasabi> Or have time.;)
<nictuku> or both
<nictuku> :-)
<mvo> sivang: http://paste.ubuntu-nl.org/11328
<mvo> wasabi: did you updated it :) ? 
<sivang> mvo: how did you have it so handy? :)
<wasabi> Just rearranged stuff slightly.
<wasabi> And made a spec.
<mvo> sivang: apt-get source cdrecord :)
<wasabi> going to try to get it done this time, though heh
<wasabi> if life permits.
<mvo> wasabi: nice! let's try to get it in for dapper+1
<sivang> mvo: ah, nice. thing is, he says there that it breaks other things, you say that SUSE are using it successfuly ?
<sivang> mvo: auch, this make me wanna wrap some of the libs inside the cdrtools for python :)
<mvo> sivang: I was involved in a network frontend for cdreocrd some years ago and we patched it out too. I fail to see where it might cause problems
<mvo> sivang: run away from that!
<sivang> hehe, why ?? :)
* sivang dreams of being able to directly eject , load , blank etc from python
<wasabi> Need to figure out some way of extracting the information from a GPG key without adding it to a keyring
<sivang> well, acutally, nautilus-cd-burner might provide this. still I check it's code and it uses cdrecord as well
<sivang> mvo: okay, thanks, do you think I should bring this up to the TB meeting?
<mvo> wasabi: what exactly do you mean? you can probably use gpg directly for this 
<wasabi> Yeah, trying to figure out the command options. The gpg key I pull out of hte .apt file, I need to get the name of it.
<wasabi> And a list of signatures.
* sivang fixes himself wait free package of cdrecord
<sivang> at least for testing HUB it will be better.
<Mithrandir> Pygi: (re ldap) tomorrow?
<Mithrandir> tseng: thanks. :-)
<raphink> hi there
<raphink> is there a reason why we keep a 10 weeks old svn version of cups instead of using rc1 which was released a few days ago?
<raphink> I know we're in UVF, but shipping an svn when the rc is out is a bit stupid isn't it?
<raphink> or is it just that we forgot to keep aware of CUPS devlopmt ?
<tseng> raphink: ask pitti on a weekday
<raphink> I guess I shall
<tseng> raphink: w/o less accusation
<raphink> he's not here currently
<raphink> tseng: hehe ;)
<raphink> tseng: i'm not accusing :)
<raphink> we have been having issues with this svn version in Kubuntu
<tseng> I am sure he is aware of CUPS development :)
<raphink> hmm 
<raphink> well beta2 has been out
<raphink> then rc
<raphink> and we still have a random svn
<Riddell> raphink: UVF is the exception, I think he's asking for an exception
<raphink> ok
<raphink> that's good
<Riddell> raphink: http://www.cups.org/str.php?L1527
<raphink> the longest it takes to get the exception, the less bugs will be fixed in it
<Riddell> raphink: if you want to test a current svn to see if that last comment fixes the issues that would be great
<raphink> fixing bugs in an obsolete svn is not so great
<raphink> Riddell: it's RC1 out now
<raphink> :)
<Riddell> see comment at the bottom of that link, I don't know if that's in rc 1
<sivang> raphink: I think he meant to do that anyway, but ask him indeed.
<raphink> sivang: I'll wait for him to be online
<raphink> sivang: the thing is that Riddell pinged a KDE dev about this issue with kdeprint not supporting cups 1.2
<raphink> who said that implementing it on an svn basis in Ubuntu when rc1 is out has no real sense
<tseng> you are accusing again
<raphink> huh?
<tseng> and inferring that you know better than the maintainer.
<raphink> no
<raphink> I'm reporting what a KDE dev said
<tseng> mm, ok sorry
<raphink> about a but we have with KDE and CUPS 1.2
<raphink> tseng: I am in no way willing to accusate anyone, and I'm sorry if you understand it this way
<sivang> tseng: we're jumpy doay aren't we :)
<tseng> sivang: most days, I think.
<sivang> tseng: hehe, low on that caffine ! :)
<wasabi> There any GUI interface to add a key to apt-key which can be invoked from python?
<wasabi> ie "Are you sure you want to trust Foo for software installs."
<wasabi> I see the interface in Synaptic anyways.
<wasabi> There a way to invoke that and only that?
<wasabi> actually iy doesn't ask confirmation (it should)
<mvo> wasabi: no, currently there is none, but it wouldn't be too hard to add one to gnome-software-properties
<wasabi> Almost got gapti done already heh
<wasabi> Simple pops up a dialog. Rest needs to be done thru synaptic, etc.
<wasabi> gksudo doesn't really work very well for this. =/
<wasabi> Cant' figure out how to pass command line options to it.
<wasabi> nor send stdin
<nictuku> I'm sure it is possible
<nictuku> wasabi, if you need a hand, talk to kov which is the author of gksu(do)
<Pygi> Mithrandir: sure, no problem at all ^_^ (re: ldap)
<Pygi> Mithrandir: I'll ping you once I'm online tommorow
<wasabi> mvo: I updated it now. It works. It needs cleanup. I am not a python wizard.
<wasabi> But it does what's advertised.
<wasabi> Feel free obviously to take a look. ;)
<wasabi> mvo: I suspect something like this is going to want some "discussion" before it's added. The security considerations, etc. Also, if it's not promited as part of the platform, it's useless. What's the appropiate forum for that?
<nictuku> wasabi, https://wiki.ubuntu.com/FeatureSpecifications may be helpful, I think
<Kamion> sladen: I'm fairly sure that that gfxboot bug is an infinite loop in the theme code, judging from the symptoms
<Kamion> I wasn't able to get time to look at it before Flight 6, but I'll try to put out some test images for people to try with suitable tracing code in them
<sladen> Kamion: okay.  I haven't had a chance to look into it yet, I didn't realise theme code could have executable code... (I assumed it was just images and positions)
<Kamion> Lure: will you be around at some point tomorrow or Tuesday to iterate through some tests with me? since I can't reproduce it myself, having somebody to teleoperate on a fairly short cycle would be good
<Kamion> sladen: theme code is ALL executable code
<Kamion> it's a postscript-like language
<Kamion> and bloody hard to get right
<sladen> ahhh...
<Lure> Kamion: sure - during daytime I am at work (=harder), but evenings can be done
<Kamion> could've been my addition of parsing for gfxboot-foreground and gfxboot-background
<Lure> (I will also by some CD-RW media to be able to modify)
<Kamion> Lure: what's your timezone?
* Kamion <- UTC+0100 currently
<Lure> UTC+2 currenlty (CET)
#ubuntu-devel 2006-04-08
<Kamion> ok, that should be doable, maybe Tuesday rather than tomorrow though (Monday night is often karate training night for me)
<Lure> s/by/buy/
<Kamion> right, bedtime, thanks in advance
<Lure> Kamion: thank you
<YokoZar> What's a good way to see what packages depend or recommend another package?
<Lure> apt-cache depends <package> and apt-cache rdepends
<YokoZar> thanks Lu
<YokoZar> Lure
<Lure> sorry rdepends is reverse depends and you are asking for recomment
<Lure> s/recomment/recommend/ - time for bed ;-)
<YokoZar> Good night
<neuralis> Kamion: do you want espresso test reports to u-d@, by private mail, or in malone?
<bddebian> infinity: ping?
<bddebian> Does Debian want to know about .desktop files?
<LaserJock> they should ;-)
<robertj> Debian doesn't even know about guis ;)
<bddebian> hehe
<robertj> btw, we can have an official count of our "upgrade-a-holics" by measuring the decrease in use after sarge and then the increase after the next release ;)
<robertj> (or we could if we actually had a way to measure general usage to begin with, security updates perhaps? ;)
<infinity> Ahh, daylight savings time, thou hast bested and confused me once again.
<infinity> bddebian: pong.
<bddebian> heh
<bddebian> infinity: WTF happened to lamonts buildlogs?  Ugh.  Anyway, can you tell if xfonts-marumoji showed up in NEW?  Or is there somewhere I can look in LaunchPud?  I didn't get an accept or reject from katie
<jdub> http://nerdvana.org.au/steve/gallery/displayimage.php?album=7&pos=2
<sladen> bddebian: https://launchpad.net/distros/ubuntu/dapper/+source/PACKAGENAME
<sladen> bddebian: https://launchpad.net/distros/ubuntu/dapper/+source/PACKAGENAME/+builds is a better URL to start at
<infinity> Actually, that's a pretty shit URL to start at, since this package hasn't been uploaded for eons.
<infinity> (Only the data since the switch to launchpad is even close to accurate and useful)
* infinity scratches his head.
<infinity> Oh, duh.
<infinity> bddebian:  xfonts-marumoji (0.2-6ubuntu1) unstable; urgency=low
<infinity> bddebian: What's wrong with this picture? ^^^^^^^^
<bddebian> fuck
<bddebian> Why didn't I get a rejected?
<infinity> And yes, soyuz isn't (currently) producing reject mails on incorrect distribution.
<infinity> Bug.  It's failing the uploads instead of rejecting them.
<infinity> (known bug, at that)
<bddebian> Well I've been "out of the loop" for a while :-(
<desrt> irc -- the ultimate fixed-width medium
<dieman> rock
<dieman> networkmanager worked with WPA PSK
<dieman> now to try with WPA Enterprise tomorrow morning
<bddebian> infinity: Dumb question.  Can I re-upload with ubuntu1 version?
<infinity> bddebian: Yes, failed and rejected uploads have never made it far enough into the queue to be tracked/counted.
<bddebian> Great, thx
<desrt> nm hates me.
<bddebian> That's OK, everyone hates me :-)
<bddebian> sladen: BTW, thanks but those links don't show me shit about a failed/rejected upload :-)
<`anthony> I was going to try out a livecd on a bunch of random Dell laptops here at work. Should I use Flight 6, or a daily snapshot?
<infinity> `anthony: There won't be much difference between Flight-6 and a daily anyway, given that we just released Flight-6...
<`anthony> infinity: ok dokey.
<`anthony> should I log a report somewhere with the results once I'm done? There's about 6 different models of dell laptop I can get my hands on easily...
<infinity> `anthony: https://wiki.ubuntu.com/LaptopTesting may be of interest.
<`anthony> Yep. Although that wants people to install Dapper - if I drop a pre-release of Dapper over the installed XP on the salesfolks' laptops, they're going to be molto cranky :)
<`anthony> livecd testing isn't _as_ good, but it's better than nothing.
<nictuku> anyone willing to test nwu before I go nuts and announce it on -server and -devel lists?
<infinity> nictuku: If you want testers, you might try asking when Europe isn't all asleep. :)
<nictuku> infinity, I count on the Americas and Asia :-D
<bddebian> Fuck, I did it again with apt-listbugs
<jdub> bddebian: make a uch script in your ~/bin that does The Right Thing :)
<bddebian> jdub: They aren't my changelog entries and I keep forgetting to check that.. :-(
<bddebian> I worry about the version and ignore the distro..
<infinity> ogra: Do you have any urge to make ltsp-* installable on hppa and ia64?
<bddebian> nictuku: What did you need tested?
<nictuku> package installation and check that there are no show stoppers
<bddebian> Sorry, for which package?
<nictuku> nwu-agent (depends on python-sysinfo) and nwu-server. None of them are in official reps
<nictuku> I'm creating a repository right now
<bddebian> Ah, OK
<nictuku> nwu description is in https://dev.ubuntubrasil.org/trac/nwu/wiki
<infinity> ogra: Nevermind, I'll do it when I have some hppa hardware locally to play with.
<dholbach> good morning
<jdong> is the debtags postinst problem a known issue?
<jdong> I'm wondering if I should LP it
<bddebian> Goddamnit, why is bittornado bug assigned to MOTUs when it's a main package?
<dholbach> malone bug 37794
<Ubugtu> Malone bug 37794 in debtags "Installing debtags results in a ConsistencyCheckException" [Normal,Unconfirmed]  http://launchpad.net/bugs/37794
<dholbach> simply searching in malone does help :-p
<jdong> dholbach: thanks, sorry for my laziness
<dholbach> don't worry
<jsgotangco> stll awake eh dholbach?
<jsgotangco> or early riser
<dholbach> no... couldn't sleep anymore
<infinity> Had to walk the dog at 4am? :)
<desrt> dholbach is not looking forward to having to fix dpkg
<dholbach> infinity: no... the dog is sleeping... narf!
<dholbach> desrt: hu? dpkg? what? fixing?
<desrt> dholbach; to make it touch all the parent directories when installing files into subdirectories
<desrt> ahem.
<infinity> desrt: Err, what?
<infinity> desrt: Why on earth would you want that?
<desrt> infinity; once upon a time there was a spec....
<lifeless> 99 specs on the wall, 99 specs on the wall, and the little one says 'move over'
<infinity> desrt: A spec about changing every directory each time an inode is touched?  This seems... Not sane.
<desrt> infinity; basically, the gtk icon theme cache doesn't realise that its out of date unless the parent directory of the cache is touched when you install icons anywhere into the entire tree
<desrt> infinity; so the spec says that you have to touch the parent dir whenever installing icons
<desrt> *it's
<infinity> desrt: Which is a pretty specific bug/feature of that one application, not a misfeature of dpkg (or, dare I say, UNIX)
<infinity> desrt: So, either fix the app to recognize icon changes, or fix the packages that install icons to touch the magic directory in postinst.
<infinity> desrt: Changing dpkg here is just plain wrong.
<desrt> infinity; it's a specific bug/feature that a few hundred apps in ubuntu share
<desrt> infinity; plus.  i was kidding about changing dpkg :)
<desrt> infinity; i just said it to hilight the insanity of the situation
<infinity> No, exactly one thing in Ubuntu has the bug, GTK.  Not hundreds of apps.
<infinity> Though the fix may end up in hundreds of apps.
<desrt> heh.  you appear to agree with seb :)
<infinity> (Perhaps some sort of dh_fiddlewithiconcache thing might help)
<desrt> gtk follows the spec.  dpkg does not.
<infinity> Then the spec is wrong.
<desrt> ie: even if the makefile of the app touches the parent dir on make install dpkg won't convey this information
<infinity> UNIX filesystem convention says that when you change an inode, you change that inode, not that inode and every parent directory back to /
<dholbach> infinity: that's what I wrote when I woke up, that dh_fiddle-thing
<desrt> right.  but dpkg is supposed to make it sort of like you just did 'make install'
<infinity> Says who?
<desrt> nobody, i suppose.
<infinity> The tarball part of a Debian package is just that, a tarball.  If you need more fancy action, that's why we have maintainer scripts.
<desrt> but if a manual 'make install' works and the package fails to work then something is wrong with the packaging
<desrt> not the package and not gtk
<infinity> I won't disagree that something may be wrong with the packaging, just not that the problem is dpkg's.
<desrt> fair.
<desrt> dholbach; dh_fiddle is gonna be.... how many days do you think it would take to go through all those packages?
<infinity> Though, in the Debian/Ubuntu context (or the context of packaging in general, I doubt RPM does what you want either), GTK could be considered buggy here.
<dholbach> desrt: i'll have to discuss it first
* desrt puts $10 on the table that says ubuntu ends up vendor-patching gtk :)
<infinity> We vendor-patch GTK all the time, why stop now?
<desrt> quite.
<infinity> So, I assume it's using inofity/dnotify to watch one specific directory for changes, and if that dir never changes, no cache flush?
<desrt> launchpad's new change-grouping feature is really nice
<desrt> cuts down a lot on the spam
<jsgotangco> infinity: what happened to the x and xorg.conf man pages?
<infinity> Shuffle.  Lost in the.
<jsgotangco> yeah
<infinity> This is true of many X-related manpages.
<infinity> I suppose one of us should look at that this week.
<infinity> Perhaps some keen new X SWAT member.
* infinity looks at jsgotangco 
<jsgotangco> gahh
<jsgotangco> ok
<jsgotangco> i just confirmed a bug about it though
<infinity> Yeah, there are many.
<infinity> I doubt we've actually lost any manpages in source packages, I just suspect that many of them aren't actually making it into the binary packages anymore.
<infinity> I've not had much time yet to set aside to looking into it, however.
<jsgotangco> hah so people *do* still care about man pages
<robertj> does anything actually consume the dbus new mail notifications?
<infinity> Does anything create any?
<robertj> infinity: evolution new mail plugin
<robertj> new-mail-notify is enabled by default
<infinity> Ahh.  Then I guess it's time for someone to write a DBUS-enabled biff of some sort. :)
<robertj> well I was thinking more along the lines of time for evolution to make it's new mail plugin useful
<robertj> dbus messages are really cool but not what 99.999% of users want
<dholbach> who can help a poor man with a bit of perl foo? I'm looking for something like python's   s.replace("blubb/123", "")
<Treenaks> dholbach: $blah =~ s/some_word/another_work/; ?
<Treenaks> maybe even $blah =~ s/some_word/another_work/g;
<Treenaks> (see the 'perlre' manpage)
<Treenaks> morning Burgundavia 
<dholbach> Treenaks: can I give it something like a path too?
<dholbach> or do I have to use   s:some/crazy/path::  then?
<Treenaks> dholbach: it's just a plain regular expresion, like you would feed to sed or awk or vim
<Treenaks> dholbach: yes, that would work too
<dholbach> nice
<dholbach> merci beaucoup
* dholbach hugs Treenaks
<dholbach> IT! WORKS!
* infinity watches as dholbach is converted to the dark side.
<Treenaks> infinity: You don't know the power of the Dark Side!
<ajmitch> poor dholbach 
<ajmitch> he had so much promise
<dholbach> infinity: I wonder how many people would see me "on the dark side" if I'd add a python dependency to debhelper :-p
<infinity> dholbach: Joey Hess.
<nictuku> "you don't know the power of ".. perl
<dholbach> for one... :)
<infinity> dholbach: And me, probably.
<dholbach> see
<infinity> Concievably, that cjwatson fellow, too.
<dholbach> hhaha
<jsgotangco> i am your father?
<jsgotangco> heh
<dholbach> on the other hand . o O { "Yo Mark, I added a python dependency to debhelper" }
<Burgundavia> salut Treenaks, still night here
<infinity> dholbach: Looking for a raise?
<jamesh> dholbach: you can probably also do $blah = `echo $blah | python -c 'import sys; print sys.stdin.read().replace(...'`
* dholbach sniggers
<infinity> dholbach: Hard to spend that money after Colin and I shitkick you. :)
<dholbach> infinity: some pretty bad guys live in my area :-p
<infinity> And I mean that in the most CoC-friendly way possible.
<dholbach> I understood
* neuralis cringes at a video regression in flight6 :/
<jsgotangco> video?
<neuralis> display/rendering/somesuch. this is why i'm much happier in my server cave.
<jsgotangco> yes but cringing won't help us solve it :)
<ajmitch> morning pitti 
<neuralis> jsgotangco: no, but it'll make me feel better. :)
<infinity> neuralis: It's a good cave.
<pitti> Good morning
<neuralis> jsgotangco: (i'm writing up the testing report as we speak.)
<pitti> hi ajmitch!
<neuralis> infinity: aye.
<Burgundavia> pitti: morning. got another url for you: http://www.kdedevelopers.org/node/1899
<pitti> Burgundavia: thanks; I've seen that yesterday, and upgrading cupsys is on my agenda
<Burgundavia> pitti: cool. just wanted to let you know
<jsgotangco> fabbione: since the binary won't work, we can assume all dual head issues with nvidia are hopelessly broken for now?
<infinity> multihead on the binary driver should work fine...
<infinity> It's only the free driver that's completely lacking that functionality.
<infinity> (It's not broken, it's just plain not there)
* jamesh hopes the firefox text rendering bugs will get fixed for release
<Burgundavia> jamesh: have you noticed that ff and epiphany render the page differently? epip has much smaller text
<jsgotangco> yeah
<jsgotangco> it actually looks better
<jsgotangco> infinity: the best is point to binary then?
<infinity> In this case, yeah, there's not much else we can do, unless someone has the spare time to do multihead stuff in the free driver. :/
<jamesh> Burgundavia: I filed https://launchpad.net/distros/ubuntu/+source/firefox/+bug/37828 about the problem.
<Ubugtu> Malone bug 37828 in firefox "Text rendered incorrectly in presence of ligatures and justified text" [Normal,Unconfirmed]  
<jamesh> Burgundavia: does epiphany use Pango text rendering?
<Burgundavia> jamesh: no idea
<jamesh> Burgundavia: try looking at /proc/$PID/environ to see what MOZ_DISABLE_PANGO or MOZ_ENABLE_PANGO are set to
<jamesh> (where PID is epiphany's pid
<fabbione> jsgotangco: ?????
<fabbione> jsgotangco: i have dual head with the binary.. it works fine
<fabbione> jsgotangco: it's only with the free drivers that will not work
<jsgotangco> i meant the free one
<jsgotangco> yeah
<jsgotangco> i understand now
<jamesh> Burgundavia: any luck?
<Burgundavia> jamesh: sorry, been hacking on book. just a sec
<jamesh> no problem
<Burgundavia> jamesh: I don't see MOZ anything listed
<pitti> fabbione: I approved the git-core report now
<fabbione> pitti: thanks
<sivang> morning all
<Burgundavia> morning sivang
<Pygi> mornin' sivang ;)
<sivang> Burgundavia: Hey Corey
<sivang> hi Pygi 
<pitti> hi sivang 
* sivang hugs pitti 
<drew> is it possible to make boot scripts interactive? #!/bin/bash -i doesn't seem to work...
<seb128> mdz: around?
<mdz> seb128: perhaps
<seb128> hi mdz :)
<seb128> mdz: we would like to start using the GTK icon cache for "hicolor" and "gnome", just want to get your opinion on that first
<mdz> will that actually change any behaviour?
<seb128> mdz: Debian doesn't use it for now because it requires to have the package to "touch icon_dir" at installation "masks the icons installed" 
<seb128> s/installation/installation or it
<mdz> are we using the icon cache for other things already?
<seb128> ie: that would require to update packages installing an icon there to not get "weird effect"
<seb128> we are using it for all the icon themes out of hicolor and gnome
<jordi> seb128: is that what involves patching 300 packages in Debian?
<mdz> are we using any hicolor icons in the desktop currently?
<jordi> how many in Ubuntu?
<seb128> since nothing else use "Human" by example we have to issue to generate the cache, it's not likely that it masks an app icon
<jamesh> mdz: updating the cache apparently results in a 300kb saving per-process
<seb128> hicolor is the standard fallback
<jamesh> (per process that uses themed icons, that is)
<mdz> oh, I thought we were falling back to tango
<seb128> lot of apps install an icon to it
<dholbach> jordi: 200 source packages http://daniel.holba.ch/ubuntu/usr-share-icons.list
<jamesh> everything falls back to hicolor
<jamesh> eventually
<jordi> dholbach: ugh
<seb128> Human fallbacks to Tango by Inherits, by hicolor is always used (that's the spec fallback directory)
<mdz> seb128: it is fine with me; it is you who will need to deal with the bugs if it causes any :-)
<seb128> dholbach counted 60 sources packages to main
<seb128> with a cdbs snippet it should be easy
<seb128> mdz: ok, thank you :)
* dholbach uploads debhelper and cdbs :-p
<ajmitch> dholbach: did you remember to add the dep on python? :)
<seb128> dholbach: please wait, I want to read you dh_tool before :)
<dholbach> haha
<seb128> s/you/your
<mdke> hi mdz. Any news on how the flash intro is going?
<jordi> dholbach: can you file bugs for Debian's cdbs and debhelper? :)
<Pygi> mdz: now my turn for questions? ^_^
<dholbach> jordi: as soon as seb is happy, yes.
<seb128> jordi: Josselin is strongly against using the current cache but he went the wrong way about it :/
<mdz> mdke: it's more or less a bust due to the software stack being broken
<mdz> Pygi: I am going to sleep in 2 minutes, what' s up?
<mdke> mdz, oh dear.
<jordi> seb128: I thought you went that way, last night on your blog :)
<seb128> jordi: he sort of insulted upstream by bugzilla saying bad stuff on redhat guys doing crappy stuff their way
<mdz> mdke: for dapper anyway; still hope to do it for +1
<Pygi> mdz: ah, sleep tight then ^_^ Will talk some day later ^_^
<mdke> mdz, ok! good night
<mdz> Pygi: I am very responsive to email
<jordi> oh man
<mdz> good night all
<seb128> jordi: I think I stayed correct
<seb128> 'night mdz!
<Pygi> mdz: no, you are not =P that's what I wanted to say =P
<Pygi> night mdz
<jordi> seb128: the rumour says he's french :)
<seb128> lol
<jordi> nite mdz
<dholbach> good night mdz
<mdz> Pygi: I don't have any email from you; what do you mean to say?
<seb128> jordi: but I didn't like BenM calling that a "packaging bug" :)
<Pygi> mdz: bah, the one about UVFe for N-M 0.6.2
<jordi> seb128: yeah, I didn't like that blog entry either.
<Pygi> I got the response to first mail from collin, but to my reply to that mail neither you or him responded :-/
<mdz> colin answered you
<Pygi> mdz: hm, yes , to first mail...but to second there were no answer :-/
<mdz> he said the same thing I would have said
<mdz> in colin's message he wrote "this looks OK"
<Pygi> mdz: bah, ok
<mdz> I appreciate your enthusiasm, but a) Colin already answered you, and b) don't expect me to respond to emails which you send to Colin
<Pygi> I was just seeking for confirmation of that in second mail, and answering to his question anyway
<Pygi> mdz: sent both to you and colin :)
<mdz> To: colin, Cc: me
<dholbach> Pygi: let mdz go to bed now :-p
<mdz> in a conversation between you and colin
<Pygi> mdz: ah, yes, ok, ok, sorry ;) sleep now =p
<Pygi> dholbach: yes, yes, will do ^_^
<infinity> Kamion: Can you remove ocaml-native-compilers on hppa?  ocaml no longer builds that binary on hppa.
<mdke> jdub, around?
<mdke> you know jdub said on sounder that Ubuntu was called "Ubuntu" and not "Ubuntu Linux"? That's official enough for me to go through the docs and hack out references to the latter, isn't it?
<infinity> Quite probably.
<infinity> mdke: AFAIK, the only time the words "Ubuntu" and "Linux" should be seen one after the other is if you're referring to "the Ubuntu Linux distribution".
<mdke> infinity, that's confused me now :)
<infinity> Wihch, for the sake of ambiguity, I suppose you could reword as "the Linux distribution called Ubuntu", but the passive voice never sounds good there, so I wouldn't.
* highvoltage thinks that should've been Ubuntu GNU/Linux, but that's another discussion
<infinity> highvoltage: That's one reason why it's not "Ubuntu Linux" either, since we can do without the silly flamewars.  The product is just "Ubuntu" and now everyone can feel equally hurt and left out.
* infinity wishes Debian had done the same thing long ago.
<highvoltage> infinity: great!
<sabdfl> Riddell: nice april 1st desktop :-)
<mdke> ok, I'll go and do the necessary grep+sythe out
<Mithrandir> hmm, why is the ubuntu-drivers logo shown in my list of groups I'm in?
<dholbach> sabdfl, Riddell: are there screenshots somewhere? :-)
<highvoltage> sabdfl: you're part of the community council, right?
<sabdfl> doh
<mdke> yeah, screenshots of april fools for all those of us who use a proper desktop
<infinity> Mithrandir: ubuntu-core-dev is a membery of ubuntu-drivers.
<infinity> Mithrandir: member too.
<Mithrandir> yeah, jamesh just pointed that out to me too.
<Mithrandir> we weren't before, I think.
<infinity> No, we weren't.
<infinity> We certainly should be, though, since we writeand implement most of the specs. :)
<jamesh> also, with the tightened up security only ubuntu-drivers members can change the milestone field of Ubuntu bugs
<jamesh> so mdz cleaned up the team membership and added ubuntu-core-dev to it
* Mithrandir thinks it would be appropriate if those kinds of changes were announced somewhere.  I haven't seen anything about it, at least.
<Kamion> neuralis: espresso test reports to ubuntu-users@ if they're just raw reports, or bug reports if they're cleanly separated out per issue
<jordi> jamesh: so
<jamesh> jordi: yeah?
<jordi> jamesh: if you want to investigate further, can you get the newest dejavu and see if it's still fucked like that?
<jamesh> jordi: where abouts?
<jordi> debian probably has it already
<jordi> let's check
<jordi> The current version is 2.4.1, which is an intermediate release to fix the kerning bug with Pango (LGC version is still 2.4) (What's new, Download). The next version 2.5 is scheduled for April 16th (see Roadmap). 
<jordi> so
<jordi> fight for a UVF exception :P
<jamesh> jordi: okay.  I've got 2.3-0ubuntu1
<jamesh> I'll bung a copy in ~/.fonts and see what happens
<jordi> k
<jordi> hrm
<jordi> debian has 2.3
* jordi pings bubulle
<jordi> jamesh: Debian is currently fucked
<Kinnison> dholbach: How's the gparted patch?
<dholbach> Kinnison: i followed up on the bug report about it
<dholbach> i ported it to 0.2.3 last week, but the result is still the same :-/
<jamesh> jordi: I doubt it is the font though: I only see the problem in Firefox
* Kinnison looks at his lpbugs folder and whimpers
<Kinnison> dholbach: Does 0.2.3 unpatched have the issue?
<dholbach> i'm quite sure that not, but let me double check
<ogra> infinity, what would it take to make ltsp installable on hppa/ia64 ? 
<jordi> jamesh: really?
<jamesh> jordi: yeah
<jamesh> jordi: firefox + pango + justified text
<dholbach> Kinnison: no, the unpatched version is happy
<Kinnison> dholbach: most bizarre
<jamesh> jordi: no change
<dholbach> yeah
<jordi> jamesh: gna
<Kinnison> dholbach: did you upload the 0.2.3 version of your package to the same place as before?
<dholbach> yeah
<jamesh> jordi: and I checked to make sure that firefox was mmaping the new version
<dholbach> Kinnison: http://daniel.holba.ch/ubuntu/gparted
<jordi> seb128: hmm. this pango kerning bug, shouldn't it be fixed by the new dejavu?
<jordi> jamesh: right
<carlos> pitti: ping
<Kinnison> dholbach: excellent. I'll take a look later. I have a small flock of bugs mdz gave me to look at which will take a little while to work through
<jordi> we should think about a new fontconfig upload, that makes bitstream vera preferred to dejavu again
* pitti waves to carlos 
<seb128> jordi: we don't have the new 
<seb128> jordi: but right
<jordi> seb128: jamesh installed it in ~
<jordi> and firefox was still missbehaving
<jordi> also, shouldn't he have the bug all across the desktop, not only ff?
<dholbach> Kinnison: thanks a lot - you rock!
<seb128> jordi: http://dejavu.sourceforge.net/wiki/index.php/Main_Page
<jamesh> jordi: firefox is special
<seb128> "The current version is 2.4.1, which is an intermediate release to fix the kerning bug with Pango (LGC version is still 2.4)"
<jamesh> jordi: and when using justified text, I'd expect it to be sending even smaller runs to pango for rendering
<jordi> seb128: I saw that
<jamesh> seb128: new DejaVu doesn't help, so no need to look at updating it for this bug
<seb128> that might be a firefox specific issue
<jamesh> yeah
<carlos> pitti: the mirror was not ready and thus, it was breaking my exports
<carlos> I think that 4 extra hours is enough to get always fresh data...
<pitti> carlos: so, shall I move my cron jobs by 4 hours?
<carlos> pitti: yes, please
<pitti> carlos: hm, no chance to update your mirror 4 hours earlier?
<Kinnison> dholbach: I'm not promising I can fix it :-)
<pitti> carlos: getting new tarballs in the afternoon is a bit inconvenient
<dholbach> Kinnison: we share the pain... that's good enough :-)
<carlos> pitti: I depend on a launchpad mirror, it's outside my control
* Kinnison grins
<carlos> pitti: I can do it before midnight if you prefer
<pitti> carlos: ok, moved
<carlos> pitti: but the data will be a bit more outdated as the db mirror will be done early in the morning...
<pitti> oh, let's do that in the afternoon then, that's fine
<carlos> pitti: as soon as my code is ready, we will move it into production 
<carlos> pitti: so we will not depend on the mirror
<heno> Mithrandir: I tested FL6; the F5 access options are still not active. Should I file a bug against it?
<Mithrandir> heno: live or install?
<heno> live
<heno> Mithrandir: I guess if it was seeded it would show up here: http://people.ubuntu.com/~cjwatson/seeds/dapper/desktop right?
<janimo> Mithrandir: do you have time today for trying to build xubuntu install iso
<Mithrandir> heno: hmm, it should, yes.  I don't remember why we didn't just seed them.
<Mithrandir> janimo: I think you want Kamion for that; I'm not sure how to set up a new project for cd building.
<janimo> Mithrandir: ok. afaik the code is there
<heno> Mithrandir: I guess we were womdering about desktop vs. live and decided on live
<Mithrandir> heno: we were, I think
<Mithrandir> Kamion: was there a reason for not seeding the accessibility stuff already?
<heno> So I think that should be ready to go
<Kamion> Mithrandir: I think I thought that ball was in your court
<Mithrandir> Kamion: maybe I just put it in a corner and forgot.
<heno> uh, I mean decided on 'desktop', sorry
<Kamion> janimo: I'm trying to swap hard disks in my laptop at the moment; I'll get to you after that
<janimo> Kamion: ok, thanks
* heno jumps up and down to dhake stuff out of corners
<heno>  :)
<heno> *shake
<TheMuso> Weren't we going to do a side-by-side comparrison on how big flite was compared to festival?
<Mithrandir> TheMuso: flite is bigger
<TheMuso> As far as I can remember anyway.
<TheMuso> Oh ok.
<TheMuso> That solves that one then.
<infinity> Kamion: If you're busy out the wazoo, I can set up and test xubuntu stuff on little for janimo first thing tomorrow.  ("tomorrow" being in 12-14 hours for me)
<Mithrandir> heno: hmm, I'm fine with desktop.  I can seed it fine.
<Mithrandir> infinity: when's Kamion not busy? :-)
<heno> Mithrandir: cool
<infinity> Mithrandir: When he forgets what he's working on for a few minutes. :)
<Kamion> infinity: it's ok, I'd rather do this one myself anyway since it's a new project
<infinity> Kamion: Alrighty then.  I'll just do livefs stuff for him tomorrow, then.
<TheMuso> Mithrandir: I also have some accessibility script changes for you in my casper tree. http://www.themuso.id.au/ubuntu/casper
<ogra> infinity, did you get my question above ? 
<infinity> ogra: Yeah.  Making it *installable* is easy.  We do the same thing Fabio did for sparc (make it depend on a package that actually exists on hppa/ia64)
<infinity> ogra: But I'd rather see about making both install and WORK.  So I can wait.
<infinity> ogra: s/making both/making it both/
<ogra> infinity, are there *any* ia64/hppa clients at all ?
* ogra wouldnt imagine 
<infinity> "clients"?
<infinity> As in, support contracts?
<infinity> Or, thin clients, you mean?
<Mithrandir> TheMuso: mind adding a changelog entry?
<infinity> I can't imagine many sparc ones, either.
<ogra> nope as in ThinClients with hppa/ia64 CPU
<Mithrandir> TheMuso: as in debian/changelog
<ogra> sparc actually has desktop machines you could use as clients
<TheMuso> Mithrandir: Yeah ok. Give me a few minutes.
<infinity> ogra: But if you just mean "slow second hand computers", there's just as many slow and cheap hppa boxes as there are slow and cheap sparc boxes. :)
<ogra> ah, k
<infinity> (lots and lots of them, in fact)
<ogra> making it basically installable will be the first step to get code contributions then :)
<infinity> Not so many with ia64.
<ogra> (i know that was fabios plan with sparc ... i didnt include the debian patches for sparc in dapper)
<infinity> There are Debian patches for sparc support?
<ogra> i guess there will be more from debian in dapper+1 ... some people are working on porting it
<ogra> yes, afaik debian has some basic sparc support built in ... i havent reviewed it, since i wanted to wait for dapper+1 for the ports
<infinity> The Debian package looks to have the same basic problem ours did.
<infinity> There's no way to satisfy "syslinux | mknbi | mkvmlinuz | aboot" on sparc/hppa/ia64
<ogra> so leat just add a "| elilo" (? ) to the deps
<ogra> ah, aboot, ok
<ogra> i'll add that ... so people can hack on it
<infinity> Err, you already have aboot. :)
<infinity> aboot is for ALpha SRM.
<ogra> oh, ok 
<Kamion> (you'll need elilo for intel macs in the longer run anyway ...)
<infinity> You'd want palo for hppa and elilo for ia64, but I was going to skeleton in some entries in ltsp-update-kernels for those two (and silo) and upload something that at least mentioned them.
<infinity> So, I guess I'll do that nowish.
<infinity> I assume that we don't currently have a way to build clients on a native machine, then host them from a non-native machine?
<nictuku> ogra, when you mentioned hwdb I though hwdata. Yes, python-sysinfo can be very helpful to hwdb, although python-sysinfo focus is inter-plataform compatibility. Eg it would list installed packages either in Debian or Fedora, and get network configuration from Linux or Windows - although it currently is only fully working on Ubuntu and Debian, though.
<infinity> It certainly looks like right now, we expect that clientarch==serverarch.
<ogra> Kamion, yeah, already on my list, mac minis would make awesome ltsp servers together with http://www.engadget.com/2005/10/31/jackpc-the-in-wall-thin-client/
<hendry> anyone with exp in migrating Debian over to Ubuntu? :)
<hendry> ogra: windows CE?
<ogra> hendry, it has a flash disk built in ... no reason to not flash it ;)
<infinity> ogra: No need to have elilo to use a mac mini as a server... Only as a client.  Actually, for that matter, I have no idea how to do tftp booting on an IntelMac anyway.
<nictuku> s/plataform/platform/
<ogra> infinity, should that be different to other arches ? 
<ogra> i wouldnt expect it to ... once the OS runs 
<infinity> Once the OS runs, nothing's different.  Getting it to boot is always the fun part.
<ogra> ah, k
<infinity> Like typical i386 and its braindead PXE thing.
<TheMuso> Mithrandir: Anything in particular concerning the version number increment?
<Kamion> I'm not sure anyone knows how to do Intel Mac tftp boot yet
<infinity> Most "real UNIX arches" are a no-op for network boot configuration, since bootp+tftp is something they were all designed to do in the first place.
<ogra> i dont expect to see intel mac thin clients around yet :) there are lots and lots of cheaper and better solutions for now
<mjg59> infinity: Except old Suns, which want RARP
<infinity> mjg59: Right, I remember messing with that a while back.
<Mithrandir> TheMuso: just increase it to 1.42 and set distribution to UNRELEASED.
<TheMuso> Ok.
<infinity> mjg59: Though, that was on a sparc32 machine.  Are there any sparc64 boxes that require RARP to netboot?
<ogra> infinity, elilo will be needed to build the client chroot on the server, so the dep is needed ...
<elmo> infinity: our buildds do
<mjg59> infinity: Ultra 1
<mjg59> Not sure about later stuff
<infinity> elmo: <blink>... Seriously?... I had the same class machines at my last job, and they did bootp just fine.
<elmo> infinity: well, I was just following fabbione's instructions, but he made me install rarpd
<elmo> I assume it wasn't just for giggles, but who knows
<infinity> elmo: Well, mine were cheaper (V100 and V120), but I wouldn't expect the higher end stuff of the same era to be less featureful.
<infinity> elmo: Maybe Fabio's just stuck in 1995. :)
<infinity> mjg59: Kay, that makes sense, given that the Ultra1 was sort of the first stab at the new world order.
<infinity> ogra: I may be a bit dense here, but why on earth would you need a bootloader to build a client chroot?
<infinity> ogra: I've never had a bootloader installed in any NFSroot I've served.
<infinity> ogra: Since it would be, well, useless.
<ogra> infinity, no idea, why do i need silo or aboot ? 
<ogra> (i didnt add either to the deps)
<infinity> In theory, you want silo for the tilo binary (except that it doesn't currently work, afaik), which rolls multiple kernels into one uberkernel (for booting sparc32/sparc64 hardware form the same image)
<ogra> hm, k
<infinity> You want syslinux for the abortion that is PXE.
<ogra> yep
<ogra> and mkvmlinuz for ppc
<infinity> I suspect aboot is required for similar reasons dealing with SRM being braindead.
<infinity> Or it's a spurious dep that someone tossed in there to make it installable on alpha.  Pick one. :)
<ogra> hmm, then intel macs should just work ... syslinux should be available there
<ogra> i guess its the latter ... :)
<infinity> No, cause Intel Macs don't have PXE (or bloody well shouldn't)
<mjg59> ogra: syslinux doesn't work on intel Macs
<infinity> So we all need to figure how the heck they boot from a network. :)
<Kamion> it won't *work*, but the package will be there; if that's all that's needed ...
<ogra> i didnt say it *works* (and there is no need to for cross arch ltsp)
<ogra> it just has to be there
<ogra> heh Kamion beats me 
<mjg59> infinity: Oh, it's pretty straightforward
<infinity> Anyhow, to make the server package installable, the path of least resistance is to add "| palo | elilo" to the list for hppa and ia64, yes.
<ogra> good, will do then
<infinity> When my hppa box lands, I need to re-examine what we actually need to do to set up bootable kernels on hppa.
<infinity> mjg59: I'd assume it's bootp + however we netboot ia64 boxes.  I hope.
<mjg59> infinity: No, it's more like netbooting a PPC Mac
<fabbione> infinity: nope, sparc OBP still wants rarpd
<fabbione> elmo: ^^
<ogra> all i want for now for the ports arches is that something like that can work: https://wiki.edubuntu.org/EdubuntuDocumentation/LTSPCrossArchSetup
<fabbione> even the t2000
<sladen> if the mactel's don't PXE, do they boot the way RARP+TFTP way as Mac Macs?
<mjg59> sladen: Macs don't RARP...
<infinity> fabbione: Whacky.  Maybe the V1[02] 0 series was made for idiots, then, cause it did bootp and loved it.
<ogra> that requires only that the ltsp-server package is installable on the server ... nothing arch specific
<TheMuso> Mithrandir: Do you mean .41 or .42? Just finished merging your changes and .40 appears to be the latest.
<infinity> mjg59: Does it need a bootloader wrapper, or can it bootp a kernel and jump right into it without any messiness?
<Mithrandir> TheMuso: hmm, pushing my latest version now
<mjg59> infinity: No, you need to give it elilo
<mjg59> infinity: But there's some magic in the dhcp options it needs
<fabbione> infinity: possibly...
<TheMuso> Mithrandir: ok.
<Mithrandir> TheMuso: pushed
<TheMuso> Mithrandir: Ok thanks.
<infinity> I'd love to pick up a new mini to play with, but not on my dime.
<sladen> fabbione: you marked that last Xv as in progress, are you doing an upload for it
<fabbione> sladen: did I?
<sladen> fabbione: https://launchpad.net/malone/bugs/19644  urm, Fix Released, rather than In Progress
<Ubugtu> Malone bug 19644 in xserver-xorg-driver-i810 "Kubuntu 5.04 Konqueror crashes X server repeatably" [Major,Fix released]  
<fabbione> 5.04
<fabbione> i was told it is fixed in dapper -> Fix released
<TheMuso> Mithrandir: Do I commit? When attempting to do so, a lot of files/merges are displayed which I had nothing to do with...
<mjg59> fabbione: The bug it's marked a duplicate of is unfixed in dapper
<fabbione> mjg59: ok..
<fabbione> just reopen it then
<fabbione> i might have misunderstood the infos
<Mithrandir> TheMuso: the usual way is to start with a clean checkout, do a bzr merge, check that it looks sane, commit, do your changes, commit, push.
<TheMuso> ok
<sivang> infinity: so , as we talked, the ATI X1300 are virtuall unsupported for us at the moment ? (/me looks at a T60 offer ;-) )
<infinity> sivang: Yes.
<infinity> sivang: They're only supported as vesa cards right now.
<doko> seb128 do you have a FC or Opensuse installation? I'm looking at opensuse and I'm wondering, why they have Bistream as standard font in gnome, but fontconfig lists Nimbus as preferred choice. The gnome font propierties just lists "Sans" / "Serif"
<seb128> doko: nop, I don't
<seb128> doko: how do you notice they have Bistream used?
<doko> seb128: not sure, but it's definitely something else than the preferred Nimbus font
<doko> (preferred by fontconfig)
<sivang> infinity: how would you describe the amount of work needed to make it supported? :)
<infinity> sivang: "A metric buttload"
<infinity> sivang: However, it's not just the newer laptops and shiny 3D cards that motivate people, the new Intel Macs (which everyone is rather fond of right now) ship with these unsupported chips too, to I suspect it'll become someone's darling project pretty soon.
<sivang> infinity: Ah, I thought it was going to be you ? :)
<infinity> sivang: ENOHARDWARE
<mjg59> Dave Airlie is potentially looking at it at some stage
<infinity> airlied looks at a lot of stuff. ;)
<sivang> infinity: ah :)
* sivang pokes at various posts on fd.o
<Mithrandir> seb128: uhm, gdmflexiserver seems to disappear if I change desktops.  Do you know of any such bugs?
<mjg59> sabdfl: Had a chance to test the X60?
<TheMuso> Mithrandir: http://www.themuso.id.au/ubuntu/casper - Should be good to go.
<sivang> mjg59: could it be that it invloves implementing a complete engine stack to support that card? (I admit I am not thoroughly understanidng the terminology but this imples writing from scratch the low level hardware talking part IMU)
<mjg59> sivang: No
<mjg59> The 2D core actually seems to be similar to the older Radeons, but the mode setting code is different
<Mithrandir> TheMuso: thanks
<TheMuso> np
<sivang> mjg59: hmm, so even to makes this work, it would need tweaking. thinkwiki reports failure with either of the drivers.
<mjg59> sivang: The mode setting code is different
<mjg59> Which means that the existing drivers will not work
<netgrabber> seb128: Do you have a current (beta) gaim version for dapper?
<zakame> hi all
<danimo> moin
<danimo> is there a chance for networkmanager 0.6.2 to be uploaded?
<danimo> (to dapper)
<mdke> danimo, yes, I believe it is planned
<danimo> is there a place I can look at the progress?
<mdke> danimo, I don't think so
<mdke> there may be a wiki page
<danimo> mdke: nope, pity
<doko> seb128: does nautilus honor /etc/mailcap?
<mdke> danimo, you can contact the maintainers, they'll tell you. but maybe it's just better to wait
<danimo> mdke: right
<torkel> danimo: or try to track the n-m bugs. I think there is a wishlist bug for upgrading to 0.6.2
<seb128> netgrabber: no, why?
<seb128> doko: no, it used shared-mime-info (freedesktop mime database)
<seb128> s#used#uses
<netgrabber> seb128: I get a lot of spam if I use the dapper version (Webaware)
<seb128> netgrabber: that can be fixed with 1.5.0 probably
<seb128> we should change the code to not use webaware
<netgrabber> seb128: do you have such a patch?
<seb128> netgrabber: no
<seb128> netgrabber: but that's probably one line of code change
<seb128> netgrabber: are you sure than the spam is due to webaware?
<netgrabber> I don't know it exactly. On my notebook i have the current beta and no spam. Here on my desktop i have the dapper version.
<giftnudel> mvo: the issue from yesterday (update-manager + sources.list) seems to be resolved ;-)
<infinity> Kinnison: * This release should also fix: ...
<infinity> Kinnison: The suspense is KILLING ME.
<janimo> mvo, as per you request poking wrt update/manager gconf :). Of course if you'd rather wait with the upload until I make config read/write it's ok
<janimo> just saw that you are in upload mode :)
<ogra> infinity, me too !!
<ogra> so lets wait for the next upload that finishes that sentence :)
<Seveas> Daniel "Cliffhanger" Silverstone ;)
<zakame> rock
<jsgotangco> heno, ping?
<sivang> ROTFL
<Kinnison> infinity: arse, forgot to dd that line
* Kinnison goes to buy some masking tape so rjek can paint the door
<Kinnison> infinity: I'll tell you more later
<mvo> janimo: thanks, keep poking me. I'm (not yet) at update-manager, but it should be part of the next upload
<janimo> mvo, thanks
<Tm_T> weare getting reports that debtag package is causing issues
<Tm_T> http://kubuntu.pastebin.com/637703
<heno> jsgotangco: pong
<Tm_T> Riddell: ping
<Riddell> Tm_T: hmm?
<Riddell> yeah, confirmed, fix should be buliding
<Tm_T> ok, thanks
<jcole> dudes
<mdke> no dudes here
<jcole> i've got about 4 ubuntu installs and have to do a "sudo hdparm -d /dev/hd*" (dma on) before i watch a dvd, or the dvd skips badly and my cpu goes through the roof ... just wondering if dma is defaulted to on in dapper
<jcole> mdke: dudettes
<sladen> jcole: https://launchpad.net/distros/ubuntu/dapper/+filebug
<OdyX> jcole: it is.. I had to do it... but has been solved (for me)
<jcole> sudo hdparm -d1 /dev/hd*
<jcole> sladen: i'm not sure if that's a bug... is it off for a reason?
<jcole> sladen: regardless, i'll file
<OdyX> jcole: lack of material detection => bug. (because it is per default)
<sladen> jcole: if something doesn't work out of the box, that is a bug.
<mdke> there was a bug in the old days about dma not being turned on out of the box
<heno> mdke: do you know who handles the ubuntu-artwork package
<mdke> I think it is closed as WONTFIX because it is too hard to differentiate between drives that support it and those that don't
<mdke> heno, jeff
<infinity> (dub)
<OdyX> https://launchpad.net/distros/ubuntu/+bugs?field.searchtext=hdparm&search=Search&orderby=-priority%2C-severity
<heno> thanks
<mdke> jcole, have a look for that bug, and see because there's not much point filing another one if it can't be fixed
<mdke> ah, it's marked as fixed now :) https://launchpad.net/distros/ubuntu/+source/linux-source-2.6.15/+bug/36185
<Ubugtu> Malone bug 36185 in linux-source-2.6.15 "Automatically enable DMA on CD-ROMs where it is known to work" [Wishlist,Fix released]  
<sladen> heno: seb128 or jdub
<mdke> heno, is that for the backgrounds :) hope so
<seb128> or dholbach
<heno> mdke: yes
<mdke> cool
<seb128> dholbach so
<jcole> mdke: cool
<heno> mdke: I even managed to blame it on you ;) https://lists.ubuntu.com/archives/ubuntu-art/2006-April/000947.html
<mdke> :)
<mdke> heno, if some don't make it into -artwork, i think an ubuntu-backgrounds package would be cool
<heno> yep
<seb128> mdke: you are trying to put new backgrounds on the CD?
<mdke> seb128, I don't have access to the CD
<seb128> you got the question probably no?
<zul> heylo
<seb128> let me say it different "the discussion is about putting backgrounds image to a package that is shipped on the CD?"
<seb128> mdke: better that way?
* jcole will search the bugs before he asks a question next time! :)
<mdke> seb128, I filed a bug about removing backgrounds from example-content. I suggested two alternative places the backgrounds could go. ubuntu-artwork, or ubuntu-backgrounds. heno has suggested that the backgrounds could be considered for ubuntu-artwork, and identified one specific background in particular as a candidate for inclusion as default background.
<seb128> mdke: how many images is that?
<mdke> seb128, i don't know. The maintainer of ubuntu-artwork can choose which images to be included, if any. I'm not trying to push images onto the CD, don't worry
<seb128> k
<jsgotangco> hmm its already in the cd no?
<seb128> I'm just concerned about the number or examples and images, we will need to kick some out of the CD or kick some apps out if that keep going that way
<jsgotangco> the bug is about just moving them to a new package?
<jsgotangco> s/new/existing
<mdke> jsgotangco, that's true yes
<bddebian> Any .desktop file experts?
<Mithrandir> jsgotangco: did you get around to testing the -server cd?
<mdke> seb128, I'd suggest removing example-content from the install cd altogether, (leaving it on the live cd) but that's another story.
<jsgotangco> Mithrandir, yeah -server flight 6 installed fine on my side but do you need further tests?
<seb128> mdz: would be a good idea
* jsgotangco couldnt think of anything to test on an X-less system
<mdke> got it
<heno> there are currenly 11 sample wallpapers on the example part of the CD, and I'm about to remove them all. I want to suggest that one of them is moved to ubuntu-artwork
<mdke> I'm with you. That background rocks
<jsgotangco> the duck?
<Mithrandir> jsgotangco: you could ask fabbione/infinity, but no, nothing I can think of immediately.
<mdke> heh, no wp-dapper.png
<bddebian> Does anyone know if a .desktop file should have Icon=foo instead of say Icon=foo.xpm?  My concern is how does it handle it if there is foo.xpm and foo.jpg in /usr/share/applications?
<jsgotangco> k
<ogra> bddebian, it prefers png, then xpm iirc
<ogra> dunno about jpeg
<bddebian> But Icon=foo is appropriate?
<ogra> and i think you mean s/applications/pixmaps :)
<ogra> should be, yes
<bddebian> Oh yeah, pixmaps.. Heh
<fabbione> jsgotangco: just apt-get install apache2 or something
<ogra> woah, example content grew to 11M ? last time i looked it had only 6 ....
<mdke> hmm. is it bad if packages grow in size suddenly, from the point of view of the cd? ubuntu-docs will get a lot bigger when it has some translations on it
<ogra> mdke, edubuntu only has kilobytes of spare space ... dunno how the situation is on ubuntu, but not *very* much better i uess
<ogra> *guess
<mdke> hmm. tricky
<janimo> mdke: will ubuntu-docs package include translations itself?
<mdke> janimo, yes
<janimo> so no langpacks there
<mdke> no
<ogra> hmm ...
<jcole> i was in synaptic the other day and was thinking "it would be nice if i could see a screenshot of these apps"... so i decided to write a shell script to that looped through "apt-cache search ." and auto-googled 10 images for each package... after about 30 minutes, i looked at the images downloaded and found alot of cool gtk apps i didn't know about before...
<jcole> i guess my point is "a screenshot is worth a thousand words" and was wondering if anyone has thought about something like this? something like screenshots window in synaptic (could be from google images or a screenshots database)
<mvo> jcole: sound like it might be a fun idea for gnome-app-install. it already pre-selects on end-user applications
<ogra> jcole, i guess it'd be rather appropriate for gnome-appinstall
<jcole> mvo ogra: exactly
<jsgotangco> well we started gai with the icons
<ogra> so dapper+1 can have the shots ;)
<jsgotangco> that's a lot of shots 
<ogra> (if time permits)
<jsgotangco> yeah
<pitti> carlos: ah, pmount translations have been imported; can I remove the obsolete ones myself, or do you need to do that?
<carlos> I need to do it..
<mvo> well, app-install data is already pretty big (because of the icons)
<carlos> well, I need to ask stub to do it
<Seveas> _ion/infinity, there now exists a patch to make madwifi-ng wext-compiant which means much less pain for n-m
<carlos> but I'm a bit overloaded atm fixing also OO translations and handling KDE imports and I forgot it... sorry :-(
<ogra> mvo, ah, so its your fault that edubuntu always runs out of space :P
<ogra> finally someone to blame :)
<sivang> hehe
* mvo points to the packages with the big icons
* mvo supports pittis degui-spec
<sivang> degui-spec? a new one ? :)
<ogra> ubuntu-cli metapackage ?
* sivang wonders since when
<mvo> sivang: jsut joking, there is a joke "GettingRidOfTheDesktop" spec
* sivang wipes out sweat. 
<sivang> :)
<ogra> how about a UsingPunchCardsInsteadOfHDs spec then ... would correspond very nicely to that one ;)
<sivang> HA HA
<sivang> ogra: Oli, stop, I'm trying to work :)
<ogra> :)
<jsgotangco> lol
<ogra> or GuessingDisplayOutputByModemNoise ....
<ogra> that would solve a *lot* of Xorg probs ...
<sivang> heheh
<ogra> (indeed only for modem users, the others would still have to use their monitor)
<zakame> haha
<ogra> pfft, no edubuntu on http://www.zegeniestudios.net/ldc/
* ogra writes complaint ...
<jsgotangco> guys its already April 3
<jsgotangco> :)
<shawarma> This is probably an FAQ by now, but why is it exactly that we've told network-manager to NOT alter resolv.conf?
<Mithrandir> shawarma: dhclient does it, if appropriate
<mdke> Mithrandir, ping
<mdke> oh, you're there
<shawarma> Mithrandir: right but I've packaged the vpn plugins but they don't really work all the well without being able to tell nm to use other DNS's.
<mdke> Mithrandir, we have a bug in that kubuntu-docs we did for breezy. the update-alternatives link points to the wrong url.
<Mithrandir> shawarma: I get very irate when NM changes my resolv.conf and am quite happy that it doesn't touch it.
<Mithrandir> mdke: hmm.
<mdke> Mithrandir, i'll do you a patch
<shawarma> Mithrandir: Besides, the default for NM is to handle resolv.conf so there must be some reason why we've explicitly told it not to.
<Mithrandir> mdke: please do; I'm on my way out so mail it to me or file a bug with a patch
<Mithrandir> shawarma: yes, it's that dhclient does.
<mdke> Mithrandir, sure thing
<shawarma> Mithrandir: Yes.... but the vpn plugins won't work.
<Mithrandir> shawarma: they need to be fixed somehow, then.
<shawarma> Mithrandir: I don't really think that "dhclient does it for you" is a good enough reason. Can you tell me something that will NOT work if nm handles it? 
<Mithrandir> shawarma: my default search path, for instance.
<jdthood> shawarma: Some time ago there was discussion of resolvconf.  Was some decision made about it?
<Mithrandir> shawarma: this is only a problem with the vpn plugins, apparently, so they should solve it.
<shawarma> Mithrandir: What if nm had allowed you to add certing things to your search path?
<shawarma> *certain
<Mithrandir> shawarma: then it would still be broken, since the search path is a global configuration thing while NMs configuration would be per-user.
<giftnudel> cool, a complete hang of the system after upgrading to dapper ...
<shawarma> Mithrandir: hmm.... One could argue that network configuratoin is a global thing. Nevertheless, nm handles network configuration.
<shawarma> Mithrandir: doesn't dhclient change your search path too, btw?
<Mithrandir> shawarma: no, since I've told it not to.
<shawarma> Mithrandir: ah..
<mdke> Mithrandir, patch is on bug #27906
<Ubugtu> Malone bug 27906 in kubuntu-docs "Typo in kubuntu-docs" [Normal,Confirmed]  http://launchpad.net/bugs/27906
<mdke> ogra, who should I talk to about ubuntu-docs growing in size, in terms of ensuring there aren't any problems later on with the CD?
<jcole> this is SO much better that the gnome services manager (and it shows ALL services), been using it for about a week -> http://linux.softpedia.com/progScreenshots/BUM-Boot-Up-Manager-Screenshot-4564.html
<jcole> apt-get install bum
<jdthood> Mithrandir: Has there been any discussion about using resolvconf together with network-manager?
<jdthood> NM, found the answer: https://wiki.ubuntu.com/NetworkMagic
* sladen wishes LP wouldn't visible CC me on bug reports.  I want the replies to go *to the bug report*, not me...
<mdke> yes, I've seen that problem too.
<mdke> it only seems to happen on certain bugs
<mdke> ah, when they are reported. Comments don't have the problem
<shawarma> The "release notes" mail about network-manager from Keybuk speaks of a bunch of errors with network-manager's handling of resolv.conf as the rationale for removing this functionality.. Does anyone know if these bugs persist in the 0.6-tree of nm?
<sabdfl> mjg59: not yet
<sabdfl> will try get there this evening
<sabdfl> dubious about this new wifi card
<zakame> hi G0SUB 
<G0SUB> zakame: hey!
<jcole> "Error ! please contact hwdb@ubuntu.com " -> http://hwdb.ubuntu.com/?xml=vectra
<bddebian> Am I OK uploading a change to a .desktop file just changing the icon name?  Should be an issue with strings right?
<bddebian> Err s/should/should not/
<seb128> bddebian: that's fine, no translation for the filename :)
<ogra> mdke, sorry, was afk
<mdke> np
<ogra> mdke, i guess Kamion, Mithrandir and me know about the sizes
<ogra> (i dont look at ubuntu normally, but they do)
<mdke> right. I'll mail
<ogra> jcole, how did you manage to upload such a file ? 
<bddebian> seb128: Great, thanks.  One other quick question.  The current Icon=graveman48.png and user wants Icon=graveman.  No problem.  However, I am going to need to rename graveman48.png to graveman.png correct?
<seb128> bddebian: correct
<bddebian> Thank you sir
<Riddell> Kamion: do you know how espresso-frontend-gtk gets on the kubuntu live CD?  its not in any of the seeds or germinate output (except extra)
<Kamion> http://people.ubuntu.com/~lamont/liveLogs/kubuntu/latest/livecd-20060331.1-i386.out says apt is deciding to install it
<Kamion> which is just installing kubuntu-live I think
<Kamion> so I'm honestly not sure, I blame apt
<Riddell> it's definatly not in kubuntu-live
<Kamion> sure
<Riddell> Mithrandir: any ideas?
<Riddell> Kamion: second question, how does the .desktop file for espresso-frontend-gtk get onto the 
<Riddell> the desktop?
<Kamion> build a base system, apt-get install kubuntu-desktop, apt-get install kubuntu-live, you should be able to reproduce it
<Kamion> casper/casper-bottom/10adduser
<Kamion> there's a for loop there which can easily have kde-ui added to it as soon as you're ready
<Mithrandir> Riddell: try changing the order of espresso and espresso-frontend-kde in the depends for -live, I think.
<Kamion> urgh!
<Kamion> we need to avoid that somehow, can't be depending on that
<Mithrandir> have kubuntu live have espresso-frontend-gtk- ?
<Kamion> you can't do that in dependencies
<Mithrandir> hmm, true.
<Kamion> no, this needs to not be a stupid metapackage workaround
<Kamion> it smells like an apt bug
<Riddell> ah, so epsresso depend on espresso-frontend which brings in espresso-frontend-gtk
<Mithrandir> Riddell: that's my guess at least.
<Mithrandir> ask mvo if you want a definitive answer.
<Kamion> both espresso-frontend-gtk and espresso-frontend-kde provide espresso-frontend
<Kamion> if espresso-frontend-kde is being installed, I don't think apt should also select espresso-frontend-gtk
<Riddell> I can just remove espresso from the seeds and leave only espresso-frontend-kde
<Kamion> hmm, that could be the problem though, espresso-frontend-gtk doesn't depend on espresso while espresso-frontend-kde does
<Kamion> not sure what's correct there
<Kamion> maybe apt feels espresso-frontend-gtk is "easier" somehow due to the lack of a circular dep
<Kamion> Riddell: ok, I'll add that dep to espresso-frontend-gtk and you can make that seed change
<Riddell> doing
<Riddell> shall I make an equivalent change for the ubuntu seeds?
<Kamion> not yet, I'll do that after my next upload
<jsgotangco> good night
<mdke> night
<pitti> seb128, Kamion: freecdb has been considered dead for some time now. Any objection if I unseed it? (no reverse deps)
<Kamion> no
<seb128> no objection from me neither
<pitti> alright
<pitti> mdz asked to migrate away from it, but unseeding is the only thing to do
<pitti> thanks
<elmo> eh
<elmo> dead how?
<elmo> userdir-ldap still uses it
<pitti> elmo: that's claimed in debian bug 338038
<Ubugtu> Debian bug 338038 in freecdb "Subject: freecdb: does not provide a shared library" [Serious,Open]  http://bugs.debian.org/338038
<pitti> which was imported into bugzilla
<pitti> (bug 25202)
<Ubugtu> Malone bug 25202 in freecdb "skkdic requires cdbmake to complete migration from freecdb" [Unknown,Unknown]  http://launchpad.net/bugs/25202
<pitti> elmo: you mean libapache2-mod-ldap-userdir?
<dieman> and network manager works with wpa enterprise at work, yay
<elmo> pitti: no, userdir-ldap
<pitti> hm, no such package here on amd64
<elmo> pitti: the thing that powers db.debian.org and the ubuntu.com machines
<elmo> it's not in the archive
<pitti> ah
<pitti> elmo: the upstream bug recommends changing to tinycdb
<mdz> infinity: which version of make is it which broke everything in Debian?
<pitti> elmo: anyway, I don't care much, if we need it in main, I'll leave it as it is
<elmo> pitti: that's fine, as long as something which implements the API is available
<elmo> and I've kind of given up on the idealistic dream of having things we run on ubuntu.com in main
<elmo> (HI APACHE MAINTAINERS)
<pitti> " tinycdb implements almost all API as found in cdb-0.75 written by
<pitti>  D.J. Bernstein, so it should be source-compatible."
<pitti> didn't test that, though
<pitti> nor do I have any idea what it does
<pitti> mdz: you wanted freecdb to go away in bug 25202; was that just housekeeping, or any particularly strong reason?
<Ubugtu> Malone bug 25202 in freecdb "skkdic requires cdbmake to complete migration from freecdb" [Unknown,Unknown]  http://launchpad.net/bugs/25202
<mdz> pitti: only the reason I gave in the bug report (it's dead upstream)
<Mithrandir> elmo: you'll get apache 2.2 for dapper+1.
<pitti> mdz: ok; Gerrit Pape did a recent upload, claiming that he took over upstream maintenance
<mdz> pitti: ok
<elmo> Mithrandir: great, you can have your DVDs served from ubuntu.com in dapper+1 too :-P
<Mithrandir> elmo: I use rsync. :-)
<mdke> elmo, while you're here. I was gonna ask you whether it might be possible to use an ubuntu server for the help.ubuntu.com website. We're thinking about hosting the translated documentation too for dapper (http://help.ubuntu.com/6.06/) and our server will probably not be good enough. What do you think?
<pitti> elmo: is there a special reason gpg uses configure --with-included-gettext? it breaks langpack support
<elmo> mdke: what software do you use/run?
<elmo> pitti: not that I can recall
<mdke> elmo, it's all just plain html
<elmo> why does it break langpack support tho?
<mdke> so apache
<pitti> elmo: the included gettext doesn't look in /usr/share/locale-langpacks
<elmo> mdke: how many and who has access?
<pitti> elmo: of course I can apply the same glibc patch to the included gettext, but it could as well just use libc's gettext
<elmo> pitti: err, I'm going to regret asking, but why /usr/sh/l-l ?
<mdke> elmo, me and henrik have root on the server, which also houses doc.ubuntu.com (which we'd probably like to keep on that server). For help.ubuntu.com we would probably just need one user with normal access to upload the documents all in one go.
<pitti> elmo: so that the langpacks don't conflict with unstripped or locally built debs
<mdke> elmo, if you prefer, they can even be tarred up for you, and you can put them up, approx once every release cycle
<elmo> mdke: if it's just plain html, that's fine, you can certainly have a server
<elmo> mdke: send a mail to RT with all these details?
<elmo> (well, _share_ a server. ;-)
<mdke> elmo, absolutely. Thanks very much.
<mdke> sure, sure
<elmo> pitti: oh, right - anyway, feel free to fix gnupg
<pitti> ok, thanks
<elmo> pitti: if it works for you, I'll change debian to match ;-)
<pitti> elmo: yep, works fine (with a small s/rm/rm -f/ fix in rules, see http://paste.ubuntu-nl.org/11382)
<elmo> pitti: err, surely, just drop the locale.alias removal altogether? but details
<pitti> elmo: I left it in in case we'll ever experiment with the internal one again, since it doesn't hurt
<pitti> but feel free to drop it completely, of course
<siretart> has the update-manager tool for upgrading from breezy to dapper already been uploaded to breezy-updates, or shall testers still use http://people.ubuntu.com/~mvo/backports/update-manager/?
<mvo> siretart: we are working on the last missing bits, currently it is still in my private repo
<mvo> siretart: I hope we get it into the archive soon though
<Chipzz> mvo: :)
<siretart> mvo: we want to update a machine right now. shall we use http://people.ubuntu.com/~mvo/backports/update-manager/ for testing it?
<mvo> siretart: yes please
<siretart> ok. will do
<mvo> siretart: you will need breezy-updates in your sources.list as well (for main and universe)
<mvo> this way a updated python-apt and python-vte can make it to your system
<bddebian> seb128: You still here?
<mdke> JaneW, ping?
<seb128> bddebian: pong
<carlos> pitti: confirmed, the language pack exports are working again
<pitti> carlos: thanks
<carlos> pitti: when will your scripts run ?
<bddebian> seb128: Sorry to bug you again, but I think copying graveman48.png to graveman.png wasn't the thing to do since it affects orig.tar.gz.  Should I just cp it in debian/rules to /usr/share/applications/graveman.png?  Is that more appropriate?
<seb128> bddebian: why not just using "graveman48"?
<ogra> bddebian, either that or uuencode it in the diff.gz
<siretart> mvo: upgrade is ongoing :)
<ogra> (i like cp in rules more though)
<mvo> siretart: woah, that was quick :)
<mvo> siretart: when it finishes, could you please send me the logs in /var/log/dist-upgrade*.log?
<bddebian> seb128: Malone 1849
<Ubugtu> Malone bug 1849 in graveman "Icon name" [Wishlist,Unconfirmed]  http://launchpad.net/bugs/1849
<seb128> bddebian: I don't know about theme edition and why "graveman48" is not a valid name
<seb128> bddebian: if you want to move it do it from debian/rules so
<sivang> okay, time to go home and do some HUBing :)
<fabbione> time to go home and.. hmm no.. i am home... doh!
<bddebian> heh
<mdke> lucky >_<
<ogra> home is where the heart is :)
<LaserJock> and where the laptop is ;) for me anyway
<ogra> or wherever i lay my heat ?
<ogra> or head ?
<bddebian> heh
<carlos> pitti: hmm, dapper export failed due a lock...
* mvo delcares dinner time
* ogra does the dholbach ...
<dholbach> ogra: how does one go about doing the dholbach?
* dholbach would like to learn from the expert :-p
<pitti> walking the dog?
<mdke> I thought that was doing an ogra
* ogra --> dogwalk ;)
<dholbach> :)
<ogra> since i'm alone i cant push susus to do it during the week *shrug*
<bddebian> Bah, screw this bug.. :)
<bddebian> It's wishlist anyway 
<sivang> fabbione: I wish I was lucky like you :-)
<sivang> ogra: eheh
<fabbione> sivang: sometimes i wish i had an office
<sivang> fabbione: Let's have a small talk about it and I'll remind you why you don't :)
<fabbione> sivang: you don't have a wife...
<fabbione> let's talk about it :F
<fabbione> :D
<sivang> fabbione: hmm
<sivang> fabbione: well, even when I'll live with my gf, she is a full time ERP intergrator , and arrives home around 6pm, and even when she's around she understands my involvment in FOSS , I hope it will stay like this when we do move in together :)
<fabbione> sivang: the point is that when she is home from work, and you are at home at work, you will be the one spending all day in front of that damn computer, doing absolutely nothing when there is the laundry that needs to be done and food to be prepared and.. and .. and..
<bddebian> heh
<sivang> fabbione: right, but then again she needs to understand that you've been at work all day :)
<sivang> fabbione: although, minor detail that physically you reside at home :)
<fabbione> sivang: you wish :)
<sivang> hehe
* sivang is glad he is not married, yet..
<hunger> Did anyone use pvmove recently in dapper?
<hunger> It keeps coredumping for me.
<Kinnison> mdz: ping?
<Kinnison> mdz: both 25737 and 24992 would be solved by syncing the new chicken package from debian. But it is an upstream version change.
<Riddell> carlos, jordi: ping
<mdz> Kinnison: usual procedure applies
<mdz> Kinnison: it's purely a build-dep thing I think, so if stuff still builds, probably ok
<KaiL> hmm, DVD-RAM-Support isn't THAT good, I'd say
<janimo> Kamion, thanks for the isos
<janimo> :)
<dholbach> have a nice evening
<sivang> night dholbach 
<dholbach> bye sivang
<dieman> KaiL: what sort of dvd-ram issue you having?
<KaiL> dieman, Bug 37905 and bug 37907
<Ubugtu> Malone bug 37905 in pmount "DVD-RAM shouldn't get mounted ro" [Normal,Unconfirmed]  http://launchpad.net/bugs/37905
<Ubugtu> Malone bug 37907 in gnome-volume-manager "no reaction on DVD-RAM" [Normal,Unconfirmed]  http://launchpad.net/bugs/37907
<hunger> Did anyone use pvmove recently in dapper? Keeps coredumping for me,
<sladen> hunger: strace it and file a bug
<tsdgeos> jordi: any update on the aspel-ca issue?
* hunger did not yet file a bug about this because he lost his launchpad account.
<tsdgeos> hi btw
<sladen> hunger: if you can remember your email address, ask for a new password
<hunger> sladen: There is the next problem: I need to pvmove my partitions to a new disc before I can read mails again:-(
<sladen> hunger: can you dd, or loop mount or something to get around that
<sladen> have you tried rebooting?
<KaiL> dieman, excapt that I can use pmount, it feels like in old days, before we had hal, dbus and so on...
<hunger> sladen: dd is not really an option since the new disc is bigger than the old one. Rebooting does not fix the issue (if it did then I'd run and get a new OS;-)
<dieman> KaiL: hrm, i dont see 37907 on my system
<dieman> KaiL: you may want to add what type of hardware you are using, too
<dieman> KaiL: i knew about 37905
<KaiL> hmm, you don't see 37907...
<dieman> i had reported it in the past i thought
<KaiL> hmm
<hunger> sladen: I'll find a solution... maybe I'll use a non-ubuntu disc to move stuff.
<dieman> trying to find my old bug here
<KaiL> let's see, if something filled gvm...
<KaiL> eh killed
<KaiL> nop, normal CD works
<KaiL> uhm...
<KaiL> worked..?
<dieman> weird
<dieman> who makes your drive?
<KaiL> where on earth is the icon?!?!?
<KaiL> LG
<dieman> hrm
<dieman> ive got an LG also and it mounts automatically
<dieman> but that machine is running breezy
<KaiL> WTF? The icon is missing :/
<KaiL> ..for a CD
<dieman> https://lists.ubuntu.com/archives/ubuntu-bugs/2004-October/012483.html
<dieman> bwhaha
<dieman> https://launchpad.net/distros/ubuntu/+source/partman-target/+bug/8970
<Ubugtu> Malone bug 8970 in partman-target "cdrom is set to ro by default, breaks dvd-ram users" [Wishlist,Rejected]  
<dieman> which is a dupe of
<dieman> https://launchpad.net/distros/ubuntu/+source/partman-target/+bug/18057
<Ubugtu> Malone bug 18057 in partman-target "UDF formatted CD is mounted read-only" [Normal,Fix released]  
<dieman> which was supposedlyf ixed in partman-target 36ubuntu2
<KaiL> ah, ok
<KaiL> and because my fstab is still from <ancient>, this still sits there...
<dieman> yah
<dieman> that too
<KaiL> let's see, what a real dapper system says here....
<dieman> you probally need to take ro out of your fstab
<jordi> tsdgeos: yes, I'm working on a update which will fix everything.
<jordi> tsdgeos: I guess I'll have it in two days or so
<KaiL> dieman, and as the other problem not only hits DVD-RAM here, something seams to have crashed :/
<carlos> Riddell: pong
<carlos> not sure if jordi answered already...
<Riddell> carlos: he didn't, able to join us in #kubuntu-devel ?
<carlos> sure
<Pygi> mdz: sorry about the mixup and all :-/
<mdz> Pygi: was your intention to ask for a freeze exception, or were you asking whether someone would do the work of updating the package?
<Pygi> mdz: nah, I was asking for freeze expection...me and _ion intented to make patches, and then talk to Keybuk & infinity about uploading
<mdz> ok
<mdz> fabbione: are you making some progress on the X bug list?  I have been mostly leaving those alone in my sweep, with the expectation that you are working on that list
<ogra> mdz, do you suggest that switching the app justifies closing the bug (i.e. bug 28758) ? it still exists in xss i guess ...
<Ubugtu> Malone bug 28758 in xscreensaver "Dapper freezes on rhythmbox notification bubble when (openGL)screensaver is active" [Normal,Fix released]  http://launchpad.net/bugs/28758
<fabbione> mdz: i did go trough the requestes you left me in malone today, but i had to do some work on cluster stuff today as well
<mdz> ogra: feel free to downgrade it instead
<mdz> fabbione: there is a big backlog of X bugs which haven't been looked at by anyone; I am going through all of the other bugs but if you could deal with the unconfirmed X bugs that would be a great help
<ogra> mdz, no, i'm fine and will wait for someone to repoen if needed, i was just asking about our general attitude 
<ogra> s/asking/curious/
<fabbione> mdz: yes i know.
<fabbione> mz
<fabbione> mdz: i also need to keep into account -server/-cluster in my daily work..
<fabbione> they aren't finished yet
<mdz> ogra: I would consider the bug to be low-impact since we are using gnome-screensaver now; of course, Xubuntu is probably still using xscreensaver, but they can open their own task if they want to ;-)
<ogra> oki :)
<siretart> mdz: I see that you assigned bug #27983 to me. I outlined what would needed to be done there. do you think we should do this transition? if yes, I'd rather start sooner than later..
<Ubugtu> Malone bug 27983 in openal libopenal0 "libopenal0: openal changed API without adjusting versioning" [Unknown,Unknown]  http://launchpad.net/bugs/27983
<mdz> fabbione: what is on your todo list for clusters?
<mdz> siretart: I received your email; I'm just trying to get caught up on bugs right now
<mdz> I have another 1300 bugs to review
<fabbione> mdz: get clvm tested and in main on sabdfl input/request.
<fabbione> mdz: that opened literally a can of worms
<fabbione> that's good tho
<siretart> ah, ok. sry then..
<ogra> fabbione, we should look into ati vs radeo detection, i had a buch of GL screensaver bugs that were solved by changing ati to radeon in xorg.conf ... 
<fabbione> but there is stuff that needs fixing and testing
<fabbione> ogra: welcome to send me a patch :)
<fabbione> ogra: i am not jalous of X
<ogra> i know ...
<ogra> nobody is :)
<LaserJock> darn, mvo killed my pbuilder how to in the Packaging Guide ;-)
<ogra> i'll look into this particular issue ...
<fabbione> ogra: solution is to fix it in discover1-data to return the proper driver and make sure xorg doesn't override
<mdz> fabbione: was I CCed on that conversation?  I don't remember clvm
<fabbione> ogra: or ask benh to actually make it working
<fabbione> mdz: i don't think so
<ogra> is our discover1-data even up to date ? 
<fabbione> ogra: yes
<ogra> i know daniels always care dfor it
<ogra> ok
<mdz> fabbione: please forward me the thread
<fabbione> mdz: yes i was searching for it
<lamont> Diziet: re 33895 - I'll check that soonish
<fabbione> mdz: you were acutally in the To:
<jordi> answered what?
<fabbione> well you got it twice
<zul_> wq
<mdz> fabbione: the only thing I saw in that message was a question "is it something that makes sense to have in main?"
<mdz> was there a later message?
<fabbione> my answer to it?
<ogra> zul_, you missed the colon
<mdz> yes, you said it was a nice to have
<zul_> ogra: yeah...my click to focus sucketh..
<fabbione> yes and that it required some investigation
<fabbione> so i started investigating and found:
<fabbione> - multipath-tools is broken
<fabbione> - lpfc kernel driver is broken and i fixed it
<fabbione> - e1000 kernel driver is broken and i fixed it
<fabbione> - clvm requires working cman and found out that it is partially broken and i am fixing it
<fabbione> together with the bugs i am fixing while i do this...
<fabbione> do/did since it's still going on
<KaiL> what on earth is an nVidia Geforce 6700 XL?
<KaiL> at least dapper seams to fail on it..
<dieman> grmbl, found a awful horrible networkmanager bug
<dieman> must fix
<dieman>         nm_gconf_wso_set_key (NM_GCONF_WSO (security), "FIXME", 5);     /* FIXME: What to do about Enterprise keys? */
<dieman> woo!
* dieman tries to build a fixed nm-applet
<Pygi> dieman: if it works (the patch),please file a bug,and attach patch? ^_^
<dieman> yah
<dieman> bug is filed
<dieman> bug #37924
<Ubugtu> Malone bug 37924 in network-manager network-manager-gnome "gnome applet loses wpa enterprise configuration" [Normal,Unconfirmed]  http://launchpad.net/bugs/37924
<Pygi> is that 0.6.2?
<hunger> Arg! My box no longer boots!
<dieman> bah
<hunger> I hope it is the LVM timeout issue again.
<Pygi> dieman: hm?
<dieman> Pygi: is .6.2 out?
<dieman> my mirror must be out of date
<dieman> yah
<dieman> your right
<dieman> shoot
<Pygi> dieaman: yes, it is...you need to use master server (archive.ubuntu.com)
<Pygi> not any mirrors :P
<fabbione> night guys
<fabbione> cya in a few hours
<dieman> well, i maintain this mirror and its updated fairly often, but not often enough to catch some things ;)
<dieman> i'll check the newer sources to see if its in there
<dieman> its just a pain to use archive.u.c sometimes 'cause its slower than the local mirror :)
<dieman> yeah, its fixed there
<Pygi> fabbione: night
<Pygi> dieaman: yes, I know that ;)
<dieman> heh
<Pygi> dieaman: update every 10 seconds? :)
<dieman> every few hours, but should have checked the list in launchpad first for new versions
<Pygi> dieman: ah, right
* Pygi faints
<dieman> thanks, anyhow
<dieman> i'm really happy its working for the most part
<dieman> it will remove another one of those awkward moments with users
<dieman> 'oh, and your wireless configuration, just edit this file!'
<Pygi> =P
<Pygi> a lot more work needs to be done :-
<Pygi> :--
<Pygi> :-/
<dieman> Pygi: yeah, but its working for the most part right now
<Pygi> dieman: look up how many bugs =P
<dieman> yah
<dieman> i saw em
<dieman> its *hard* to get it to work with all drivers
<dieman> i've only had the opportunity to test it with intel cards for the most part
* Pygi yells at madwifi
<sivang> night all!
<Pygi> night sivang
<Seveas> Pygi, have ou seen my memo?
<jmg> !seen sabdfl
#ubuntu-devel 2006-04-09
<jmg> whats sabdfl's email address? mark@canonical.com?
<Seveas> jmg, that one would work
<Seveas> jmg, but his inbox is very crowded
<Seveas> maybe someone else can help?
<jmg> Seveas: some canonical corp guy?
<Seveas> jmg, depending on what the issue is, several others can be able to help you. Would you mind telling why you want to contact mark?
<jmg> business partnership?
<jmg> is that acceptable?
<Seveas> hmm - i forgot who did that, sec.
<jmg> thanks
<Seveas> jmg, seen this? http://www.ubuntu.com/partners/become - it suggests partners@ubuntu.com
<jmg> Seveas: thanks
<Seveas> np
<jmg> Seveas: and yes
<jmg> Seveas: but i wanted to talk to sabdfl, just hoping he was online i guess
<Seveas> hehe - well not right now and he'll be travelling tomorrow
<Seveas> so partners@ may be your best bet at getting a response 
<jmg> Seveas: Thanks again!
<ajmitch> jmg: and if you're looking at hiring NZ developers.. ;)
<jmg> ajmitch: maybe in 6 months :)
<lifeless> good morning!
<_ion> Good night.
<jono> hi all
<jono> is anyone actively looking into https://launchpad.net/distros/ubuntu/+source/gst-plugins/+bug/34597 ?
<Ubugtu> Malone bug 34597 in gst-plugins gstreamer-alsa "Cannot record using alsa + gstreamer framework" [Normal,Unconfirmed]  
<jono> ahh heh
* jono pats Ubugtu
<sladen> not I said the pussy cat in the corner
<jono> heys sladen
<lifeless> whens the next TB meeting ?
<nictuku> YYYY-mm-dd at HHMMUTC :-)
<OgMaciel> anyone from Boston going to Linux World tomorrow?
<trappist> how can I see all bugs ever reported on a given package in malone?  clicking "all bugs ever reported" only shows open bugs.
<LaserJock> trappist: try https://launchpad.net/distros/ubuntu/+source/<packagename>/+bugs-advanced-search
<fabbione> morning guys
<trappist> LaserJock: yeah, found that.  guess that's a bug on malone.
<Mithrandir> mdke_: bug 28512; this is a bug in installation-guide.  Mainpackage is the first package in the control file and debhelper is behaving according to spec here.
<Ubugtu> Malone bug 28512 in installation-guide "unexpected debhelper behavior renders postinst inoperative" [Normal,Unconfirmed]  http://launchpad.net/bugs/28512
<whiprush> jdub: ping
<whiprush> jdub: I keep checking my feed, no idea why it's blowing up planet ubuntu, so if it's too painful remove me temporarily please.
<zakame> hi all
<dholbach> good morning
<highvoltage> morning
<TheMuso> Hey dholbach.
<highvoltage> hi TheMuso 
<dholbach> hey TheMuso
<jsgotangco> fabbione: i just forgot about the server test - yes our server is god personified as a distribution cheers
<KaiL> hmm, why doesn't install nvidia-glx also enable it?
<fabbione> jsgotangco: there is another test you can do :)
<fabbione> jsgotangco: at the install prompt select lamp
<fabbione> that should auto-install apache+mysql+php5
<jsgotangco> fabbione: i actually installed lamp
<jsgotangco> it works
<fabbione> perfect
<fabbione> great
<jsgotangco> my co worker fainted when she saw mysql5 and php5 working ot of the box
<fabbione> eheh
<infinity> jsgotangco: So, she's easily impressed?
<infinity> jsgotangco: I'll happily take credit anyway.
<jsgotangco> it doesn't have modrewrite and mod python but easily remedied
<jsgotangco> not all lamp installations need it anyway
<infinity> rewrite is include, just not enabled by default.
<dholbach> heya infinity
<infinity> (because rewrite is a resource hog, and most people who thing they need it don't, so I prefer not to encourage it)
<infinity> s/thing/think/
<janimo> infinity: if you could find time to spin a xubuntu live I'd appreciate it :)
<fabbione> infinity: you better get these credits :) you deserve them
<infinity> KaiL: I can't really auto-enable nvidia-glx or fglrx without first tearing some holes in dexconf, so I can re-seed it in filthy ways in my postinsts.  It was on my TODO list, but not particularly high up there.
<KaiL> infinity, ah, ok
<KaiL> I might have found a card, on which the "nv"-driver fails... GeForce 6700 XT (some Medion-special-thing)
<infinity> KaiL: Now that all the drivers are modular, it makes sense to rethink the thing a bit anyway, so it may not happen until dapper+1.
<fabbione> KaiL: also because auto-enabling means changing a config file that the user might not want changed
<infinity> KaiL: Things like "well, with modular drivers, does that mean that if you explicitly install one, you want it to become the default?"
<HrdwrBoB> most likely yes
<janimo> jdub, is the xubuntu flight 6 announce to be sent to u-announce?
<HrdwrBoB> but potentially no
<infinity> fabbione: Well, hence why I was going to do it via dexconf, so I could pre-seed the driver (and some module enable/disable action), and only have the config regenerated if it was auto-generated in the first place.
<KaiL> Xorg and it's hardware detection is really a problem :(
<HrdwrBoB> but if 'no' you would now what you're doing
<infinity> fabbione: But it's sketchy at best, and not something I've bothere to pout any real thought into.
<fabbione> infinity: nvidia-thingy enable does that
<fabbione> it preseed debconf -> dexconf and regenerate the config
<KaiL> the best thing whould be, if udev could re-set the driver to the best one on every boot...
<infinity> KaiL: In the case of nvidia/nv or fglrx/radeon, Xorg autodetection won't fix anything anyway, cause you're still talking about having two drivers to drive the same card.
<KaiL> but would help at least against the "no X at all"-Problem, if you change the card
<infinity> fabbione: Oh, that's right, it DOES do it correctly now.  What it doesn't do (and the reason I wanted to muck with it) is disable modules that are incompatible with nvidia.
<KaiL> the best would be, if Xorg itself would do an auto-detection, including fallbacks to vesa and vga
<infinity> I think the world agrees with you, and it's been said many times before.
<infinity> None of that produces working code, though.
<fabbione> infinity: right, but actually.. it works perfectly fine here... even with these modules loaded
<fabbione> infinity: and modules are preseedable
<infinity> fabbione: Even accelerated?
<fabbione> infinity: very easily
<fabbione> infinity: i think so.. how can i check?
<infinity> fabbione: If so, then nvidia has fixed that, and I don't give a shit anymore. :)
<fabbione> it's not like i spend my day playing quake3
<KaiL> which modules are that?
<infinity> fabbione: I dunno, if you don't have any fancy 3D games around, just run glxgears and see if it seems appropriately smooth and silky and such.
<infinity> (Very scientific, I know)
<jsgotangco> glxgears come on
<jsgotangco> hah
<fabbione> infinity: glxgears crashes here due to the multi-multi-multi-head setup
<jsgotangco> well for stats yeah
<infinity> fabbione: Oh, special.
<fabbione> infinity: yeah.
<fabbione> infinity: well only in fullscreen
<infinity> I'll have to re-test this whole mess on Zofia's machine soon then, before I put those bugs to rest.
<fabbione> otherwise is smooth and soft
<KaiL> fabbione, another big issue on Xorg - there are many usefull extentions, but many of them are incompatible to each other...
<KaiL> Xinerama, DRI/GLX, RANDR, RENDER, COMPOSITE...
<fabbione> KaiL: not all of them...
<fabbione> i use Xinerama+dri/glx
<fabbione> at least
<fabbione> probably more
<infinity> And RandR.
<KaiL> yes, some work
<infinity> Everyone uses RandR.l
<infinity> Render and Composite are entirely dirver-dependant, and either work or don't.
<KaiL> but Xinerama + Randr doesn't work (at least on i810)
<infinity> KaiL: You mean, eg, using RandR to resize the individual Xinerama surfaces?
<KaiL> yes
<infinity> KaiL: I suspect that's more of a missing feature than an incompatibility.
<KaiL> or that
<infinity> I suspect no one cares because Xinerama is a broken and hideous spec that should just get eaten by the RandR engine over time anyway.
<KaiL> ;)
<mdke_> Mithrandir, ok, I guess I got the wrong bug? this is a bug on ubuntu-docs assigned to you. i'll dig out the number
<mdke_> Mithrandir, bug #27906
<Ubugtu> Malone bug 27906 in kubuntu-docs "Typo in kubuntu-docs" [Normal,Confirmed]  http://launchpad.net/bugs/27906
<jmg> is k3b hosed in current dapper
<jmg> or is it the kernel + cdrecord?
<sivang> good morning world
<sivang> jmg: cdrecord worked fine last time I tried, what are the issues you're experiencing ?
<Mithrandir> mdke_: no, it's the right bug.  mdz assigned it to me last night.
<mdke_> Mithrandir, are you perhaps talking about a different bug?
<mdke_> we may be at cross-purposes
<Mithrandir> mdke_: I'm not talking about the kubuntu-bugs one, no.
<mdke_> ok, I'm not sure I can help with installation-guide, but Ill give it my best shot, what's up?
<Mithrandir> mdke_: but as you noted in the bug log, the docteam doesn't touch that package.  Do you know who does?
<mdke_> Mithrandir, yes, Kamion 
<Mithrandir> heh, 'k
<Mithrandir> and thereby me, I presume.
<mdke_> is he off?
<Mithrandir> no, but I'm also part of the installer team
<mdke_> oh right. Dude you're on all the teams
<Mithrandir> heh :-)
<Pygi> Seveas: around?
<pitti> ajmitch: ping
<janimo> infinity, ping
<Kamion> Mithrandir: I've been thinking of reorganising the espresso source package
<Kamion> Mithrandir: I'm increasingly fed up with having to create .debs out of everything and its wife in the installer, and I note that the partman source package already takes the approach of "automatically merge a load of other source packages into this one and rebuild them"
<janimo> Kamion, thanks for the iso builds. Can yesterday's images be tagged as flight 6 so they have a permanent link?
<janimo> they seem to be installable by a couple of accounts
<Kamion> Mithrandir: what do you think of just fetching all the source packages for all the installer bits at espresso source package upload time, and moving all the espresso component bits into the main source package?
<Kamion> janimo: it's very irregular for the very first build to end up as Flight N; I was expecting you to target Flight 7
<Kamion> particularly since e.g. some bits of the installer have moved on from Flight 7
<Kamion> from Flight 6
<janimo> Kamion, ah. that's because first builds rarely work ;)
<Kamion> indeed
<janimo> but ok then I'll target f 7
<Kamion> still, I suppose it's possible, just surprising
<janimo> well people installed it and they say it's just fine
<janimo> and two extra weeks of testing time for those waiting for iso-s seem tot be worth it
<Kamion> fair enough
<janimo> mvo, morning and daily pokage ;)
<janimo> pitti, hi
<pitti> hey janimo 
<janimo> there was a problem with at_console you discussed with mjg59 a few days ago
<pitti> yep
<janimo> I am wondering if what I see is related
<seb128> is an external CD drive supposed to be listed by fstab?
<janimo> after killing gdm and logginh into xfce via startx
<janimo> I no longer have the right to shutdown
<janimo> hal and system dbus were not restarted
* sivang hugs pitti 
<pitti> janimo: why should they?
<janimo> is dbus-send the best way to test this?
<pitti> hi sivang 
<janimo> pitti, no they shouldn't I am just saying 
<pitti> janimo: no idea, but that sounds like a gdm issue rather
<janimo> is soemthing in the at_console privileges tied to gdm or the 7th console?
<janimo> pitti, ok I'll look at the sources involved
<pitti> janimo: no, I don't think so
<seb128> Kamion: should https://launchpad.net/malone/bugs/37673 be reassigning to some installer part or it's NOTABUG?
<Ubugtu> Malone bug 37673 in gnome-applets "disk mount applet always shows an "cdrom1" device that doesn't exist." [Normal,Needs info]  
<pitti> janimo: it's just used for g-p-m, g-v-m, and network-manager
<seb128> Kamion: external CD listed by fstab
<janimo> pitti, and hal for shutdown?
<seb128> (so the guy still gets a volume icon when there is no CD drive plugged)
<pitti> janimo: no
<janimo> or that is via g-p-m
<mvo> janimo: good morning :)
<pitti> janimo: yes, g-p-m needs to go through hal
<pitti> janimo: but AFAIK gdm shuts down directly, not via hal (right, seb128?)
<seb128> pitti: correct
<janimo> pitti, hal has policy at_console="true" in it's dbus conf, that's what I meant
<Kamion> seb128: either partman or notabug, not quite sure this early in the morning
<seb128> Kamion: I'll reassign to partman so, feel free to reject it
<infinity> janimo: Xubuntu livefs is on my TODO, but it's #3 on the list or so (I assume that's what the ping was for)
<janimo> infinity: right, but not hurry. thanks
<pitti> janimo: yes, that's for apps that want to use hal to do power management
<Kamion> maswan: would you be so kind as to kick off a mirror of http://cdimage.ubuntu.com/xubuntu/releases/dapper/flight-6/ ?
<janimo> pitti, rigth, the xfce logout is directly calling hal. I'll investigate, since it does not seem to affect gnome
<pitti> janimo: then this could be related to that bug
<janimo> pitti, is it written up somewhere? if not I'll search irclogs
<pitti> janimo: it's a race condition right now; if you hit an unlucky time, the foreground console at the time the login manager restarts might be wrong
<janimo> and also is this ubuntu specific or hal upstream at_console prob?
<infinity> Kamion: Regarding that Flight6-on-i2o bug, I can't see how we're missing adding the module to the initrafms, if the LiveCD works (as he claims), and an espresso install from Live works (again, his claim), it's only a system created from d-i that seems to explode on him...
<pitti> janimo: bug 37181
<Ubugtu> Malone bug 37181 in dbus "at_console does not adapt to console changes" [Major,Unconfirmed]  http://launchpad.net/bugs/37181
<janimo> pitti, thanks
<pitti> janimo: ubuntu specific
<janimo> in my case there's no 'login manager'.Is it used in  a braoder sense here, does startx qualify?
<Kamion> infinity: could be the RAIDness instead, I was just guessing at i2o
<maswan> Kamion: done
<Kamion> infinity: espresso doesn't support RAID so that would be the differentiator
<Kamion> maswan: thanks
<janimo> Kamion, thanks
<janimo> any ubuntu-announce moderators here? I'd like to announce xubuntu f6. Also if the text needs preview before sending I'd appreciate someone looking over it
<infinity> Kamion: But it shouldn't be using software md anyway... Hrm.
<infinity> Kamion: Achwell, I'll try to squeeze some more info from him before we pick someone to blame.
<Kamion> janimo: please wait until maswan's finished mirroring
<janimo> Kamion, oh sure I won't announce till this evening
<Kamion> janimo: you should also just send rather than try to find a moderator first; I'll review your text if you like
<janimo> just wanted to know who to talk to before that
<Kamion> this is appropriate for -announce, no need to find a moderator
<Kamion> infinity: can you point me to a copy of the sources.list used by the buildds?
<Kamion> infinity: for a breezy-security upload
<infinity> Sure.
<Kamion> infinity: trying to work out what a debian-installer upload to breezy-security will do
<Kamion> (apart from horribly confuse us all)
<infinity> deb http://jackass.ubuntu.com/ breezy main
<infinity> deb-src http://jackass.ubuntu.com/ breezy main
<infinity> deb http://jackass.ubuntu.com/ breezy-security main
<infinity> deb-src http://jackass.ubuntu.com/ breezy-security main
<infinity> deb-src http://jackass.ubuntu.com//security/ breezy-security/
<infinity> The only problem you'll have is if you need to do more than one upload where A build-deps on B, since we don't have binaries in accepted to build from.
<Kamion> pitti's pre-publishing to avoid that
<infinity> So, you need to get me or pitti to silently release the binaries from A before you can build B.
<infinity> Yeah, cool.  No big deal.
<maswan> Kamion, janimo: done
<pitti> infinity: just did so
<janimo> maswan: thanks
<pitti> infinity: binaries will be there in 55 minutes
<maswan> only install isos, right?
<tepsipakki> Kamion: do you plan on adding debian #348509 to dapper?
<Kamion> maswan: cheers; yes, just install
<Ubugtu> Error: I tried to send you an empty message.
<pitti> infinity: (yay LP turnaround) :/
<infinity> pitti: 55 minutes?  They're there now, dude.
<Kamion> tepsipakki: yeah, it's on my to-do list
<pitti> infinity: not in the archive
<pitti> infinity: I just uploaded them to LP
<infinity> pitti: security builds from jackass, publishing to jackass is instant.  Or is jackass only a mirror now?
<tepsipakki> Kamion: great news :)
<pitti> infinity: it's just a staging server now
<pitti> infinity: after amber, the next LP security upload cronjob runs at :45, then the publisher in cron.daily at :00
<infinity> I'd be curious about that, actually, since amber still goes through the motions of publish/apt-ftparchive/etc before the upload to drescher.
<pitti> infinity: do you happen to plan a svn merge/sync to debian soon?
<pitti> infinity: if not, I'd like to grab the RPATH fix from -5 and apply it to our current version
<pitti> infinity: I sponsored the Debian upload and tested it pretty thoroughly
<jmg> hi all
<jmg> any ideas how i can install to an lvm from flight6? espresso isnt handling lvm correctly
<Kamion> jmg: by design, espresso does not support LVM or RAID. Use the traditional installer.
<infinity> pitti: I had a couple more fixes I wanted to get into upstream SVN before syncing.  It the rpath thing urgent for you, or just annoying?
<jmg> Kamion: how do i launch it from flight6?
<Kamion> jmg: grab the install CD, not the live CD
<pitti> infinity: it should be fixed for dapper, but not terribly urgent
<Kamion> boot from it
<jmg> Kamion: damn ok
<pitti> infinity: the /tmp rpath shouldn't affect us since we rebuild binaries
<pitti> infinity: but having rpaths in the apache library at all is still ugly
<jmg> Kamion: i see espresso is written in python. i could fix the lvm support :)
<infinity> pitti: Having RPATH anywhere is ugly.
<Kamion> jmg: it uses bits of the traditional installer for partitioning support, and gparted for manual partitioning; believe me it will be tortuously hard
* jmg files bug against the livecd to get text installer launched as well
<Kamion> jmg: please don't bother
<jmg> added*
<Kamion> jmg: it's not possible
<jmg> Kamion: it sort of supports lvm already though
<Kamion> we do not have room on the CD
<Kamion> jmg: that's a bug
<jmg> Kamion: the other components are already there
<Kamion> no they aren't
<jmg> how does espresso do the install then?
<Kamion> it copies the live filesystem
<jmg> magic?
<jmg> i see
<Kamion> the traditional installer requires a pool of .debs
<jmg> so i really am better off getting the install cd ;)
<Kamion> yes
<Kamion> we don't have space to put them both on the one CD, I'm afraid
<jmg> is espresso the gui installer for dapper?
<Kamion> the only LVM "support" I'm aware of in espresso is that it will probably display existing LVM PVs
<jmg> or just the quick-hack-copy-livecd-image installer?
<Kamion> we're referring to it as the "live CD installer"
<jmg> it displays two lvs
<Kamion> but yeah
<jmg> and then tries to format them as disks :/
<Kamion> jmg: oh, in gparted?
<jmg> before gparted
<Kamion> ok, that's just a bug
<Kamion> I don't have time to make LVM support work properly; I'd rather it didn't work at all than half-worked
<jmg> Kamion: *nods* i could add a check to see if the disk is lvm and remove it from the list if requred
<Kamion> mm, it's messy to do in espresso, would fit better in partman
<Kamion> ... somewhere
<jmg> heh
<jmg> ok
<jmg> well i really like drake
<Kamion> but sure, that approach would be reasonable, noting that the code is shared with the traditional installer so it can't just be unconditional removal
<jmg> but i dont get the aero glassalike theme
<jmg> at least placement etc
<jmg> and size
<jmg> ok rebooting
<Kamion> hmm, I think this might need to go in parted_devices.c
<Kamion> the deeper the better ...
* pitti fixes password leakage in samba
<pitti> meh, d-i, wpasupplicant, samba - keeping passwords secret is not our greatest strength ATM :/
<infinity> pitti: Hrm?
<infinity> pitti: What's there to fix?
<infinity> pitti: oh, I haven't uploaded to dapper yet, that's what.
<pitti> infinity: http://us1.samba.org/samba/security/CAN-2006-1059.html
<infinity> pitti: It's sitting here, pending me merging another patch.  I wouldn't bother, unless you think it's uber-urgent.
<pitti> infinity: oops, sorry, too late; I just uploaded it
<infinity> Oh, alright then.
<pitti> infinity: feel free to just ignore the current version and changelog if you'll upload 3.0.22 then
<janimo> pitti, I assume you have the same objections against xubuntu-system-tools for main as for evince-gtk, given it's a fork/dupe of gnome-system-tools?
<pitti> janimo: yes, in principle - how big is the diversion?
<seb128> next is nautilus-gtk and evolution-gtk :p
<janimo> pitti, smaller than for evince
<infinity> pitti: Oh, if you've seen the log bypass vuln for MySQL 5.0, you can happily ignore that too, it's going in my next upload...
<infinity> (The upload I'd be doing if my laptop would stop overheating..)
<janimo> seb128: nautilus and evolution are _definitely_ not getting into xubuntu
<pitti> janimo: ... multibuild
<seb128> soon gnome-desktop-gtk is coming :)
<pitti> infinity: yes, it was next on my list; thanks :)
<janimo> pitti, yeah I'll look at cdbs multibuild as cdbs2 is not ready
<pitti> janimo: or just do it the old way then
<janimo> seb128: really you mentioned the two apps are the least appealing for a gtk-only version ;)
<janimo> top 3 in gnome bugzilla, no thanks :)
<seb128> janimo: guess what, that was on purpose
<seb128> :p
<janimo> I know
<seb128> what media player do you use?
<seb128> are you going to rebuild totem with gtk? :)
<infinity> pitti: Have you confirmed that it doesn't affect MySQL 4.x?  If not, I'll poke that in a bit.
<pitti> infinity: no, I just wanted to ask yo
<pitti> you
<pitti> infinity: but let me dig that out then
<janimo> pitti, "or just do it the old way then" ? what do you mean
<seb128> debhelper probably
<pitti> janimo: good ol' debhelper
<seb128> pitti: if you start switching GNOME packages from cdbs to debhelper I'll not be happy :p
<janimo> pitti, but that means debian maintainers of said package go to debhelper.
<infinity> pitti: Upstream only applied the fix to the 5.x branch, so I think I'll actually have to look at the code to see if it affect 4.0/4.1  (I don't tend to trust upstreams when they claim "only affects foo")
<janimo> anyway I mailed g-s-t maintainer but no response so far
<pitti> infinity: indeed, we had such cases with mysql before
<janimo> seb128: I just saw the media player q
<janimo> right now it's xfmedia
<infinity> pitti: Right, I'll look at it after I finish testing 5.0, then, and upload to warty/hoary/breezy if necessary.
<pitti> infinity: http://rst.void.ru/papers/advisory39.txt <- yay, my Russian is far from good enough to decipher that :)
<janimo> but I don;t like it much. another could be plain xine-ui or gxine
<pitti> infinity: thanks
<pitti> janimo: hm, true, converting gnome packages to debhelper is bad
<pitti> janimo: but it shold be no problem (just a bit ugly) to get the same effect with cdbs rules - you have to write the unpack and build code anyway (with debhelper, too)
<janimo> pitti, yes. Need to see which is the lesser evil: dup source packages or uglier rules in someone else's package
<pitti> janimo: the latter IMHO
<janimo> pitti, IMHO too, but it invloves other people who have the most say init I think
<pitti> janimo: why, we can fork it for ubuntu
<Mithrandir> Kamion: (re merging espresso): I'd be quite happy with it.
<jordi> where do I mail UVF exception requests?
<dholbach> jordi: main? universe?
<jordi> dholbach: main, I guess. It's the aspell/myspell Catalan dictionary.
<jordi> current in Debian/Ubuntu is the horror, I just fixed it.
<dholbach> jordi: then it's cjwatson and mdz
<jordi> It's named 0.5-1, but it's just text files that change.
<jordi> ok, will try those.
<jordi> is there a wiki page, or email?
<Kamion> Mithrandir: yeah, I think it might make it easier for third parties to hack on it privately too (although increases the risk of the result being a mess, but I think we have to live with that)
<Kamion> I'll have a look at it soon
<Kamion> jordi: http://wiki.ubuntu.com/DeveloperResources
<ogra> doko, ping
<ogra> doko, bug 37545, you seem to run the ati driver, could you try with "radeon" in xorg.conf ?
<Ubugtu> Malone bug 37545 in gnome-screensaver "hitting a key while the "ants" screensaver is running terminates the X-session" [Major,Needs info]  http://launchpad.net/bugs/37545
<jordi> thanks Kamion 
<jordi> Kamion: I'll give this a few days of testing in unstable.
<hunger> Why is my screen suddenly all messed up when shuting down the system?
<hunger> Looks a bit like the startup-screen, but with text scrolling all over it and the colors all wrong.
<doko> ogra: will try, but that's what the autoconfiguration did detect
<ogra> doko, yes, but i had other bugs with the same effect ... apparently the autoconfiguration is a bit outdated
<Kagou> hi
<hunger> Any idea which distro I can use to fix up my LVM? Dapper coredumps when trying, breezy does not work at all with the HDD.
<Pygi> Mithrandir: hi hi, around? ^_^
<Mithrandir> Pygi: yes, but a bit busy.
<Pygi> Mithrandir: will talk later then...
<janimo> mvo, would there be an interest in a unionfs patch to pbuilder, as I see there are ubuntu specific bits in it?
<Kinnison> hunger: have you tried to work out what bit of pvmove segfaults?
<siretart> janimo: have you looked into schroot/sbuilds capabilities for building on lvm snapshots? great stuff! :)
<Pygi> janimo: I think he's currently working on some bugs ;)
<mvo> janimo: the patches I applied so far are very little changes, good value :) I may apply the unionfs patch if it's not too instrusive
<janimo> siretart, not for sbuilds specifically just to make tar extraction go away
<janimo> and have not looked at lvm 
<janimo> siretart: are those in pbuilder now in debian?
<siretart> janimo: I don't think so. I switched from pbuilder to sbuild on my laptop. but schroot can also extract chroots from tarballs, if you like that
<Kamion> janimo: any reason you couldn't do cdbs multibuild by creating two extra debian/rules-* files which are basically ordinary debian/rules files except that they use a different build directory, and a very simple debian/rules file which just calls both subrules files in succession?
<Kamion> wouldn't be very pretty, but ought to be relatively easy for cdbs-ish people to maintain
<hunger> Kinnison: No, I can no longer boot the box with that problem.
<Kinnison> hunger: erm, oops :-(
<Kinnison> hunger: not even with a dapper live CD?
<janimo> Kamion, I did not think of specific ways to tackle the problem. As I thought cdbs maintainers don't want their packages touched in anay way
<janimo> but will look at a clean way
<hunger> Kinnison: Dapper's LVM stuff coredumps (pvmove).
<hunger> Kinnison: Breezy live does not want to access the drive at all:-(
<Kinnison> hunger: right, so can you not boot a live cd and strace pvmove ?
<Kamion> janimo: well, I don't know if they'd want their packages touched in this way either - just a suggestion
<Kinnison> hunger: see at what point it dumps?
<hunger> Kinnison: So I am trying to download FC to fix my dapper.
<janimo> siretart: so is sbuild better than pbuilder? You need a lvm partition for it?
<hunger> Kinnison: I could... but then all my data is in that LVM... incl. all my passwords to i.e. launchpad and my email accounts.
<Kinnison> hunger: aah :-)
<Mithrandir> hunger: make a backup first and work on the backup.
<Kinnison> hunger: that's why you have a recent and full backup right? Like a good user?
<hunger> Kinnison: I do have backups of all my data.
<hunger> Kinnison: But I still do not want to resetup a new box to use it.
<Kinnison> fair enough
<hunger> Kinnison: Currently I am on a windows box (with irc running on my server).
<Kinnison> hunger: sounds painful
<hunger> Kinnison: I can not really delete any of those two boxes:-(
* Kinnison nods and feels your pain
<triceratops> ping dholbach, may I ask a question about ubuntu-example-content...
<dholbach> triceratops: fire away
<siretart> janimo: sbuild itself requires a 'real' chroot. rleigh enchanced it so that you can build on any chroot which schroot supports. and schroots supports 'plain' chroots, block devices, lvm-snapshots or tarballs. you are way more flexible with that solution.
<janimo> siretart: hmm never tried it
<triceratops> Do you know about the free video and audio projects in Europe. There are a few which might be interesting for example-content
<siretart> janimo: if you do, then better try the versions from debian unstable. I didn't get to write UVF exception request for the 2 packages yet
<dholbach> triceratops: you might want to talk to heno - he searched a lot for open and nice content in the internet - he did the actual selection
<janimo> siretart: ok, thanks
<triceratops> dholbach: may I have his email address ...
<siretart> janimo: I assume it wouldn't be hard to enhance schroot to build on unionfs volumes, but since it does cope with lvm, I don't see the need for that..
<dholbach> triceratops: he's on irc atm
<triceratops> dholbach: yepp, he's on #ubuntu-accessibility... Should have asked whois first. *tsstsstss*
<doko> ogra: is there already a report open for the autoconfiguration? which package?
<ogra> should be xserver-xorg 
<ogra> but no, i just have other GL screensaver bugs with that coming up
<hunger> Kinnison: Yahoo! It boots agian!
<hunger> Kinnison: FC5 came to the rescue:-(
<hunger> Which has a sucky (but at least working) rescue CD.
<Kinnison> How odd
<jono> hey ho
<jono> mjg59, ping
<mjg59> jono: Hi
<mjg59> jono: I have stuff written for you, but I want to try to sort out a generic bug target
<jono> mjg59, no worries
<jono> mjg59, you want to be a rockstar on lugradio tonight?
<hunger> Kinnison: I opened #38007 about the pvmove issue (incl. strace output).
<Kinnison> hunger: hopefully someone with an LVM will be able to debug it :-)
<ajmitch> someone with LVM & willing to sacrifice a filesystem
<mjg59> jono: Sounds good
<jono> mjg59, mail me your phone number - we will call you at around 8pm
<mjg59> jono: Ok - address?
<jono> mjg59, this will be a five minute update :)
<jono> mjg59, jono AT jonobacon DOT org
<hunger> ajmitch: pvmove is harmless.
<ajmitch> it's *meant* to resume properly, but anyone testing has to take that on faith :)
<hunger> ajmitch: It mirrors the data and only removes the actual data once that is done.
<hunger> ajmitch: So it is harmless when it coredumps early:-)
<mjg59> jono: Done
<jono> mjg59, nice
<hunger> Kinnison: Is there anything I can do to help debug the pvmove issue?
<Kinnison> hunger: No idea really
<Kinnison> hunger: it fails after talking to devicemapper
<Kinnison> hunger: so I'm guessing it was compiled with the wrong libdevicemapper or something, but I'm not sure
<Kinnison> hunger: try downloading the source, recompiling it and see if it works better?
<hunger> Kinnison: I'll try that. Thanks!
<Kinnison> hunger: and even if it fails, you'll be able to provide a better debug trace by compiling it with debugging symbols and using gdb :-)
<hunger> Kinnison: lvm2 build depends on libdlm-dev which in turn depends on libdlm1 which is not a dependency of lvm2. Is that OK?
<Kinnison> hunger: if the shlibdeps claim it's not needed, I imagine it's okay unless it's being dynamically loaded or something odd
<Kamion> it's possible that e.g. everything is inlines
<Kamion> inlined
<Kamion> or that it just needs some constants
<hunger> Kamion: Build fails without that builddep, so it seems to be needed.
<Kamion> dholbach: FYI libsexy2-dbg in binary NEW is empty apart from documentation; perhaps you forgot to rename a .install file?
* mdke hugs dholbach 
<hunger> Kinnison: pvmove crashes after a rebuild just as well.
<Kinnison> hunger: so build it -g -O0 and hit it with gdb :-)
<pitti> mdz: I reviewed dovecot, please see bug 30314 (waiting for your approval)
<Ubugtu> Malone bug 30314 in dovecot "dovecot 1.0beta3 is out, but dapper is still on alpha ;)" [Wishlist,In progress]  http://launchpad.net/bugs/30314
<Mithrandir> maswan: is ftp.acc.umu.se ill or something?  I get < 1MB/sec from it.
<Riddell> pitti: the cups KDE fix sorts out a compile problems that existed for a while but doesn't fix the other problems.  it looks like we'll need an old cups in the archive to get it to work
<pitti> Riddell: I didn't yet see the promised API compatibility patches
<hunger> Kinnison: Where does our lvm2 come from?
<hunger> Kinnison: The version we use is not even mentioned in debian's changelog
<Riddell> pitti: it's r5329
<maswan> Mithrandir: perhaps one frontend has significant load?
<maswan> Mithrandir: I'm off now for a while though, feel free to check the different IPs. :)
<Riddell> pitti: which fixes http://bugs.kde.org//show_bug.cgi?id=124157
<Mithrandir> maswan: I tried from a few different boxes.
<Ubugtu> KDE bug 124157 in general "KDEprint incorrectly uses private CUPS APIs _ipp_add and _ipp_free" [Grave,Unconfirmed]  
<Riddell> but not the longer standing issue of http://bugs.kde.org//show_bug.cgi?id=115891
<Ubugtu> KDE bug 115891 in general "KDE doesn't work with CUPS 1.2" [Normal,Unconfirmed]  
<Mithrandir> maswan: it seems like the backend might be loaded, since it acellerates for a while, then is cut off.  Repeat.
<pitti> Riddell: and kdeprint won't be ported to 1.2 anytime soon?
<pitti> Riddell: i. e. are we forced to revert back to 1.1?
<Riddell> pitti: well he's been promising since November according to that bug, but I've not seen any development
<pitti> Riddell: it's important that we decide this very soon, before I evaluate 1.2rc=1
<Riddell> pitti: I've been testing an SVN CUPS and it makes no difference
<pitti> Riddell: no, I meant, if we can port kdeprint to 1.2, then I'd like to upgrade cups to 1.2rc=1
<pitti> Riddell: but if that is utterly complex, and we don't have any other chance, then we should revert to 1.1 ASAP
<pitti> (I wouldn't like that, though)
<dholbach> Kamion: arg, will look into it
<dholbach> mdke: anytime :)
<Riddell> pitti: I don't think we'll be able to port kdeprint
<hunger> Kinnison: I tried to build the lvm2 debs from debian. Those need a newer devicemapper (userspace) which in turn won't build on ubuntu:-(
<pitti> Riddell: that means we have to revert?
<Kinnison> hunger: Hmm
<Riddell> pitti: I don't see any other way at the moment
<Riddell> pitti: mandriva have also changed to cups 1.2, I should talk to them to see how they plan to resolve the problems
<pitti> Riddell: yep, that would be nice; maybe they ported it
<Riddell> I don't think so, as far as I know it's broken for them too but I'll e-mail the maintainer
<pitti> Kamion: which package is responsible for TZ selection in the installer? in particular, where does it take the translations of the countries from? (bug 28690)
<Ubugtu> Malone bug 28690 in glibc "Translation bug on tzconfig" [Normal,Unconfirmed]  http://launchpad.net/bugs/28690
<pitti> Riddell: can you make head and tail of bug #29648? Do you really use gnome-cups-icon under KDE?
<Ubugtu> Malone bug 29648 in gnome-cups-manager "Printing Notification Icon misplaced under KDE" [Minor,Unconfirmed]  http://launchpad.net/bugs/29648
<Kamion> pitti: tzsetup
<sivang>  /msg Kinnison Hey Daniel!
<sivang> wops
<Kamion> pitti: it has its own translations
<pitti> Kamion: ah, thanks
<Kamion> because they're translations of zones not countries
<Riddell> pitti: not by default we don't but someone can always install it
<pitti> Kamion: shall I upload a fixed pacakge, or do you prefer to handle that yourself?
<Kamion> pitti: please don't, I want to get it sorted out upstream
<pitti> ok, then it's ok if I assign it to you?
<Kamion> since it's still buggy upstream
<Kamion> pitti: sure
<pitti> Riddell: so, will NotShowIn=KDE help?
<Riddell> pitti: it'll hide the application from KDE, that's fine since KDE has equivalent programmes (although they don't work just now with cups 1.2)
<pitti> Riddell: alright, then I'll do that for this bug; thanks
<Riddell> pitti: but that .desktop file should really have a Categories line, I don't understand how it doesn't end up in the Gnome lost and found category
<Riddell> mvo: did you add .desktop files for ubuntu-desktop and kubuntu-desktop to app-install-data?
<mvo> Riddell: no, I don't think that is the right application for this. 
<Riddell> mvo: why not?
<jmg> ubuntu-desktop-files?
<mvo> Riddell: well, it feels wrong. this app installer is about applications, we have very little exceptions (like the gstreaer, xine stuff). adding a desktop enviroment, I'm not sure
<Riddell> mvo: just seems to me there should be an easy way to install them, there's a lot of questions on #ubuntu and #kubuntu about how to install the other desktop
<mvo> Riddell: hm, right. I'm not totally against it, I was merely uncertain. can you install ubuntu-desktop on a kbuuntu system without removals?
<mvo> there are no conflicts at all?
<Riddell> mvo: yep, no conflicts
<doko> Diziet: I need to revert your fontconfig change (removing the aliases for the Adobe standard fonts)
<mvo> Riddell: ok, if there is enough  demand, I'll add it
<Riddell> hmm, so I need to set up a poll on ubuntu forums to convince mvo of the demand :)
<mvo> Riddell: just nag me until I give in, that usually works (well, at least for my GF)
<infinity> I dunno, could cause more issues than it solves.
<infinity> kubuntu and ubuntu /do/ coexist fine, but the first thing you see pepole asking after they discover they can install both is "eek, now my menus have twice as many apps in both desktop environments and now I want to switch to just one or just the other, and there's no way to do that, help!"
<infinity> Perhaps it's best to leave "install two (or more) meta-desktops at once" to people who at least have a tiny bit of understanding about how to add and remove packages with a real package manager.
<mvo> good point! another possible  problem is that iirc kdm will replace gdm and that will suprise some people too
<jdub> and stuff like the kubuntu usplash
<mvo> *nod*
<Riddell> he he, we do get a few surprised people with the "I installed kubuntu and now my bootup is all blue!"
<giftnudel> you'd need to provide a kde meta-package ...
<giftnudel> hehe
<ogra> thats what kubuntu-desktop is
<giftnudel> ogra: yes, I meant like a package which you install in ubuntu which doesn't do all the stuff about ...
<giftnudel> above
<ogra> sudo apt-get install kubuntu-desktop && sudo apt-get remove kdm :)
<giftnudel> and then you wonder why kubuntu-desktop is not installed and you do it again and again ...
<giftnudel> I hate it, gnome-screensaver activated 3 times so far, while I was writing ...
<ogra> yes, i'm still diggin on that
<infinity> Oh, speaking of gnome-screensaver...
<giftnudel> but it makes the desktop more entertaining ...
<ogra> nooo
<ogra> infinity, its not on my TODO today
<infinity> ogra: Your patch to mplayer seems to completely disable the screensaver when I run it.  ie: I have to manually enable it afterward.
<infinity> And no, mplayer isn't crashing.
<infinity> (Though even if it were, that really shouldn't leave me with no screensaver. :/)
<ogra> infinity, i just added gnome-screensaver to the kscreensaver code ... it gets only disabled if you use the --no-screensaver option 
<infinity> Seriously?  Then something else is randomly disabling it, and I assumed it's mplayer, cause that's the only thing I use that SHOULD be disabling it?
<ogra> since the original code switches off the screensaver completely instead of poking it, it wont get enabled if mplayer crashed
<infinity> Greeeaaat.
<infinity> Oh, no, I have stop-xscreensaver=true in .mplayer/config
<ogra> but i refuse to write new features for screensaver handling that werent there before
<infinity> So, yeah, it probably is mplayer.
<ogra> its the way it always handled screensavers ... g-s-s was only added to that function
<infinity> TBH, the old screensaver handling in mplayer never worked well anyway.  Now it works a bit TOO well.  Not sure which is worse.
<ogra> (its the most evil way btw)
<ogra> the right way is to have a timeout loop that pings the screensaver on a regular base ... which is apparently implemented in all other mediaplayers i touched
<ogra> mplayer is a bit different
<janimo> Kamion, could you proof-read this? https://wiki.ubuntu.com/XubuntuReleaseNotes
<Kamion> janimo: I'm not sure about the last bit about checking whether the bug was reported beforehand; the sentiment is fine, but many bugs that people may notice (e.g. installer bugs) should not be assigned to xubuntu-team
<janimo> Kamion, ok I'll delete it. But the last bit is only for the ~10 xubuntu bugs
<Kamion> say so, then :)
<janimo> the reports are still directed to ubuntu as in the original mail
<janimo> as I copy pasted from Tollefs mail
<Kamion> otherwise, it looks fine
<janimo> ok, thanks I'll modify the last bit 
<maswan> Mithrandir: Ok, I guess I'll poke Znarl for a bit less load then.
<janimo> ok just deleted the ref to xubuntu bugs and left the generic ubuntu link only
<maswan> Mithrandir: how quick does it drop for you?
<maswan> Mithrandir: I get a bit over 2M/s. :)
<infinity> Aww, isn't that cute, MySQL and PostgreSQL building at the same time on the hppa buildds.
* infinity challenges pitti to a DB duel.
<LarstiQ> heh
* mvo goes out for a bit
* hunger sighs.
<hunger> Breezy: Does not detect my HDD, dapper: pvmove coredumps, Etch: Does not detect my CDROM, FC5: works but is generally quirky.
<hunger> And all that just to fix my perfectly working dapper installation.
<hunger> FC5 complains about partitions not ending on cylinder boundaries when seeing discs partitioned in dapper. Is that something to worry about?
<giftnudel> I recently saw a "round to cylinder" option in espresso
<hunger> giftnudel: I just used plain fdisk... that asks for cylinder numbers by default.
<giftnudel> hunger: I just read a howto, where it says that for linux, there is no problem if they don't end on cylinder boundaries
<giftnudel> but some programs complain just because they can
<hunger> giftnudel: I wonder why it does not end on a boundary in the first place. I gave track numbers when creating the partitions. And dapper does not complain at all, it is just FC5 that does.
<giftnudel> hunger: in the howto, they mentioned diskdruid on rh 7.1 complaining without a reason
<giftnudel> so this might be a leftover
<hunger> giftnudel: I used fdisk on both distros. But FC5 *is* strange.
<giftnudel> hmm
* hunger loves lvm.
<hunger> Migrating to a new HDD is so easy with it (if pvmove works of course).
<Riddell> Kamion: in gtk espresso how does the ui get moved onto the autopartition page
<Riddell> Kamion: I have partman.py calling set_autopartition_choices, but nothing is moving the page on from the 
<Riddell> disk selection page
<Riddell> Kamion: oh, got it, set_autopartition_choices changes the UI page
<Kamion> Riddell: "messily". I guess you've found it
<Riddell> :)
<Kamion> I'd love to come up with a generally less messy way of moving between pages; I might look at that while trying to make pages disabled until espresso's actually ready for input
<seb128> pitti, carlos: why is gnome-btdownload not listed by rosetta as to translate?
<seb128> hum, https://launchpad.net/distros/ubuntu/dapper/+source/gnome-panel/+pots/gnome-panel-2.0/fr/+translate works fine
<seb128> carlos: but it's not listed by https://launchpad.net/distros/ubuntu/dapper/+lang/fr
<carlos> seb128: that page needs some love...
<seb128> https://launchpad.net/distros/ubuntu/dapper/+source/gnome-btdownload/+pots/gnome-btdownload/fr/+translate I mean
<seb128> carlos: so what page should be used to know what to translate for the desktop?
<carlos> seb128: as soon as I finish importing most dapper, I will give some love to that page
<seb128> the list is not autogenerated?
<carlos> seb128: we don't have a page with that concrete information
<carlos> at least not yet
<Riddell> pitti: talking of translations, koffice isn't being imported into the langpacks
<seb128> carlos: ok, thank you
<Riddell> pitti: koffice is like k3b, it has a separate koffice-l10n package (which is in universe)
<carlos> seb128: a user wrote this page: https://wiki.ubuntu.com/RosettaImportantPackagesToTranslate
<seb128> carlos: everything shipped by the GNOME language pack should be one a page by example
<carlos> seb128: we are going to implement that kind of page inside launchpad/rosetta 
<seb128> so people know what to do to get a desktop translated
<carlos> seb128: yeah, and same for kde lang packs
<carlos> or xfce
<seb128> do you know when that should be ready?
<pitti> Riddell: ah, I see; well, this should be mainly carlos' problem now, but if we need to build another set of langpacks from just buildds, I can add another special case for it
<seb128> because that's required if you want correct translations for dapper
<seb128> look at gnome-btdownload, I noticed that it's not translated this morning while trying a patch
<Riddell> pitti: good point.  I'll poke carlos if it doesn't sort itself out
<seb128> it's not listed by rosetta list of french packages to translate
<seb128> how do you expect people to figure they have to translate it?
<carlos> Riddell, pitti: Well, I will provide those files to be translated and available as part of language packs if you move them into main
<carlos> if they are in universe, we ignore them....
<carlos> seb128: I cannot give you a date, still working on language packs and dapper 100% ready to be translated from Rosetta...
<pitti> carlos: so far we specifically kept k3b-i18n and koffice-i18n in universe since they are empty anyway
<pitti> carlos: i. e. we need the built source packages to strip them, but the debs themselves are useless
<carlos> pitti: are the .po files inside the main packages then?
<pitti> carlos: they are in the koffice-i18n/k3b-i18n source
<pitti> carlos: so, if we need to promote the source into main for you, that's not a problem at all
<carlos> hmmm, so that means that I should have a list of packages from universe that we should import....
<carlos> pitti: well, I prefer them in main
<carlos> that means I don't need to add special code to handle those packages
<pitti> carlos: then we will promote them
<carlos> pitti: thank you
<Riddell> pitti: need a main inclusion review?
<pitti> Kamion: is it possible to have just a source package in main, but none of the resulting binaries?
<jono> is anyone looking into https://launchpad.net/distros/ubuntu/+source/gst-plugins/+bug/34597 ?
<Ubugtu> Malone bug 34597 in gstreamer "Cannot record using alsa + gstreamer framework" [Unknown,Unknown]  
<pitti> Riddell: for a bunch of po files? I hope not... :)
<carlos> pitti: btw, are you fixing the list of packages that are missing a .pot file?
<carlos> you or any other developer
<carlos> ?
<pitti> carlos: I'll try to look into them, yes
<pitti> carlos: some of them are false positives
<carlos> pitti: I'm able to detect them from the rosetta import queue
<carlos> not automatically
<Kamion> pitti: technically yes, although that source would be on anastacia's list for demotion
<carlos> but is easy to detect seeing the 'stalled' .po files that we cannot import
<pitti> yes, IIRC I threw a bug at you about that, right?
<pitti> Kamion: I mean, it wouldn't exactly hurt to have the empty debs in main, but they are just totally useless
<carlos> pitti: I filed some bugs, but seb told me that you are already aware of them
<carlos> due the list you maintain
<wasabi> https://wiki.ubuntu.com/ThirdPartyApt   <--- spec I'm looking for more opinions and interest on
<pitti> carlos: do you know any tool which counts the number of msgids and translated strings in a po file?
<pitti> carlos: msgfmt --statistics only counts the latter
<pitti> carlos: grepping the file twice wouldn't be a big deal, but maybe there is sth more efficient
<carlos> grepping it twice?
<pitti> carlos: grep --count for the number of msgids, and msgfmt --statistics for the number of translated strings
<carlos> pitti: you can either do that or just calculate the number of msgids from the --statistics count
<carlos> s/count/output/
<pitti> carlos: how?
<carlos> pitti: if you add untranslated + fuzzy + translated == msgid count
<pitti> carlos: it just shows me '48 translated messages'
<carlos> that's 48 msgids
<pitti> no, 48 msgstrs
<pitti> there are 49 msgids in that file
<carlos> the header does not count
<carlos> and your grep counts it as an extra msgid
<pitti> carlos: ah, I see; nevermind :)
<carlos> ;-)
<Kamion> fabbione: re your multipath-tools mail, I consider UVF exception granted now, I'm just making a note about future promotion to main
<fabbione> Kamion: ok sure. it has been tested *before* asking for UVF
<fabbione> Kamion: just to make sure we understand eachother
<Kamion> fine
<janimo> is jdub the announce list moderator?
<Kamion> mdz: FYI, I'm getting increasingly fed up with maintaining all the little espresso-* binary packages; Mithrandir and I have agreed that it would be better to move to a system like the one we use for partman (i.e. a set of scripts that suck all the component source packages into espresso, and make the espresso binary package itself contain all the components)
<Kamion> mdz: that'll make it easier to manage the whole thing, and hopefully make it easier for third parties to hack on after dapper release too
<Kamion> working on that now since I have several other components I need to add and I might as well do this first
<Kamion> (apt-setup, choose-mirror at least)
<Kamion> effectively, the espresso source package will be in a similar position to debian-installer; the component interface is thin enough that coordinated changes are very often needed anyway
<jono> is there a GUI way of dist-upgrading in Dapper?
<jono> as in, going from dapper to dapper+1 ?
<ogra> there is an upgrade tool (never tried it so i dont know if it has a gui part, but i guess so)
<ogra> its called dist-upgrader ...
<jono> but is anything planned to make this easy and clickable?
<ogra> yup i think so ... mvo is the guy who cares for it 
<_mvo_> jono: yes ,we have it for breezy->dapper as well
<_mvo_> ogra: it has a GUI :) the trouble is that there is currently no version without a gui :)
<jono> _mvo_, so will the gui for it be installed by default in dapper?
<_mvo_> jono: yes
<jono> cool
<jono> where do I find it to run it?
<_mvo_> jono: if you want to run it on breezy, make sure that you have "breezy-updates" for main and universe in your sources.list
<ogra> gah, dbs-edit-patch sucks ...
<_mvo_> jono: then add "deb http://people.ubuntu.com/~mvo/backports/update-manager /" to your sources.list and dist-upgrade, it should bring in new upate-manager, python-vte, pyhton-apt
<hunger> Is this splash thingy used during shutdown nowadays?
<ogra> yep
<hunger> I keep seeing something that looks like the startup splash thing with text scrolling all over it.
<hunger> ... or just the text like usual, but in a blue color (kubuntu).
<jono> _mvo_, hang on a sec, will this tool be included in Dapper so I can just click a button and upgrade to dapper+1?
<hunger> ... or a completly unreadable screen or the normal text as it used to be before.
<jono> (I am writing this into the book you see)
<Riddell> hunger: that's kdm calling usplash_down
<Riddell> hunger: it doesn't always do it at the right time
<hunger> Riddell: Ah, OK then.
<Riddell> hunger: any fixes welcome :)
<hunger> Riddell: So far I didn't see a "proper" shutdown splash:-)
<hunger> Riddell: Currently I need to free up one computer entirely. Maybe after I am done with that.
<_mvo_> jono: yes
<_mvo_> jono: its part of update-manager
* jsgotangco just remembers to update the update-manager help file
<jono> _mvo_, right, so when a new version of Ubuntu comes out, will update-manager tell me ?
<_mvo_> jono: yes. there is a thing called "meta-release-file" that knows about available versions of ubuntu
<jono> _mvo_, cool. and when a distro changes, what does the user see in the GUI?
<_mvo_> jono: http://people.ubuntu.com/~mvo/dist-upgrader/dist-upgrade.png
<_mvo_> jono: http://people.ubuntu.com/~mvo/dist-upgrader/dist-upgrade1.png (1-4)
<_mvo_> the screenshots are not fully up-to-date
<azeem> _mvo_: I suggest renaming "Post upgrade stuff" to "Magic happens here"
<jsgotangco> lol
<jsgotangco> ubuntu voodoo at work
<jono> _mvo_, thanks for that :)
<jono> _mvo_, I will write about this in the holy book :)
<_mvo_> jono: woah, you write a holy book :) ?
<ogra> didnt you know ? 
<_mvo_> azeem: haha, the name (fortunately) changed since then. but "magic happens here" is very appropriate
<ogra> the ubuntu almanach :)
<jono> :)
<ogra> (-h in english apparently)
<Riddell> seb128, doko: what protocols does openoffice support?  is it just smb:/ ?
<doko> Riddell: ftp works as well for me, but there are some bug reports with user logins from the GUI
<_mvo_> ogra: btw, I had a quick look at the hwdb nexata stuff, it seems to be only backend related (from a very quick look)
<ogra> yep, and minor gui changes for branding
<Riddell> doko: so what happens if you open an openoffice file from an unsupported URL, sftp:/ or something?
<ogra> i also took a glance but didnt dig deeper
<doko> Riddell: try it: oowriter <URL>
<ogra> ARGH !!!!
<ogra> how do you guys handle debian/patches if patch 99 already exists ? 
<fabbione> azeem: you got your files back.. or almost all of them
<ogra> apparently it applies patch 100 i just created *before* all others
<Riddell> doko: hmm, so having %U in the .desktop file does break things
<bddebian> ogra: 99a?
<ogra> hmm
<crimsun> ogra: there's always 999, 9999, ....
<ogra> eeek
<ogra> *shudder*
<crimsun> yeah, very oogly.
<ogra> why cant it just pick up 100 at the right place *sigh*
<bddebian> Start using hex :-)
<bddebian> ogra: Because it char
<ogra> heh
<ogra> yes...
<doko> Riddell: fix it, it works for Gnome, or you have to use another set if .desktop files.
<bddebian> ogra: Or just move all the patches into the source and start over.. ;-P
<ogra> haha
<ogra> i'm sure thats the right way for a manpage patch in coreutils :P
<bddebian> manpage? WTF?  Who uses those?
* bddebian hides
<ogra> i got a bug about it with a two line formatting change ...
<ogra> i thought it would be a good fingertraining to relax a bit between the serious ones ...
<bddebian> :-)
<ogra> tsk ...
<Riddell> Kamion: espresso can't resolve archive.ubuntu.com during install to download yaboot, is that a known problem?  the machine has perfect internet access
<Kamion> Riddell: yeah, will be fixed by telling apt-get not to upgrade packages (it already has a reasonable version of yaboot on the live filesystem)
<Kamion> I think networking probably isn't set up right in the chroot at that point
<Riddell> Kamion: how do I tell apt-get not to do that
<Riddell> ?
<Kamion> Riddell: add --no-upgrade to the apt-get arguments in /usr/lib/espresso/compat/apt-install
<Kamion> I haven't tested that yet, but that was my intention
<elmo> seen on a galeon dialog 'Save as' box... "Save with content"
<elmo> someone deserves a very spethial UI award for that one
<LarstiQ> elmo: what, just structure isn't enough for you? :)
<siretart> *sigh*. another kernel-abi bump :(
<fabbione> siretart: and what is your concern with it?
<ogra> fabbione, rebooting :)
<fabbione> ogra: you still need to reboot without ABI changes
<fabbione> fixes that might affect you are not necessarely in modules
<fabbione> and i have never see ANY of you going to unload everything manually to load a fix
<ogra> yes, i'd have said "*sigh*. another kernel" :)
<fabbione> ogra: prove me wrong
<siretart> fabbione: I have to take care that l-r-m are in sync with the kernel when upgrading
<fabbione> siretart: when l-r-m is synced, there is a new linux-meta
<fabbione> otherwise it will just refuse to install
<siretart> hm? will investigate..
<fabbione> siretart: i am sure
<fabbione> if you have linux-meta installed it will pull in the kernel upgrade at the right time
* ogra will upgrade to the latest kernel ... to get broadcom love 
<fabbione> i am happy -20- is out
<fabbione> finally we will have gdb on sparc working 100%
<fabbione> even on threaded apps
<siretart> cool :)
<siretart> sparc doesn't care for l-r-m anyway, I assume
<fabbione> siretart: yes we do
<fabbione> siretart: i have l-r-m on my i386/amd64 desktop
<siretart> fabbione: which sparc drivers are in l-r-m?
<fabbione> siretart: only some firmwares
<siretart> ah. I see
<kagou> BenC: i think that  with last version of linux-source you have also close my bug #31502 :) i'm waiting update to verify 
<Ubugtu> Malone bug 31502 in linux-source-2.6.15 "Incorrect MAC address on card (00:00:00 in device portion)" [Normal,Confirmed]  http://launchpad.net/bugs/31502
<BenC> kagou: ok
<BenC> kagou: it should
<kagou> indeed
<ogra> Kamion, is there something squeak realted sitting in NEW ?
<ogra> *related
<Kamion> ogra: not any more, squeak binary accepted
<ogra> ah, thanks
<j^> BenC are you still maintaining libraw1394?
<j^> the debian packages
<lamont> mvo: ping
<pitti> hey lamont, how are you?
<mvo> lamont: pong
<mvo> lamont: don't tell me anything about any bugs, I have enough of those already
<lamont> mvo: any clue why hppa installs now appear to hang in aptitude right after it says 'Reading exteneded state information'?
<lamont> it used to be that the install just bombed out at that point (breezy timeframe) - I just figured that was a natural part of the netboot install.... :-(
<lamont> but now it hangs regardless of which dapper image I'm playing with.
<Yagisan> Diziet: ping
<mvo> lamont: does strace show anything interessting?
<lamont> lots of sched_yield() and occasional nanosleep()
<mvo> lamont: hm, aptitude is nowdays fully threaded, maybe a problem with that? that is only exposed on hppa for some reason?
<mvo> *joy*
<lamont> several aptitude invocations worked prior to the hang, but 'Reading extended state information' appears exactly once in syslog
<mvo> lamont: use apt-get :P it's still single threaded
<lamont> mvo: this is the installer.
<Kamion> the installer cannot use apt-get for this
<mvo> lamont: does this bug happens on the normal system as well? or only in the installer?
<lamont> mvo: dunno yet...
<jc-denton> what's the state of beagle in dapper
<mvo> lamont: I see. I would love to help debugging it, but I guess I need to log into a hppa system first
<jc-denton> can i use it with deskbar?
<lamont> mvo: I'll check on it...
<lamont> fabbione: you have that hppa box up yet?
<mvo> lamont: thanks. I suspect it may be a threading issue
<lamont> quite possibly
<fabbione> lamont: yes i do have it.
<dholbach> jc-denton: try installing python-beagle - but this is more of a #ubuntu question
<lamont> fabbione: is that a J box or an rp2470?
<fabbione> lamont: it's scheduled for rewiring tomorrow..
<lamont> (dark or light grey)
<fabbione> j5k
<fabbione> dark
<lamont> oh, right
<fabbione> lamont: i did run out of network cables today
<lamont> heh
<fabbione> i got them, but i didn't have power to plug them
<lamont> iz scary
<fabbione> yeah
<lamont> mvo: of course, just because you say "threading issue" doesn't mean that it's necessarily a kernel bug...
* lamont goes to try and reproduce this on an up-and-running machine
<mvo> lamont: no, that is not what I wanted to say, just the opposite, I suspect it's a bug in aptitudes threading that for some reason is triggered on hppa
<janimo> Kamion, do you have moderator powers on u-announce? I sent a mail after subscribing but is still not gone through
<lamont> ah, ok
<lamont> mvo: what exactly triggers the 'Reading extended state' information?
<mvo> lamont: I would have to look that up, IIRC it happens when the normal cache initialization finished (but I guess that is not very helpful)
<lamont> well, for reproduction, do I care about Keep-FDs, Status-Fd and such?
<mvo> lamont: unlikely, this is stuff to communicate with a fontend
<Kamion> janimo: no, I don't; I do know that there's some debate about whether it should be on -devel-announce instead (because -announce has got an awful lot of posts recently for a low-volume announcement list), but you should get an answer on that shortly
<lamont> mvo: ok.  - not only that, it's annoying to setup. :-)
<janimo> Kamion, ok
<janimo> mvo, thanks for the upload :)
<ogra> hmm, has anybody experience with rpath ? 
<ogra> i'm trying to find patches in an rpath based package ...
<mvo> lamont: with what params is aptitude called? I'm looking at the source right now
<mvo> lamont: called from the installer that is
<Lure> Kamion: around?
<Kamion> Lure: hi
<Lure> hi, just tested your debug image
<Lure> it stops on 63th step (62 presses of Esc are OK)
<lamont> mvo: --without-recommends -y install ~t^ubuntu-standard will reproduce it
<Kamion> further than I expected
<Kamion> let me just dig into exactly where that would be
<lamont> amusingly, under gdb, I got to 65% before it hung...
<Lure> I have also noted the debug output at the time if that would help
<Kamion> might do, shoot
<mvo> lamont: a backtrace in paste.ubuntulinux.nl would be very helpful, thanks  :)
<lamont> pkg_or_matcher -> pkg_matcher -> pkg_trivial_string_matcher -> regexec -> pthread_mutex_lock -> loop
<Lure> Kamion: I need couple of minutes to type down
<lamont> mvo: still on the installer machine -> no cut/paste
<mvo> lamont: ok, thanks. 
* mvo wonders why threading is needed when no gui is used 
<lamont> is that enough to get you started?  lunch folks want to leave...
<mvo> lamont: thats enough for now, thanks
<mvo> lamont: go and have lunch :)
<lamont> mvo: thanks.
<Lure> Kamion: added to bug 34592
<Ubugtu> Malone bug 34592 in gfxboot-theme-ubuntu "flight 5&6: install hang on ATI x700/x800" [Critical,Needs info]  http://launchpad.net/bugs/34592
<Kamion> Lure: thanks; on the phone, but I'll get back to you RSN
<Lure> Kamion: no pb (in process of getting kids to bed ;-))
<bddebian> infinity: ping?
<joelbryan> Hi, is what are the package responsible for the scattered volume icons in desktop?
<sladen> joelbryan: nautilus
<dholbach> joelbryan: scattered?
<joelbryan> yes
<dholbach> i'm not quite sure what you mean
<joelbryan> the mounted volumes are displayed in desktop, but when I start the desktop, it is arrange scatteredly, overlapping the icons.
<dholbach> ah yes, that's nautilus
<dholbach> there are around 20 bugs filed about the icon placement behaviour already :-)
<joelbryan> I have tinkered a small script that fix those, Bug #38056
<Ubugtu> Malone bug 38056 in ubuntu-meta ubuntu-desktop "Fix scattered volume icons in Desktop, and some suggestions to Dapper." [Normal,Unconfirmed]  http://launchpad.net/bugs/38056
<jc-denton> dholbach, thx for answer
<jc-denton> i was asking mostly about the status..
<jc-denton> so this would not be a #ubuntu question i think
<jc-denton> but afaik it wont be included in dapper?
* janimo wonders whether elmo or keybuk is the James of u-a moderation
<dholbach> it is
<jc-denton> ah..
<dholbach> ubuntu-desktop pull deskbar-applet in
<jc-denton> yes i already did that
<jc-denton> but what about beagle?
<joelbryan> hi, about the script, the icons placement will not be changed, and the volume icons will find their way into the desktop, only the real icons will change it's position.
<dholbach> it doesnt depend on it, as it works without it as well
<dholbach> about beagle in general, you might want to ask the mono team
<tseng> the what now?
<elmo> janimo: me
<elmo> janimo: Scott doesn't sign his  mails 'James'
<janimo> elmo, ok replied re xubunt
<tsdgeos> jordi: ping
<jordi> tsdgeos: yep
<ogra> Kinnison, ping
<ogra> hmm, somehow i didnt get a Accepted/Rejected mail for my pwgen upload ...
<Kamion> Lure: ok, this is going to be a bit of a counting test I'm afraid
<Kamion> Lure: could you boot that image, hit escape 62 times, then hit space 8 times, and tell me what's in the slot labelled 1 of the column labelled pstk?
<Kamion> it's "1. 1" here
<Lure> Kamion: OK, will reboot in 5-10 minutes or so and report back...
<Kamion> Lure: oh, it's on the machine you're IRCing from?
<delire> i've just tried out flight6 and have a few experiences/critiques i'd like to share. where should i do this?
<Kamion> that's going to suck
<Lure> Kamion: I will get to my desktop and start IRC there...
<tseng> delire: ideally in launchpad.net/malone as individual bug reports
<Kamion> Lure: ah, good, having to reboot and then press keys a precise but large number of times over and over again would be no fun at all
<delire> also, how much of the existing artwork (theme, icons, logout dialogue) is intended to remain through to the final Dapper release?
<Kamion> Lure: I suspect I'm going to be called away to dinner soon, so apologies if I disappear
<Lure> Kamion: no pb, will continue when back...
<delire> tseng: they're not necessarily 'bugs' so much as look and feel suggestions, flight6 has a few problems IMO.
<tseng> a UI bug is still a bug
<delire> right, ok.
<tseng> there is already a bug open on the logout dialog for example
<delire> tseng: so what i see is intended for the Dapper official release?
<delire> tseng: yeah that is pretty awful. i'll read up on that.
<tseng> beats me, #ubuntu-artwork
<delire> cheers
<Kamion> Lure: your parameter stack (pstk) report is a little different from mine, so I'm wondering if this is a consequence of slightly different memory layout due to different numbers of VESA modes returned by the graphics card, or something horrible like that
* mvo goes for dinner
<ogra> mumble mumble ...
<Lure> Kamion: interesting - you will get new one soon - I might have copied something from screen (was to lazy to grab my camera to take a picture :-(()
<ogra> where is my pwgen upload, grr
<Kamion> Lure: it's different enough that it's unlikely to be a transcription error on your part
<Kamion> and it doesn't massively surprise me that it differs
<Kamion> Lure: the return stack (rstk) on the right-hand side is indeed mostly uninteresting
* Lure is going down on notebook
<janimo> elmo, should I repost the xubuntu ann to devel announce? if so is it moderated as well or do I subscribe for posting. thanks
<elmo> janimo: you can post it to -d-a, if you like.  it's also moderated, so it doesn't matter whether you subscribe or not first
<Kamion> if Lure comes back, somebody please tell him I'm away for dinner and will be back in an hour or two; sorry for unfortunate timing
<ogra> <Kamion> if Lure comes back, somebody please tell him I'm away for dinner and will be back in an hour or two; sorry for unfortunate timing
<Lure> ogra: thanks
<Lure> ogra: can you also copy his instructions about number of space presses (if I recall 8 times)
<Lure> ogra: I am on another computer and have no irc logs...
<Mithrandir> Lure: 20:13 < Kamion> Lure: could you boot that image, hit escape 62 times, then hit space 8 times, and tell me what's in the slot labelled 1 of the column labelled pstk?
<Lure> thanks
<Mithrandir> Lure: 20:13 < Kamion> it's "1. 1" here
<ogra> ah, Mithrandir beats me :)
<delire> tseng: if i wanted to file a bug about the boot process, the way the dapper live CD jumps from splash to vga text in the console, which package would i file it under?
<Kamion> Lure: (back briefly)
<tseng> delire: usplash
<delire> cheers
<tseng> delire: usplash
<tseng> oh, i was right the first time
<Mithrandir> delire: you wouldn't.
<Mithrandir> delire: it's already filed.
<jc-denton> how is beagle search called in gconf-editor?
<Lure> Kamion: ok, was distracted in counting 2 times already ;) (wife, kids...)
<Riddell> Kamion: what is self.progress_position in gtkui?
<tseng> jc-denton: i'm not sure its called anything
<Kamion> Riddell: an object that keeps track of nested progress bar regions; see espresso/progressposition.py for docs
<Riddell> ok, sounds fun
<Lure> Kamion: it is 1.1
<Lure> right hand side also changed this time
<Kamion> Lure: ok, hit space another 7 times, what's in pstk 1?
<Lure> 0.1
<delire> Mithrandir: yep, just saw that when searching for Usplash.. cheers
<Kamion> Lure: space another 13 times, pstk 1?
<Mithrandir> delire: it's actually a bug in casper, not usplash, though.
<delire> right..
<Lure> 0.1
<sladen> that line of kamion's should go in the quotes file
<Lure> sladen: ;)
<Kamion> Lure: hit space another 11 times and pstk 1 should be 0.1 again?
<Kamion> sladen: which line?
<Lure> 0.1
<delire> i have another question on bug validity, while waiting for my DHCP lease on a wireless network a prompt pops up with: "Choose password for default keyring", something i've never had to deal with previously, albeit i usually configure such things using iwconfig on the commandline. what is the point of this prompt? i don't remember it being present in Breezy previously.
<sladen> Kamion: hit space 62 times...
<Kamion> Lure: ok, now if you hit space another 6 times, is pstk empty?
<delire> interestingly i just gave a random password and was given a lease as a result.
<sladen> delire: is it for the WEP key?
<delire> sladen: no, i entered that earlier..
<Kamion> sladen: not my fault gfxboot is obscure :-/
<delire> sladen: .. in the wireless connection dialog itself
<tseng> delire: you add your wep key to the gnome-keyring
<Lure> Kamion: no, I would say it hanged on last press 
<tseng> delire: you then create a master passord to unlock the keyring later
<Lure> there is 0 709....
<Kamion> Lure: interesting, that means it's hanging trying to free memory
<delire> tseng: right.. then that should be explained. people coming from windows, OSX or other KDE distributions would find that confusing.
<Kamion> where's 0 709?
<Lure> shit it went away *powered down(
<tseng> delire: on each login, you present that password to unlock the keyring and pull out your wep key
<Kamion> Lure: heh, no worries
<Kamion> Lure: that's pinpointed it very precisely
<delire> right ok.. that will need a balloon or 'first time user' text.
<Lure> Kamion: it was in pstk 1:
<Lure>  (or 0: - it was only one line there)
<Lure> line was 0: 0709 something
<delire> i discovered it when a friend wrote to me asking me what it was - a KDE user. trying it out myself i also found it confusing as it goes unexplained.
<Kamion> "0:    70e3e. 4" here
<ivoks> um... i'm interested in helping with UCE
<ivoks> since i have some exp. with RHCE
<ogra> UCE ??
<ivoks> (and wouldn't like to see UCE so easy as RHCE :)
<Kamion> Lure: probably 709a0. 4, since that was in the trace you mailed earlier
<ivoks> pardon, UCP
<Kamion> that's what I'd expect
* Mithrandir wonders why he's wasted a dvd-r on a live cd
<ivoks> Ubuntu Certified Professional
<Lure> yep, I am sure it was a next
<ogra> ah
<delire> tseng: out of interest, why is the loopback device in the devices menu in the top-bar? is there a valid reason for it to be there?
<delire> s/devices/netork devices
<delire> bah you get the idea ;)
<Lure> but it was only one line (no 1: as during "space pressing times")
<ogra> ivoks, i'd suggest to answer silbs mail then :)
<tseng> delire: i am unfortunately not able to answer every question that pops into your head
<Kamion> Lure: right
<Kamion> Lure: thanks, I think I'm done with you for tonight :-/
<Kamion> :-)
<delire> tseng: bizarre, i thought you were The Architect! ;)
<ivoks> ogra: :)
<delire> tseng: cheers, i'll ask around.
<Kamion> Lure: I'll look at this again tomorrow; worst case I'll just leak a bit of memory
<tseng> delire: great, have a nice day.
<Kamion> which I expect will make the problem go away
<Lure> Kamion: ok, just ping me if you need remote testing still
<Kamion> it's a bit concerning though, seems like the malloc arena's a bit trashed
<Kamion> but I'm buggered if I'm sitting trying to decipher all this assembly code
<Lure> so spaces were really steps over individual instructions? I can imagine
<Lure> :-(
<Kamion> Lure: actually that wasn't in assembly, that was in a forth-like language
<Kamion> Lure: but yes, I had you single-stepping
<Kamion> the assembly in question is the implementation of the gfxboot language
<Kamion> the infinite loop is, I think, in its 'free' operator
<Lure> Kamion: any idea why it turned off this time - side effect of debugging?
<Kamion> Lure: could be, not sure about that
<Kamion> Lure: it might have just crashed
<Kamion> I think all bets are probably off
<Lure> right
<Lure> ok, now run for dinner ;-)
* lamont delunches, looks for mvo
<Kamion> oh, I wonder ...
<Kamion> I think I'm double-freeing
<Kamion> or not. maybe. hmm. later :)
<mdz> Kamion,pitti: I see syncs on dapper-changes, everything running smoothly there?
<Kamion> mdz: not me, last I heard pitti had a hacked-up home-grown sync tool
<Kamion> lp_queue user's history has not a lot interesting in terms of syncs
<elmo> it runs as lp_archive
<elmo> for starters :P
<mjg59> Kamion: So the Macs will boot off a hybrid filesystem
<Kamion> ah, heh
<mjg59> Though right now the only way of generating one seems to be under MacOS
<Kamion> elmo: I think I could be forgiven for being confused by ~lp_queue/HOWTO-SYNC
<sladen> Kamion: do you have new-style blessing stuff ported somewhere?
<Kamion> sladen: no, Keybuk's working on it I think, and there's no point until there's some free way to make a filesystem
<elmo> Kamion: well for added fun and confusion, the sync tool runs as lp_archive, the actual processing of syncs is done by lp_queue
<elmo> whole directory under /home is crack that happened towards the end of the sprint anyway
<Kamion> elmo: ~lp_queue/HOWTO-SYNC says to write stuff to a directory that's only writable by lp_queue
<lamont> mvo: current dapper gets as far as 'Building tag database... Done'
<elmo> Kamion: yes, but the sync tool needs to talk to the db, and it can't do that as lp_queue
<Kamion> ah, I see ~lp_archive/syncs/ though
<Kamion> elmo: ah
<elmo> so you run josie-port as lp_archive
<Kamion> I filed a bug about that ...
<elmo> then copy by hand to the crackful /home/lpqueue stuff and it gets processed there
<elmo> lp_queue probably shouldn't be able to talk to the db
<elmo> even in RO mode
<elmo> and besides, lp_archive is in %lp_queue, so it can write to the lp_queue dir
<mdz> pitti's look like they might be a different tool (eg., Origin: debian/unstable)
<elmo> yay for reinventing the wheel
<mdz> though infinity's mysql-dfsg-5.0 looks like josie (Origin; Debian/unstable)
<Kamion> elmo: er, it can?
<Kamion> $ ls -ld ~lp_queue/sync-queue/
<Kamion> drwxr-xr-x  6 lp_queue lp_queue 4096 Feb 22 20:55 /home/lp_queue/sync-queue/
<Kamion> or you mean it can sudo?
<elmo> Kamion: well if that dir was g+ws, it could
<mdz> fabbione: is it helpful to reassign server bugs from xorg to xorg-server, or not really?
<Kamion> https://launchpad.net/products/soyuz/+bug/35723 was the sync-source database access bug I think
<Ubugtu> Malone bug 35723 in soyuz "sync-source should not connect as the 'ro' user" [Normal,Confirmed]  
<mdz> I think most of the bugs on the xorg source package are server bugs currently
<elmo> ?!
<Kamion> elmo: stub thinks it should have a special user created
<elmo> oh, but still a ro only user
<Kamion> right
* elmo de-heart-attacks
<elmo> god that inline control stuff is fugly
* bddebian breaks out the refribulator
<Kamion> elmo: ok, so if we follow the ~lp_queue/HOWTO-SYNC directions but substitute copying files around in the "obvious" way, it should work?
<ogra> mdz, fabbione explained it like that: "all configuration bugs should go to the xorg package, all others schould be assigned to the respective server"
* Kamion -> dinner, REALLY this time
<elmo> Kamion: it'll work for syncs without UTF-8 Maintainer: fields, AFAIK
<bddebian> bon jour
<elmo> Kamion: you'll need to setup $http_proxy too, when running it as lp_archive
<elmo> Kamion: I'm working on the UTF-8 thing ATM (see, e.g. listadmin, as a current broken example)
<mvo> lamont: I'm having dinner right now, but does current dapper has the same backtrace?
<mdz> ogra: respective?
<mdz> ogra: surely configuration bugs should be xorg-server, and driver-specific bugs to the driver packages
<lamont> mvo: differnt
<ogra> mdz, exactly
<mvo> lamont: what does it look like?
<lamont> just a minute
<mvo> lamont: you don't have network on the hppa machine to mail it or something?
<lamont> this one, yes.
<danimo> hi
<lamont> mvo@u.c?
<mvo> lamont: should work, yes
<danimo> is there a reason NetworkManager-openvpn is not included in dapper?
<Pygi> danimo: hm, why can't you just install it? =P
<lamont> very similar backtrace actually
<lamont> sent
<mvo> lamont: thanks!
<Pygi> when you didn't had vpn support you argued about that (not you really, but a lot of people), and now when you have it you want more :)
<lamont> this time, pkg_task_matcher::matches() -> regexec() --> death
<danimo> Pygi: I'd like to, I must be missing the package
<mvo> lamont: have it, thanks
<lamont> mvo: I just wonder who's not freeing the mutex...
<mvo> lamont: and why hppa triggers it
<delire> anyone know of plans to implement the Ubuntu equivalent of 'internet connection sharing' in dapper? eg an easy interface to iptables w/forwarding etc. something people in non-dsl territory would say is fairly vital..
<lamont> well, more interested in how to make hppa not trigger it...
<_ion> Cool, n-m 0.6.2 is already in dapper.
<Seveas> delire, sudo apt-get install firestarter - please go to #ubuntu for end-user support
<Pygi> _ion: yes, it is...ages ago ^_^
<_ion> Yeah, i dist-upgrade every once in a while. :-)
<danimo> Pygi: not sure what you are trying to tell me
<ogra> mdz, elmo, any idea how we should handle fonts where the license in the ttf file differs from the license in the copyright file ? if i want to edit TSCu_Comic.ttf from the ttf-indic-fonts package with pfaedit, it tells me the included license in the ttf doesnt permit changes without agreement of the original author, but the package is GPL
<Pygi> danimo: hm ... well, just openvpn, and start nm-vpn-properties? :)
<_ion> Just happened to notice it.
* Pygi pokes _ion =P
<elmo> ogra: err, which copyright file?
<delire> Seveas: this isn't end user support.. just a query as it's a project i was considering undertaking at one point.
* _ion peeks Pygi
<ogra> elmo, debian/copyright 
<ogra> elmo, in ttf-indic-fonts
<danimo> Pygi: we're talking dapper from universe?
<danimo> dapper packages even
<_ion> http://irc-galleria.net/view.php?nick=Ion
<mvo> lamont: I'll have a look. is there a hppa machine where this can be debugged?
<elmo> ogra: debian/copyright isn't canonical?  whatever is in the upstream source is
<lamont> mvo: email me an ssh key
<Seveas> _ion, freaky 
<Pygi> danimo: yesh ^_^
<ogra> elmo, hmm, so the ttf file overrides ?
<elmo> ogra: yeah
<ogra> odd
<ogra> ok
* danimo updates again to make sure he didn't miss anything
<sivang> re all
<_ion> seveas: Well, that was gimped. This is my real face. http://johan.kiviniemi.name/pictures/misc/ion-faceless
<danimo> Pygi: can't find a package that contains nm-vpn-properties
<janimo> delire, there were firewall/conn sharing specs but got deferred for lack of developer resources
<janimo> one is in the works for dapper+1
<Pygi> danimo: hm, there just isn't link for it, but it's there
<Pygi> there are two forum topics about that...please post there? ^_^
<elmo> Message for booting on non-x86_64 machine (32-bit) (X86_64_NOLONG_MSG) [Your CPU does not support long mode. Use a 32bit distribution.]  (NEW)
<delire> janimo: right.. is there an URL, i may be able to help..
* elmo boggles
<elmo> give that developer a UI award too
<janimo> delire, I don;t have it rigth now but you can search for it on launchpad
<janimo> but maybe google finds it faster 
<delire> janimo: will do. thanks alot.. firestarter is pretty lacking in this regard.
<danimo> Pygi: dpkg -L doesn't think so :)
<mdz> ogra: there's no explicit license from upstream apart from whatever flag is set in the ttf?
<Lure> danimo: n-m-vpn packages are still not in repo (not sure if anybody is working on them)
<ogra> Copyright:
<ogra> The followings Tamil OpenType fonts have been released under the GNU
<ogra> General Public License. The fonts are copyright of the respective authors.
<ogra> 1. TSCu_Times, TSCu_Comic
<ogra>    Thukkaram Gopalrao, USA
<ogra>    http://www.thinnai.com/
<janimo> delire, https://launchpad.net/distros/ubuntu/+spec/firewall
<Lure> but there is one repo (check forums) wher you can get it
<danimo> Lure: ok, that was what I suspected
<Pygi> danimo: bah, just ask the people on the forum...people are running vpn's, but you need to make sure you do certain stuff =P
<_ion> OpenVPN support would be nice, as i use it. :-)
<janimo> looks like it should b ready by May 1st
<ogra> mdz, but opening it in a glyph editor explicitly states that its not allowed to change the font without premissin
<danimo> Pygi: I just want to make sure it ends up in dapper and works with KDE
<Lure> danimo: I just know it works (with knm) for some time, as Tonio have sent me screenshot a week ago
<Pygi> danimo: perhaps it will ^_^
<Lure> already with 0.6.1
<mdz> ogra: an explicit license from upstream qualifies as "permission"
<danimo> Lure: ah, cool
<Lure> danimo: I can forward you that mail - just sand me your e-mail address
<ogra> mdz, so i should assume GPL ?
<delire> janimo: brilliant.. this looks good. thanks ;)
<mdz> ogra: if that's what it says in the upstream tarball, yes
<mdz> ogra: (not debian/copyright)
* Pygi - over and out
<ogra> ohoel, right ... 
<ogra> mdz, hrm, the orig.tar.gz is native :/
<ogra> so i have to respect the builtin license in the ttf i guess ...
<mdz> ogra: which bug# is this about?
<ogra> bug 35349
<Ubugtu> Malone bug 35349 in ttf-indic-fonts "edubuntu  incorrect in desktop" [Normal,Confirmed]  http://launchpad.net/bugs/35349
<Riddell> danimo: what's up?
<mdz> ogra: I'd forward it to Debian with a note that the license needs to be clarified, and move on to another bug
<danimo> Riddell: I'm just making some trouble
<pitti> Riddell: do you think there is anyone in the KDE community who would like to work on porting kdeprinter to cups 1.2? Maybe we can bounty it?
<danimo> Riddell: as usual :)
<danimo> Riddell: seriously, though, I'll ask tonio to package the vpn plugin for n-m
<danimo> Riddell: since that's really most useful
<ogra> mdz, ok, but i consider it major as long as we ship that font as default ... 
* ogra still whishes for Kinnison ...
<ogra> my pwgen upload still doesnt show up 
<mdz> ogra: I don't understand why you are using a different font for edubuntu than ubuntu uses
<mdz> perhaps that should be revisited
<ogra> mdz, we use a completely different look 
<_ion> ** (nm-applet:24038): WARNING **: <WARNING>      nma_dbus_init (): nma_dbus_init() could not acquire its service.  dbus_bus_acquire_service() says: 'Connection ":1.26" is not allowed to own the service "org.freedesktop.NetworkManagerInfo" due to security policies in the configuration file'
<ogra> why should we use the same font ? 
<_ion> I wonder what's the correct way to fix this.
<mdz> ogra: fonts are less about the look and more about functionality and language support
<pitti> _ion: did you start n-m from a remote shell, or so?
<mdz> ogra: we have to choose them very carefully in order to work well for most users
<_ion> pitti: Nope.
<pitti> _ion: do you have /var/run/console/<yourlogin>.7?
<pitti> _ion: (or whatever your foreground console is)
<Mez> hmm
<Mez> gnome-btdownload is a pretty borked package atm
<ogra> mdz, yes, i know ... its trivial to fix and add the handfull of missing glyphs though ... that what bothers me ...
<_ion> pitti: Hm, /var/run/console doesn't exist.
<pitti> _ion: do you have libpam-foreground?
<Mez> /var/lib/dpkg/info/gnome-btdownload.prerm: line 5: gconf-schemas: command not found
<Riddell> pitti: Cristian Tibirna is the maintainer
<_ion> pitti: Yes.
<mdz> ogra: except where missing glyphs are being provided by a different font, then you change that behaviour, etc....it's rarely simple
<pitti> _ion: /etc/pam.d/common-session has pam_foreground?
<_ion> pitti: Anything in /etc/pam.d doesn't contain the string foreground.
<mdz> and it takes a long time for enough users to test it to get feedback for many languages
<pitti> _ion: did you manually modify anything there?
<crimsun> Mez: missing dep on gconf2?
<Mez> crimsun, gconf2 is installed
<janimo> mvo, u-m still deps on python-gnome2
<Mez> but gconf2-common isnt
<mdz> Mez: gconf2 depends on gconf2-common
<Mez> crimsun: and it';s breaking an upgrade to dapper
<mvo> janimo: right, forgot to fix that
<_ion> pitti: I have modified it to authenticate from LDAP, but i thought that was the only modification i had made. And i have looked at diffs when new package versions of the config file have appeared. But maybe i have missed something.
<ogra> mdz, hmm... k i'll put it into the edubuntu meeting tomorrow to get some feedback if we shuld change it ... but i suspect the users wont be happy to have something sans serif on their desktop :)
<Mez> mdz: weird 
<Mez> http://rafb.net/paste/results/PlDAkv87.html
<pitti> _ion: hm, this might justify a bug against libpam-foreground
<mvo> janimo: what about this deal ... once your fake-gconf is actually working I drop the depends and make it a recommend ;) ?
<seb128> Mez: you are trying to install a package built with new gconf on a box with an outdated one?
<janimo> mvo, ah ok. I just made u-m a dep of xubuntu-desktop
<janimo> need to hurry
<Mez> seb128, I'm trying to upgrade from breezy to dapper
<seb128> Mez: that's a gnome-btdownload bug so
<Mez> seb128, obviously
<seb128> Mez: I'm fixing it now
<seb128> it doesn't use ${misc:Depends} for its control
<Mez> seb128, ah cool :D well... er :D
<Mez> I'm overriding the prerm file ;)
<seb128> Mez: you wanted to fix it?
<seb128> Mez: upgrade gconf first if you want to get it fixed cleanly
<Mez> seb128, no - I just wanted to upgrade to dapper :D
<seb128> other way gnome-btdownload will not be registred correct
<Mez> seb128, I dont mind unclean fixes as long as they're fixes
<Mez> seb128, I've removed it
<mdke> elmo, Znarl, it.archive.ubuntu.com isn't working. shall I file an RT for that sort of thing?
<Riddell> pitti: shall I send him an e-mail?
<Znarl> mdke : No, it's ok.  I'll point it.archive at ourselves and contact the admin. 
<mdke> Znarl, thanks very much
<Znarl> Thanks for letting me know.
<pitti> Riddell: let's talk with mdz
<pitti> mdz: would there be room for a bounty to port kdeprint to cups 1.2?
<pitti> mdz: right now we had to revert to cups 1.1
<mdz> pitti: yes
<mdz> pitti: assuming an acceptable stabilization risk
<mdz> in the balance between cups and kdeprint
<pitti> mdz: in the same line, would you even consider upgrading cups to 1.2rc1? I didn't upgrade our snapshot since UVF so far
<elmo> oh, right, I forgot to ask
<elmo> can we upgrade dovecot?
<pitti> elmo: already done a couple of hours ago
<elmo> otherwise our supported pop3/imap server is going to be an alpha version
<elmo> pitti: ok
<elmo> now it's only a beta ;-)
<mdke_> which is the supported pop/imap server?
<pitti> elmo: I did some basic imap[s] /pop3[s]  fetchmail/mutt/evo testing today which went well
<mdke_> out of interest
<ogra> dholbach, i need to add dh_iconcache to the app ? not to the package installing the icon ?
<elmo> mdke: see the 'can we upgrade' line
<mdke_> elmo, I disconnected during that line
<elmo> mdke_: dovecot
<mdke_> ah good, thanks
<pitti> mdz: cups 1.2rc1 has tons of bug fixed, but also a fair number of new features and changes, so it would require some serious testing
<dholbach> ogra: to the debian/rules of the source package of the app installing the file to /usr/share/icons/{hicolor,gnome}
<dholbach> ogra: is that precise? :-p
<ogra> dholbach, thinking about theme packages like edubuntu-artwork (which adds a distributor logo)
<bddebian> Bah, there's no better test than production.. :)
<ogra> dholbach, and it applies only to /{hicolor,gnome} ? no other icon themes ? 
<dholbach> ogra: if it installs stuff to hicolor (as ubuntu-artwork does), then yes
<ogra> i dont ... we use gartoon and tango brown
<dholbach> ogra: that's the ones we'd like to use the icon cache for (we run it for Tango already)
<pitti> bddebian: well, but dapper was specifically meant *not* to be like bananas :)
<mdz> pitti: would be worth considering
<dholbach> ogra: and those are safe, since no package installs stuff to /usr/share/icons/Tango
<ogra> dholbach, nope it doesnt :) 
<bddebian> pitti: :_)
<dholbach> ogra: if you want to it for gartoon, that's fine too
<ogra> dholbach, /usr/share/icons/TangoBrown is its own theme
<dholbach> ogra: just add   dh_iconcache  to the debian/rules
<ogra> i didnt want to clash with tango upstream 
<ogra> ok
<_ion> pitti: Ok, i added the proper line for libpam-foreground, now it works.
<pitti> Riddell: ok, could you please mail him then? if we can get the port in the timeframe of 2 weeks, we can upgrade/test cups in parallel
<ogra> dholbach, thanks
<dholbach> ogra: anytime
<Riddell> pitti: ok
<pitti> Riddell: thanks
<seb128> mdz: xchat-gnome upstream asked if we would consider an UVF exception if they roll a new tarball. They have some bug fixes to SVN and a configuration dialog for the spell checker ... do you think it would be ok?
<pitti> mdz: ok, I'll wait for KDE's answer then and will prepare a test pacakge and a detailled report
<ogra> who apart from Kinnison can look into the upload queue ? elmo ?
<elmo> err, me, kamion, pitti, mdz, infinity
<elmo> cprov
<pitti> oh, can I?
<pitti> I don't have a drescher account
<nowlin> hey are network.manager broken in dapper or is it just me. i got this wen trying to run it :   The NetworkManager applet could not find some required resources.  It cannot continue.
<elmo> you don't?
<elmo> neat
<elmo> ok, -pitti
<elmo> the rest are definitely true tho
<pitti> yes
<ogra> ogra@edubuntu:/mnt/devel/packages$ ls -l pwgen*.upload
<ogra> -rw-r--r-- 1 ogra ogra 228 2006-04-04 19:43 pwgen_2.04-1ubuntu1_source.upload
<ogra> elmo, could you look if thats there anywhere ? 
<mdz> seb128: if it's only bug fixes, yes
<ogra> i have no accepted/Rejected mail and it doesnt show up on changes
<ogra> (it was a one word change in a manpage)
<bddebian> Rejects don't come back some times.  I've had that happen a couple of times recently
<janimo> elmo, if you moderate the u-d-a list as well, please kick my mail to go through. thanks
<elmo> ./failed/upload-20060404-184347-002508/pwgen_2.04-1ubuntu1.dsc
<ogra> oh
<bddebian>  unstable?
<elmo> Distribution: unstable
<ogra> ogra@edubuntu:/mnt/devel/packages$ grep dsc pwgen_2.04-1ubuntu1_source.upload
<ogra> Successfully uploaded ../pwgen_2.04-1ubuntu1.dsc to upload.ubuntu.com.
<bddebian> heh
<ogra> argh
<bddebian> I did that too :-)
<ogra> silly beginners error 
<ogra> #/me blushes
* bddebian hugs ogra
<ogra> elmo, thanks and sorry for stealing your time
<dholbach> Kinnison: seb128 just told me: gparted 0.2.4 *whine*
<elmo> janimo: done
<janimo> thanks
<bddebian> Ack, how am I supposed to get the /usr/include/IV-2_6/InterViews path in?  Is there some automake magic or do I have to force -I?
<bddebian> Oh, it's ivmkmf ugh
<Riddell> janimo: congratulations
* Burgwork smacks Seveas for the awful sounder post :D
<janimo> Riddell: thanks :)
* dholbach hugs janimo
* Seveas hugs Burgwork 
* janimo hugs dholbach
* bddebian hugs dholbach, janimo, Seveas, et al
* ogra wonders what speedcrunch is ...
<Treenaks> Seveas: doh @ post
* ogra installs it
<Riddell> ogra: a calcuator
* bddebian hugs sabdfl
<ogra> Riddell, ah, mdz assigned two bugs for it to me ... didnt ever hear about it before :)
<Riddell> ogra: oh, well you can send them back to me if you want
* sabdfl hugs bddebian
<ogra> let me look first ... one is a trivial one ..
* sivang hugs sabdfl 
<sabdfl>  /invite bddebian #darkroom oops ;-)
<bddebian> hehe
<sivang> sabdfl: darkroom? :-)
<pitti> janimo: just saw your flight-6 annoucement; congratulations!
<ogra> huggers
<janimo> pitti, thanks :)
<ogra> wow, you lucky man ... 400MB isos 
<ogra> thats what i'm dreaming of
<sivang> heh
<sivang> that's all about lightweight desktops :)
<janimo> pitti, re the libpam_foreground thing. I found that if a shell has the privileges, starting xinit from it does not inherit
<janimo> ogra, yeah I can borrow you 100Megs
<ogra> heh
<ogra> Riddell, are tooltips handled by QT or ba the app in QT apps ? 
<ogra> s/ba/by/
<ogra> (bug 26361)
<Ubugtu> Malone bug 26361 in speedcrunch "speedcrunch does not terminate if tooltip is visible" [Normal,Unconfirmed]  http://launchpad.net/bugs/26361
<janimo> pitti, so that's why I cannot shutdown via hal if startx-ed instead of gnome. Still have to figure out why
<pitti> janimo: hm, apparently it does not cause the PAM magic to happen; maybe mjg59 has a hint for you
<Riddell> ogra: by qt generally
<ogra> Riddell, so reassigning it to QT would be right ?
<janimo> pitti, I have started reading up on pam so it's going to be instructive I guess
<Riddell> ogra: well it's probably speedcrunch using tooltips in the wrong way, I'd keep it at speedcrunch
<ogra> ok
<LaserJock> is there a canonical location to put browser plugins?
<bddebian> Should X11R6 be removed in everything in debian/ ?
<bddebian> Should /usr/X11R6/bin be replaced with /usr/X11/bin or just /usr/bin?
* bddebian appears to be talking to himself again
<LaserJock> so many questions, so few answers
<zul> if a tree falls in the forest....nahhhh..
<bddebian> if God can make a rock so heavy that he can't lift it...
<LaserJock> if bddebian can fix Universe ...
<bddebian> Bah, apparently I can't fix anything :-(
<gdiebel> I have done some looking into zope on dapper and it doesn't look pleasant. Could someone elaborate on the status of zope3 packages in dapper?
<Burgwork> gdiebel, I believe you need to talk to ajmitch 
<LaserJock> gdiebel: I haven't a clue but ajmitch might know. He does a far amount of zope/plone stuff
<LaserJock> doh, Burgwork beat me to it
<bddebian> Ack there is no /usr/X11R6/lib/X11/config or /usr/lib/X11/config ...
<bddebian> Who's the X slut these days, infinity?
<mdke> there is an X swat team in LP, members of that are the sluts, I guess
<bddebian> Well I don't want to file a bug for something I should be able to fix myself
<KaiL> has somebody tested dapper flight6 on a typical Core Duo Laptop? found quite a lot big problems
<mdke> bddebian, well fabbione, infinity, and two non-devs are in that group, so you could try pinging them
<KaiL> infinity, btw. you wanted to send ATi X1000+ to vesa driver ;)
<LaserJock> KaiL: on an macbook pro?
<KaiL> LaserJock, does that have this chip too?
<KaiL> uhm, yes
<KaiL> X1600
<LaserJock> KaiL: umm, I thought it was the only laptop with a Core Duo
<KaiL> uhm, no?
<KaiL> today had my fun with an FSC Amilo
<LaserJock> oh, I stand corrected then :-)
<LaserJock> I've got an intel iMac that I'd like to get Dapper on
<LaserJock> mjg59: is Flight 6 ready to test in an intel mac?
<KaiL> at least the "ati" driver fails on X1400, X1600 and friends
<LaserJock> :(
<KaiL> so you need to select "vesa" on normal i386
<LaserJock> oh, well that would be acceptable for now
<KaiL> don#t know, if that is possible on intel-macs too (afaik they are something special there)
* bddebian does the summon infinity dance
<KaiL> second problem, which does not hit the apple, but the Centrinos is the WLAN chip
<KaiL> there seams to be no driver in flight 6
<KaiL> and you need to exchance the kernel to have both cores
<KaiL> and I forgot to test dynamical CPU clock - damn
<Kamion> LaserJock: no, Intel Macs won't work at all yet, sorry
<LaserJock> Kamion: shoot, it's ok. I'm getting used to development over ssh ;-)
<bddebian> Wow, python2.3-* is pretty much gone?
<KaiL> oh, btw, is that only me, who has the wrong icon Theme on the flight6 live CD?
#ubuntu-devel 2007-04-02
<Enola_Gay> cu all
<Draconicus> Your distro is making me think about taking up drinking. ._.
<shawarma> Draconicus: Because it's so easy to use that being drunk won't matter?
<Draconicus> shawarma: Naw... Because if, god forbid, something unusual happens and something goes wrong, you'll never, ever be able to figure out the cause of it all. ._.
<Draconicus> Though chances are at this point that my problem is tragically hardware related.
<Draconicus> And I don't mean generic problems or distro bugs..
<shawarma> Draconicus: You think Ubuntu is harder to debug than other distros?
<Draconicus> No... Actually it's about the same.
<Draconicus> Linux is Linux is Linux.
<Draconicus> I just felt like poking fun at the subject matter. Nothing personal.
<Draconicus> It's not like I'm interrupting some vital conversation or something. This channel has cobwebs. :P
<Draconicus> Though on the off chance that I AM disrupting such a conversation... sorry. 
<shawarma> Draconicus: it's the weekend.
<Draconicus> You're a weekend! D:<
<Draconicus> Anyway, I'll go away now. Toodles.
<shawarma> cheers
<Draconicus> Happy developing. You really do have a wonderful distro, despite my silly comments. :)
<smithj> the ubuntu-patches mailing list seems to have not gotten any patches since march 7. given that i don't think ubuntu has ceased development, what's up with that?
<smithj> see https://lists.ubuntu.com/archives/ubuntu-patches/2007-March/date.html as a reference
<cjwatson_> smithj: I believe that's because the machine running that has run out of disk space; there's a sysadmin ticket open for it
<smithj> cjwatson_: is that ticket open to the non-ubuntu-masses to follow?
<cjwatson> afraid not, but it's not exactly interesting
<smithj> ok
<cjwatson> "dear sysadmins, casey ran out of disk space, love Scott" ;-)
<smithj> thanks for the info
<smithj> well, its been out for almost a month now :-/
<cjwatson> yeah, but the sysadmins are largely busy relocating Canonical HQ to a new office
<smithj> ah
<_ion> One would think the "ran out of disk space" problem would be easy to prevent in advance. ;-)
<cjwatson> _ion: ?
<smithj> nagios ftw
<cjwatson> (a) that doesn't prevent you running out of disk space, merely ensures you know about it (b) the Canonical sysadmins already use nagios
<_ion> cjwatson: For example, use one of the tools available to draw a graph of the free disk space on each server and tell one of the employees to take a look at them every once in a while.
<cjwatson> _ion: I suppose you might also quit patronising the admins ...
<cjwatson> (hello, obviously this is done, that doesn't mean there's always time to deal with it when lots of other stuff is going on.)
<cjwatson> and I know it's done because when machines where I'm responsible for services are running low on disk space, one of the admins asks me to have a look at it well before it's critical
<cjwatson> however, the problem was being escalated as of when I last heard about it on Thursday, so
<smithj> not to be overly pestersome (if thats a word), but isn't patch mail a critical system? without overview of changes, anyone with commit access could knowingly commit a security flaw... even if you trust them not to do that, commit mail is essential to code review...
<cjwatson> that would be true if we used that service for code review ;-)
<smithj> even if canonical doesn't use it for code review, the community might want to
<cjwatson> I hope it will come back before feisty releases
<smithj> ok. i anxiously await :)
<shawarma> cjwatson: Still around?
<cjwatson> shawarma: just ...
<shawarma> cjwatson: Since at least a few weeks ago I've been unable to install feisty in qemu. It boots fine, but after that it's unable to detect either the emulated hard drive or the cdrom. Tollef thought my might be able to tell at a glance what was wrong.
<cjwatson> I can have a quick look at syslog if you have it handy
<cjwatson> or if you give me a recipe that somebody with no brain at 1:20am can follow
<shawarma> cjwatson: Simple: Download a recent feisty image (anything since at least the beta will do), do a "qemu-img create hda.img 5G; qemu -cdrom ubuntu-feisty-server.iso -hda hda.img -m 128", wait for little while, and do your magic thing.
<cjwatson> several ata exceptions on boot there
<shawarma> cjwatson: Yes. Those went away witht the updates the day before yesterday, but the problem remains.
<shawarma> cjwatson: I should have mentioned that.
<shawarma> cjwatson: Specifically, the exceptions went away with the d-i update which made it into dailies 20070330.1 and onwards.
<cjwatson> detects the hard disk fine here but not the CD
<cjwatson> nothing in /sys/block other than ramdisks etc. and sda
<shawarma> cjwatson: Do you actually have access to the hda block device or does the boot log just mention its existence?
<shawarma> cjwatson: sda? That's odd.
<cjwatson> it's sda, and udev certainly knows about it
<cjwatson> this is a slightly old alternate CD
<shawarma> cjwatson: That might be interesting. How old?
<cjwatson> not really surprising though? presumably it's just libata doing its thing
<cjwatson> not that old, 2.6.20-12 kernel of some vintage
<shawarma> cjwatson: Oh, /dev/hd[a-z]  is history?
<cjwatson> not entirely but many such devices have moved
<cjwatson> depends on the driver IIRC
<cjwatson> so I only seem to have one IDE interface, according to lspci, and /dev/sda is on that
<shawarma> cjwatson: I see. I never noticed due to the UUID fstab goodness. :-)
<cjwatson> I'm not entirely clear where the CD device would be
<shawarma> cjwatson: Nor I.
<shawarma> cjwatson: Neither Tollef nor I had access to the hard drive, IIRC.
<cjwatson> at any rate, my snap diagnosis would be a kernel problem, but I've no idea where
<cjwatson> since the device isn't appearing
<shawarma> cjwatson: Both using daily image from the 31st.
<shawarma> cjwatson: Just as I suspected. I'll file a bug.
<shawarma> cjwatson: Thanks for your help.
<cjwatson> you're welcome, sorry I couldn't be of more assistance
<cjwatson> the exceptions on ata2 seem relevant, since they're on the device that isn't claiming to have a hard disk attached. I wonder if they're merely hidden in newer versions
<shawarma> cjwatson: I don't think so.. There was a bug about it somewhere. 2 sec.
<shawarma> https://bugs.beta.launchpad.net/ubuntu/+source/linux-source-2.6.20/+bug/94637
<ubotu> Malone bug 94637 in linux-source-2.6.20 "[vmware]  ata1: reset failed, giving up" [Medium,Fix released]  
<shawarma> But mdz still manages to continue his install => clearly a different issue.
<cjwatson> shawarma: those aren't the messages I'm seeing.
<shawarma> cjwatson: no?
<cjwatson> "ata2.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen" etc.
<cjwatson> anyway, I'm grabbing a newer image and will retry on Tuesday or so (I'm away tomorrow)
<shawarma> cjwatson: Cool. I'll be sure to /msg you if I work something out with BenC.
<mjg59> cjwatson: Hm. Just speaking to someone else who's ended up with an unbootable 2.6.17 after upgrading userland to feisty.
<shawarma> mjg59: udev in feisty requires 2.6.19, doesn't it?
<cjwatson> udev in feisty also version-checks that before updating the initramfs
<mjg59> Conceivably, though breaking people's existing initramfs is sub-optimal
<mjg59> cjwatson: Ok, so that's meant to work now? Good to know.
<shawarma> True.
<mjg59> I'll try to figure out what happened.
<cjwatson> I don't think udev broke it, but something else may have done
<cjwatson> seeing as half a zillion packages update the initramfs
<mjg59> Does update-initramfs check?
<mjg59> Or is it just the udev package?
<mjg59> If the latter - ouch.
<cjwatson> it's based on the MINKVER variable in hooks
<cjwatson> it shouldn't actually be bad to regenerate the initramfs providing dependencies are satisfied, normally
<cjwatson> unless there's some weird circular dep thing going on
<mjg59> It checks all hooks and then bails if the kernel is older than any of them?
<mjg59> Sounds sane.
<cjwatson> yes, see check_minkver at the end of /usr/share/initramfs-tools/hook-functions
<cjwatson> a number of packages got upgraded before udev last I checked, though
<cjwatson> should be possible to data-mine it from /var/log/dpkg.log, and possibly the initramfs timestamp to save effort
<shawarma> mjg59: It seems to be reproducable. :-(
<shawarma> mjg59: Gah.. the initrd is 0 bytes long.
<shawarma> mjg59: I've found it, I think.
<shawarma> mjg59: update-initramfs grabs a backup of the initrd, but when mkinitramfs fails due to MINKVER not being met, it doesn't restore that backup. It's fine, if it's only run once since the initrd...dpkg-bak is still around, but the next time update-initramfs is run, a new backup (this time of the trunced initrd) is made overwriting the good one. 
<shawarma> mjg59: http://linux2go.dk/update-initramfs.diff fixes it.
<shawarma> mjg59: Or so it would seem, anyway.
<shawarma> Goodnight
<wasabi> There certainly needs to be some tighter package binding of some sort between linux-restricted-modules, the kernel, the X config, and nvidia-glx
<wasabi> I am getting a bit tired of accedently updating only part of all of that and having my media box boot up to a black screen.
<wasabi> oh. fun. this time it just didn't boot.
* wasabi sigh.
<wasabi> Um... there a launchpad way to mark a bug as critical for feisty in such a way that somebody will look at it before releasing feisty?
<Burgundavia> yes
<Burgundavia> change it so that it is proposed for this milestone --> https://launchpad.net/ubuntu/+milestone/ubuntu-7.04
<atoponce> question asked to me in my loco channel, and i don't know the answer:
<atoponce> "how long have the UUIDs for partitions been incorperated into the kernel?"
<crimsun> atoponce: do (s)he mean "into Ubuntu's kernels"?
<crimsun> s/do/did/
<atoponce> yeah
<atoponce> think so
<crimsun> well, the udev side is 093-0ubuntu5 (as of Mon, 24 Jul 2006 22:44:22 +0100)
<atoponce> i guess that works for him.
<atoponce> crimsun: thx
<stub> Launchpad is going down in 15 minutes for an update. Estimated downtime is 15 mins.
<grndslm> sorry to intrude...but i'm wondering why the devs place more emphasis on apt-get as opposed to aptitude (i.e. - in the command_not_found app)
<Hobbsee> grndslm: because it shows errors clearer
<grndslm> Hobbsee:  I see...so there's no plans to use aptitude ever?
<Hobbsee> who knows.  we may use smart.  depends on how they all evolve.  why do you ask?
<grndslm> i'm just curious...i've just never understood why you would use a "dumber" package manager...was just confusing to me
<grndslm> ubuntu's decisions seem to be the best possible, other than this...but cleared messages could be what's necessary...was just wondering
<grndslm> *clearer
<Treenaks> grndslm: in some ways, aptitude is dumber... if you have weird conflicts during upgrade, sometimes aptitude wants to delete EVERYTHING except the broken package, while apt does it the other way around
<Treenaks> grndslm: all options have their pros and cons, it's just that apt-get is "well-known", also by the devs
<grndslm> true, true...well, thanks for the clarification guys
<popey> grndslm: there has already been a bug reported about that
<popey> bah
<Treenaks> popey: too late! :)
<popey> so i see
* popey says bug 92862 anyway
<ubotu> Malone bug 92862 in command-not-found "Shouldn't be apt-get-centric" [Wishlist,Fix committed]  https://launchpad.net/bugs/92862
<Treenaks> popey: btw, what do/did you use to create those "instruction videos" ?
<popey> https://wiki.ubuntu.com/ScreencastTeam/RecordingScreencasts <- that
<Treenaks> ooh cool
* Treenaks makes a few colleagues happy ;)
<popey> :)
<Treenaks> thanks
<popey> np
<fabbione> morning
<orkid> hello
<Hobbsee> hey fabbione!
<fabbione> hey hey
<pitti> Good morning
<fabbione> hey Martin
<Hobbsee> heya pitti 
<pitti> Padre!
<pitti> Bella donna!
<fabbione> ROFL
<fabbione> pitti: what's all this italian? trying to score chicks? :)
<pitti> fabbione: si :)
<fabbione> eheh
<Hobbsee> heh
<Hobbsee> good luck with that, pitti :P
<pitti> Hobbsee: grazie
<Hobbsee> pitti: *g* 
<mneptok> pitti: ora sono destato. grazie.
* pitti hugs mneptok 
<mneptok> Hobbsee: don't be jealous. pitti and i have something special that doesn't affect the love you and i share.
<mneptok> (and by "love you and i share" i mean "the nausea you experience when thinking of me")
<Hobbsee> heh
<ajmitch> morning pitti, mneptok 
* Mithrandir yawns.
<ajmitch> hi Mithrandir 
<pitti> hi Mithrandir, good morning
<Mithrandir> morning Andrew, Martin
<kylem> morning Mithrandir 
<Mithrandir> hiya Kyle
<Mithrandir> we have over 100k bugs in malone now.
<kylem> scary, eh?
<afflux> siretart: do you still need the patch for bug #82343 ? just noticed this is still not implemented and is not a big fix... the patch on launchpad doesn't work anymore, though. I can give you a working one ;)
<ubotu> Malone bug 82343 in cryptsetup "init.d/cryptdisks doesnt create symlinks in /dev/disk/by-*" [Undecided,Unconfirmed]  https://launchpad.net/bugs/82343
<dholbach> good morning
<Sp4rKy> hi there
<Sp4rKy> 'morning dholbach 
<pitti> hey dholbach 
<siretart> afflux: looking
<Sp4rKy> i'm the sysadmin of medibuntu repos, and i would know how update-manager test update at a predefined hour, and not randomly
<siretart> afflux: the patch looks indeed sane. I need to test it this evening
<siretart> afflux: thanks for your patch!
<afflux> siretart: i think the line numbers changed, I have a working one for the 1.0.4+svn26
<afflux> not sure about that
<Sp4rKy> because, at about 6h45/7h UTC, all the server gets all connection due to update-manager
<siretart> afflux: in doubt, please attach a working one to lp
<afflux> alright
<glatzor> Sp4rKy: the cron job is in /etc/cron.daily/apt
<Mithrandir> ogra: What's happening with the trace on 97342?
<Sp4rKy> glatzor: yes, but what i would know is _why_ all the update is done at the same hour
<Mithrandir> dholbach: do you think desktop-team would be a sensible assignee for bug 69799?
<ubotu> Malone bug 69799 in gnome-system-tools "services-admin reorders acpid startup" [Medium,Confirmed]  https://launchpad.net/bugs/69799
<Sp4rKy> and why update-manager didn't choose an hour randomly at installation
<dholbach> hi Sp4rKy, hi pitti
<dholbach> Mithrandir: probably yes
<seb128> Mithrandir: we don't have anybody really working on g-s-t atm
<Mithrandir> seb128: it's release-targeted, I suspect it's easy to fix.
<seb128> I think mvo spoke with upstream about it
<seb128> mar 07 12:30:35 <mvo_>	hey garnacho! fancy to look at https://launchpad.net/bugs/69799 ?
<seb128> mar 07 12:33:01 <garnacho>	mvo_: there's little we can do with that ATM (services-admin can't really guess the priority to use, might guess it from the other runlevels, but it could be still pretty rough...)
<seb128> mar 07 12:33:44 <garnacho>	mvo_: maybe the "properties" context menu option should be more visible... (there you can edit per-runlevel priorities)
<ubotu> Malone bug 69799 in gnome-system-tools "services-admin reorders acpid startup" [Medium,Confirmed]  
<glatzor> Sp4rKy: could you please fill a problem report? It could be already to late for feisty to address this issue.
<seb128> Mithrandir: ^
<glatzor> seb128: hi, are going to upload a gnome 2.18.2 before the feisty release? otherwise I would have to import some translations manually.
<seb128> glatzor: no, 2.18.2 will be in some months
<Mithrandir> seb128: but it doesn't put everything at 10 if you disable and rename the service?
<seb128> glatzor: we will ship with 2.18.1
<seb128> Mithrandir: I'll have a look,, I don't want to break my desktop, I'll try later on my laptop
<Mithrandir> seb128: just install something you don't care about, like an FTP server or something?
<seb128> right, lemme try
<glatzor> seb128: ah, fine
<Sp4rKy> glatzor: yep i know. But i would talk with some responsible here before,to know if i can fill a bug report or if it's not necessary because this "issue" will not change
<Sp4rKy> :/
<seb128> Mithrandir: I've just tried with apache2, it does 91 -> 50
<Mithrandir> seb128: ugh. :-/
<Mithrandir> seb128: I really wonder where those values come from, though.  They don't seem to come from g-s-t itself, nor from liboobs
<seb128> Mithrandir: looks like g-s-t uses 50 for everything
<seb128> Mithrandir: 
<seb128> $ grep 50 system-tools-backends-2.2.0/Init/Services.pm 
<seb128>     $priority = 50 if ($priority == 0); #very rough guess
<Mithrandir> seb128: ugh.  We could extend the frontend to just setting it from a static table.
<seb128> Mithrandir: 
<seb128> mar 07 12:39:39 <mvo_>	garnacho_: could we assign default priorities to the things? so that we can genertate (or auto-generate) that based on the defatuls in ubuntu?
<seb128> mar 07 12:41:16 <garnacho_>	that'd be great :)
<seb128> mar 07 12:41:42 <garnacho_>	hmm, even better would be getting rid of those pointless priorities :P
<seb128> Mithrandir: not sure that's something we want to start on now though
<Mithrandir> we are not going to transition the whole system to upstart events two and a half weeks before release. :-)
<seb128> right, I was speaking about the priorities list
* pitti celebrates bug #100000
<ubotu> Malone bug 100000 in malone "There are still too many bug reports" [Undecided,Confirmed]  https://launchpad.net/bugs/100000
<zyga> hey
<Mithrandir> seb128: oh, true, but do you have a better idea?
<seb128> Mithrandir: not really no, the bug is not new though, that's no a regression and we didn't get many complains about it during previously cycles, I would not bother too much
<Mithrandir> seb128: hm, point.
<Mithrandir> Keybuk: do you have any plans wrt upstartification for feisty+1
<Mithrandir> ?
<doko> fabbione, pitti: any idea why https://launchpad.net/+builds/+build/315658 would fail in dh_strip?
<Mithrandir> (and do we have a name for feisty+1 soon?)
* pitti votes for Glamourous Gnu
<Mithrandir> I want a giraffe.
<doko> gargoyle
<pitti> strip: debian/eclipse/usr/lib/eclipse/eclipse: File format not recognized
<pitti> urgh
<fabbione> doko: that's pitti's deb mangler
<doko> fabbione: I'm not sure ...
<Keybuk> pitti: I have to tag bugs to get them retraced, right?
<Keybuk> Mithrandir: vague plans, yes
<pitti> Keybuk: right
<Keybuk> pitti: what are the tags?
<pitti> Keybuk: need-{amd64,i386,powerpc}-retrace
<fabbione> doko: did you try on faure?
<fabbione> doko: does it happen without the package mangler?
<doko> fabbione: doesn't build on faure, smp problems ... please fix it
<pitti> doko: AFAICS, it's strip itself that fails, and thus the original dh_strip fails
<fabbione> doko: file a bug on the kernel and ask Ben to look at it. kthxbye
<pitti> exec $REAL_DHSTRIP "$@"
<pitti> ^ it fails here
<doko> fabbione, BenC: that bug is now open for months ...
<fabbione> doko: you opened one on OOo
<fabbione> i haven't seen any on eclipse
<doko> fix that first
<fabbione> doko: plus you have a sparc with a chroot to test.. does it happen there too?
<doko> fabbione: yes
<fabbione> same cpu as faure?
<fabbione> is it SMP or UP?
<doko> fabbione: I don't have a sparc besides faure at the moment
<fabbione> doko: you told me you had one with a chroot != faure
<fabbione> doko: anyway there isn't much i can fix.. testing kernels on faure is not really an option without full root access on the box...
<fabbione> and nether me or davem have that kind of CPU at home
<fabbione> doko: the only thing would be to take down faure -> move it somewhere i can get full root access -> try to fix -> return faure back
<ogra> Mithrandir, can you approve 96103 as RC ?
<Keybuk> siretart: ping
<Keybuk> Mithrandir: context for question?
<Mithrandir> Keybuk: bug 69799
<ubotu> Malone bug 69799 in gnome-system-tools "services-admin reorders acpid startup" [Medium,Confirmed]  https://launchpad.net/bugs/69799
<Mithrandir> ogra: no.  If you have a complex setup, don't use NM (yet).
<Keybuk> Mithrandir: why does gst do that?!
<ogra> Mithrandir, i thought you said you would add a config option to /e/n/i for that
<siretart> Keybuk: yes?
<Keybuk> siretart: did the packages I made help you at all?
<tepsipakki> please test 0.7.7.7:
<ogra> Mithrandir, when i asked if i should undeed it for edubuntu
<tepsipakki> sorry
<tepsipakki> middleclick error :)
<Mithrandir> ogra: yes, that bug is not asking for that, it's asking for support for multiple NICs in NM.
<siretart> Keybuk: I'm sorry to tell you that your package broke the bootup procedure of my system completely, I had to revert to the feisty ones
<Mithrandir> Keybuk: because it smokes crack.  Or rather, guesses and guesses wrongly.
<Keybuk> siretart: more verbose
<Keybuk> what broke and how?
<siretart> Keybuk: the mdadm-raid init script timout'ed on every LV, and disabling that init script didn't help
<siretart> Keybuk: my system timeouted somewhere else
<pitti> Keybuk, cjwatson, other british folks: would you say that the majority of users considers Monday as start of the week? (I have a bug about changing it, current setting is Sunday, I think) 
<ogra> Mithrandir, well, thats nitpicking, the bug starts with: I have two NICs and I want them both active at the same time.
<Keybuk> pitti: Sunday is the canon start day
<pitti> Keybuk: ISO 8601 says Monday, and two bugs requested it, so I'm not sure
<siretart> Keybuk: this however is a problem after having my root volume, the initramfs brought up my raid devices correctly, but not lvm
<siretart> Keybuk: I still had to 'lvm vgchange -ay' by hand to get my root volume
<Keybuk> siretart: I'll need you to debug more
<Mithrandir> ogra: then the submitter should have used a better title.  He is complaining about NM not supporting more than one nic, he's not saying "I want to do this and I can't because of $foo".
<Keybuk> pitti: actually, UK tradition may be Monday as the first
* Keybuk isn't sure
<siretart> Keybuk: FYI: on friday, I tested iwj's test packages again, and they showed the same behavior in the initramfs: all raid devices fine, no lvm
<Keybuk> siretart: iwj's test packages?
<fabbione> Keybuk: one udev rules question for you.. when the kernel adds a block device, udev starts executing all the rules related to block devices in the numbering order as they appear in rules.d/ .. let say that one of these rules needs to wait for 5 seconds before the next one is executed.. can that be done by adding a sleep or udev does not wait and just execute all the rules?
<Keybuk> fabbione: it can be done with a sleep
<fabbione> Keybuk: thanks
<Keybuk> though that suggests a race condition?
<Keybuk> it would be better to not sleep, since you can't guarantee you'll sleep long enough?
<siretart> Keybuk: http://www.chiark.greenend.org.uk/~ian/d/udev-nosyslog/
<Keybuk> siretart: right, that just adds an option for debugging
<Keybuk> siretart: are you going to be able to help debug your problem today?
<fabbione> Keybuk: yes it's a very very specific corner case where I know the response time of the hw
<Keybuk> fabbione: ah, shouldn't be a problem then
<siretart> I think he changed that a bit further, and told me to patch one script.. need to fetch the irc log
<fabbione> Keybuk: nope.. i just have to make sure that udev will wait before executing the next rules...
<Mithrandir> asac: about bug 99655, what is your take on that?  Should we drop pango-libthai and use the support in pango proper?
<ubotu> Malone bug 99655 in pango-libthai "pango-libthai ships nothing" [Undecided,Confirmed]  https://launchpad.net/bugs/99655
<siretart> Keybuk: http://paste.debian.net/24837 is what iwj told me to do
<Mithrandir> sladen: I think 98648 is bogus and should be rejected, do you disagree?
<Keybuk> siretart: will you be able to install new packages and test with them?
<ogra> Mithrandir, ok, i un-duplicated Bug #100021 and added n-m 
<ubotu> Malone bug 100021 in ltsp "[Feisty]  LTSP fails on multi-homed server due to network manager touching predefined static interfaces" [Undecided,Confirmed]  https://launchpad.net/bugs/100021
<siretart> Keybuk: this evening, sure. I'm currently at work
<Keybuk> siretart: damn
<Keybuk> unfortunately if I can make this work for me in vmware, I may have to upload because it seems to fix it for others
<Keybuk> this evening will be too late
<siretart> Keybuk: can you imagine what could have caused the mdadm-raid script to timeout?
<Keybuk> siretart: I understand very little about mdadm/lvm
<Keybuk> I don't even understand what that script *does*
<siretart> Keybuk: I could install them remotely, and tell my gf to watch the boot procedure. However, if the system doesn't boot any longer, I cannot access it until I get back home
<Mithrandir> pitti: I know you're a postgres and not a mysql guy, but do you have a bit of time to look at bug 95821?
<ubotu> Malone bug 95821 in mysql-dfsg-5.0 "Replication failure with auto-increment and on duplicate key update" [Undecided,Unconfirmed]  https://launchpad.net/bugs/95821
<pitti> Mithrandir: sounds complex and upstreamish, but I can take a look at it if you really need me to
<siretart> Keybuk: perhaps Nafallo wakes up and can test your packages?
<Mithrandir> pitti: I don't have anybody better suited for the task, and it looks kinda critical-ish.
<pitti> Mithrandir: alrighty
<asac> Mithrandir: yes, the idea is to build pango with libthai-dev ... should do the trick (according to thep)
<Mithrandir> asac: ok, can you make sure that happens (in coordination with seb128 or dholbach, I suspect)
<asac> Mithrandir: sure ... will do
<Mithrandir> asac: thanks a lot.
<Mithrandir> pitti: about the mysql bug, maybe it's better to just update to the newer upstream version?
<pitti> Mithrandir: if you would generally be fine with that, sure
<pitti> Mithrandir: upstream's microreleases are generally fine
<pitti> Mithrandir: otherwise we can still backport the single bug fix commit
<pitti> Mithrandir: but I'd be happy to grab 5.0.38 and give it some test runs
<Mithrandir> pitti: I'd want to take a look at an debdiff just to make sure they didn't rewrite half the engine, but if they're generally cautious about the microreleases, I'm not opposed to it.
<Mithrandir> pitti: if you could, that'd be great.
* Keybuk had forgotten just how much noise and mess a puppy can make
<pitti> Mithrandir: sure, I'll review the diff and changelog for general sanity and report back to you
<pitti> there are probably more fixed we are interested in
<Mithrandir> pitti: coolie.
<Mithrandir> Keybuk: new dog?
<Keybuk> Mithrandir: yeah, a second border collie
<Mithrandir> Keybuk: yay, dogs++. :-)
<Keybuk> he arrived at the weekend, so is still in that "scream the house down hourly every night" phase
<Mithrandir> yeah
<Mithrandir> and you have to make sure to take him out fairly often and such.
<\sh> Mithrandir: do we include a patch fopr 
<Keybuk> yup
<\sh> for mysql bug #27294?
<ubotu> Malone bug 27294 in esound "esound: breaks since ALSA 1.0.10 transition; fixed by Ubuntu patches" [High,Rejected]  https://launchpad.net/bugs/27294
<Keybuk> he's being surprisingly good actually, and waiting until I take him out before going to the loo
<\sh> grmpf
<Mithrandir> \sh: that's hardly a mysql bug. :-P
<Keybuk> of course, he goes again as soon as he gets back in, but the spirit is there
<\sh> http://bugs.mysql.com/bug.php?id=27294
<\sh> Mithrandir: for sure ;) 
<Mithrandir> Keybuk: yup, that's good.
<Mithrandir> \sh: no idea, but we might want to.
<\sh> Mithrandir: I could prepare something for feisty...cause the bug was produced here, and patch fix as well.
<\sh> Mithrandir: there is also another fix for the same problem http://bugs.mysql.com/bug.php?id=21322 ;)
<Mithrandir> \sh: if you could coordinate with pitti who's looking at updating mysql for another problem, that would be good.
<\sh> Mithrandir: surew
<pitti> Mithrandir: ubuntu seeds updated to fight downsizing; doing Kubuntu now
<Mithrandir> pitti: cheers
<pitti> Kubuntu done as well
<pitti> edubuntu is okay
<pitti> seb128, tepsipakki: hmm; I built/installed your new libx11 package, purged *xcb*, restarted X, and I still get the xcb assertion with vmware; where could this come from now?
<seb128> vmware
<pitti> tepsipakki: oh, maybe vmware is statically linked against xcb?
<tepsipakki> maybe
<tepsipakki> do you have 6.0rc?
<pitti> tepsipakki: no, 5.5.3
<tepsipakki> ok, xcb didn't exist then :)
<seb128> pitti: remove the libx11 old build you have to /usr/local :p
* seb128 runs
* pitti hugs seb128
* seb128 hugs pitti back
<fabbione> Keybuk: i assume what you told me about the sleep is true for dapper/edgy/feisty, right?
<fabbione> Keybuk: and if i change a rule do i need to restart udev or it will be executed as new at the first trigger?
<tepsipakki> pitti: that error is from libx11 anyway
<seb128> pitti: does the "non-xcb libx11" works fine for you?
<pitti> seb128: no, as I wrote
<pitti> very same error
<pitti> tepsipakki: ooh, wait
<pitti> tepsipakki: I didn't purge libxcb-dev before building
<pitti> tepsipakki: maybe configure picked it up and used libxcb again?
<pitti> however, there's no libxcb library any more
<seb128> pitti: my question was not clear, "no regression over the xcb version"?
<tepsipakki> pitti: the version I built still had the deps
<seb128> like "should we upload the non xcb version now"
<pitti> seb128: ah; nothing noticeable so far
<Keybuk> fabbione: yup, just put RUN+="/bin/sleep 5" in
<Keybuk> fabbione: shouldn't need to restart
<Milan> hi! I've just seen on Feisty that udatedb is run by cron daily. Is this really useful for most of users ?
<pitti> seb128: I guess this more or less matches the edgy version again then?
<fabbione> Keybuk: yeps.. thanks.. 
<seb128> pitti: new upstream version though, not sure on how much they changed out of xcb
<pitti> tepsipakki: indeed, the package still b-deps on xcb
* pitti uses -d and tries
<pitti> tepsipakki: your libx11 builds fine without the xcb build deps
* pitti tests X server with updated library, just for thoroughness
<Milan> nobody can tell me what updatedb is run for? I don't see the point of having locate work on a standard desktop station.
<Keybuk> Milan: geeks expect it to work
<Keybuk> and geeks are the only people who tend to leave their computer on over night
<Milan> Keybuk: ;-) why do we set it on by default?
<Keybuk> because it's on in Debian
<Keybuk> it'd be work for us to turn it off
<pitti> Keybuk: and thanks to anacron it even works for people who switch it off
<Milan> Keybuk: rm /etc/crond.daily/slocate
<pitti> but locate is love!!
<Keybuk> Milan: yes, but why would we do that?
<Keybuk> Milan: is it causing you a problem?
<Milan> pitti: that's the problem: turning on my computer, the HDD is working
<Keybuk> Milan: at which point?
<Milan> Keybuk: locate is really useless for 90% of users, and it's working everyday to check the FS
<pitti> Milan: many people turn on beagle, which makes the problem ten times worse..
<Milan> pitti: I know, there's a bug in /etc/cron.daily/beagle-crawl-system too. But Beagle is useful for some people
<Keybuk> Milan: anacron will only fire sometime *after* boot if the system isn't busy
<Milan> I mean: wouldn't it make sense to trun locate off by default, assuming that geeks will turn it on easily ?
<Milan> I think it would be worth discussing that issue
<pitti> Milan: to a certain degree I agree
<Milan> oh good :-)
<Milan> the thing is my dekstop is too often working without I know what it is doing, and this is really not a good point
<Keybuk> Milan: start a discussion on the ubuntu-devel-discuss mailing list
<Keybuk> suggest that it (and maybe other daily sysadmin-specific activities) be disabled by default
<Keybuk> and work out with people there how it would be enabled again, etc.
<Keybuk> and then produce a specification and register it in launchpad for the next release
<Milan> I'll mail about it - but I have certainly no time to write a spec now
<cjwatson> it's not only geeks who use locate; it's also people who are told by wiki page instructions etc. to use locate t ofind something
<Milan> we'll see what the thread will tell
<doko> seb128, dholbach: is the tangerine theme something else than the tango theme?
<c4n3R> geldim a.q
<c4n3R> :D
<cjwatson> beagle isn't installed by default so it doesn't count yet
<dholbach> doko: yes
<seb128> doko: yes, tango is blue
<seb128> doko: tangerine is orange ;)
<c4n3R> kanka by_KuSs:D
<by_KuSs> Sieeeeeeeeee
<c4n3R> amn ziktiklerim konusuyo bak :D
<doko> seb128: so it's called "human" as well?
<by_KuSs> a.qdukLarm
<c4n3R> haha:D
<c4n3R> HHHHHH
<c4n3R> :D
<seb128> doko: no, Human is the Ubuntu theme
<doko> I'm confused ...
<c4n3R>  seb128 ; anann am... :D
<seb128> doko: tangerine is tango with an orange palette
<seb128> doko: Human is an original design, tangerine is tango style icons made to work with the Human color I think
<by_KuSs> A.q Szn.
<by_KuSs> AmckLar.
<c4n3R> :D
<c4n3R> yaa
<c4n3R> zokaym
<c4n3R> amna
<seb128> doko: dholbach knows that better though
<c4n3R> seb128 turkce
<c4n3R> konus
<doko> seb128: ok, thanks.
<c4n3R> :D
<c4n3R> o.D:
<c4n3R> IRC.DiyalgoTR.Com
<c4n3R> :D
<c4n3R> D:
<NapaLmDeath> c4n3R
<NapaLmDeath> :D
<c4n3R> :))
<NapaLmDeath> HelaL 
<NapaLmDeath> :D
<c4n3R> burdareklam
<c4n3R> yapcaz
<c4n3R> anneklerini
<c4n3R> sikicem ben
<c4n3R> :D
<NapaLmDeath> AnaLArn Sikerim
<NapaLmDeath> unLarn 
<NapaLmDeath> :D
<c4n3R> :D
<c4n3R> by_KuSs
<c4n3R> sende zi:D
<NapaLmDeath> kanaL opu iLe yok aq :D
<c4n3R> seb128 Fuck off:D
<c4n3R> ama
<by_KuSs> Ahauyabauahah
<by_KuSs> :D
<by_KuSs> AnneSzLer.
<NapaLmDeath> :D
<c4n3R> :D
<Fujitsu> !ops
<ubotu> Help! Mez, LjL, elkbuntu, imbrandon, DBO, gnomefreak, Hobbsee, rob, ompaul, Madpilot, Burgundavia, Seveas, CarlK, crimsun, ajmitch, tritium, Nalioth, thoreauputic, apokryphos, tonyyarusso, PriceChild, Amaranth or jrib
<c4n3R> see you:D
<by_KuSs> ubotu
<by_KuSs> Skm ye :D
<c4n3R> ubotu
<c4n3R> anan
<NapaLmDeath> !op
<c4n3R> bi
<NapaLmDeath> :D
<by_KuSs> Skm ye :D
<c4n3R> zikerim
<by_KuSs> Skm ye :D
<c4n3R> warya
<c4n3R> :D
<by_KuSs> :D
<c4n3R> akln
<c4n3R> durtur
<c4n3R> gtn tawana wrur
<c4n3R> ;)
<NapaLmDeath> HEy WomenLer sikerim sizi :D
<by_KuSs> :D
<c4n3R> :D
<by_KuSs> a.q
<apokryphos> hm, we need more ops in here.
<by_KuSs> ne Skm
<c4n3R> a.k:))
<by_KuSs> Server
<by_KuSs> CycLe ot :; )
<c4n3R> annene,
<c4n3R> in
<c4n3R> here:D
<c4n3R> achil was here..!
<c4n3R> D:
<c4n3R> klsfmslfs
<NapaLmDeath> apokryphos Sikeyim seni orospu Cocugu YunanL :D
<by_KuSs> NapaLmDeath
<by_KuSs> falfa
<vciaglia> that's really a stupid thing
<jenda> hello
<NapaLmDeath> bigjools Aq Senin La ingiLiz Orospusu
<by_KuSs> yes yes
<by_KuSs> Anan Skcem :D
<c4n3R> EMPTY, THIS PLACE, 
<c4n3R> EMPTY, THIS PLACE, 
<c4n3R> ananz
<apokryphos> jenda: ^ :)
<c4n3R> sikerim
<c4n3R> yoksa
<c4n3R> :D
<c4n3R> EMPTY, THIS PLACE, 
<c4n3R> :D
<NapaLmDeath> vciaglia Aanan Sikerim Senin Stupid ide
<c4n3R> geldi
<c4n3R> amciklar:D
<Mithrandir> imbrandon: could you please apply a bunch of bans here?
<by_KuSs> qRsLere ak A.q
<SeJo> sorry jenda i'm out :-) 
<Fujitsu> Mithrandir: Nobody around has powers... But jenda is here, so all should be good.
<c4n3R> LEAVE, THIS PLACE,  Mithrandir
<c4n3R> :D
<imbrandon> Mithrandir, i'm trying seems my access is gone
<by_KuSs> las
<by_KuSs> gfi
<c4n3R> hay
<c4n3R> ananz sikim tya
<c4n3R> :D
<c4n3R> bye
<c4n3R> a.q
<c4n3R> :
<c4n3R> :D
<c4n3R> 
<c4n3R> 
<by_KuSs> ehefjaf
<Mithrandir> Keybuk: you seem to have ops, care to clean up?
<imbrandon> jenda, can you clean this up and then poke about where my access went
<apokryphos> we'll get more ops added once Seveas is around
<jenda> imbrandon: no, I can't sorry.
<RichiH> imbrandon: so, whatcha need?
* mode/#ubuntu-devel [+o fabbione]  by ChanServ
<apokryphos> imbrandon: freenode/staff/ isn't in, as well :/
<cjwatson> we should have a few more core developers with ops, since we tend to pay close attention here
<Fujitsu> There does seem to be a bit of an op shortage lately.
<imbrandon> apokryphos, ahh figures
<mneptok> ooo! fabbione!
<apokryphos> Fujitsu: not in the other channels, but here (since it's so rarely had problems). We can easily fix that though.
<mneptok> fabbione: can you add me to the access list for -devel?
<fabbione> humpf.. 2 minutes that i am behind the rack resetting the SAN and the world goes foobar
<fabbione> mneptok: i don't have the channel password...
<fabbione> i was made op
<Fujitsu> apokryphos: Takes a few minutes in #ubuntu at times...
* mode/#ubuntu-devel [+o mneptok]  by fabbione
<jenda> fabbione: and maybe you could add *@freenode/staff/* too :)
<mneptok> fabbione: alright. i'll bother Dennis.
<denny> fabbione doesn't have access to modify the access list  :)
<apokryphos> fabbione: have to wait for Seveas or thom
<fabbione> jenda: same as what i said to mneptok .. i don't have the channel password
<cjwatson> the ops list here dates from 2004.
<denny> needs to be thom
<Fujitsu> Only thom and staff can modify it.
* mode/#ubuntu-devel [+b *!*NapaLm@85.103.55.*]  by mneptok
<fabbione> thom: ping?
<apokryphos> Fujitsu: or Seveas, yes.
<Fujitsu> apokryphos: Ah, I suppose he would have the password.
* mode/#ubuntu-devel [+b *!*asa@85.98.111.*]  by mneptok
<cjwatson> mneptok: asa@85.98.111.224 and Yuzuk-4@88.243.106.131 were the other two troublemakers
<cjwatson> ah, you're on it
<jenda> apokryphos: nope.. only staff when told to by Seveas.
<jenda> (and thom)
<apokryphos> jenda: same thing; just indirectly :)
<jenda> hehe
* mode/#ubuntu-devel [+b *!*Yuzuk*@88.243.106.*]  by mneptok
<RichiH> fabbione: it would probably be a good idea to poke whoever can set access levels to add freenode staff to the list. that means we know we are allowed to do emergency stuff
<RichiH> of course, if there is a huge flood, i would just set the channel +m, anyway
<RichiH> but we will not do anything against lesser stuff unless we know we are allowed to by channel owners
<mneptok> RichiH: beats screaming "WE'RE DOOMED" and trampling the children to reach the door.
<apokryphos> RichiH: we do tend to have staff on the access lists for all ubuntu channels (it's one of our policies); just must've missed it on this one; soon.
<RichiH> mneptok: heh, i generally avoid trampling anything i do not plan to eat
<RichiH> apokryphos: yah, no worries
<RichiH> you can probably force jenda to write a script to check regularly
<mneptok> RichiH: are you hitting on me?
<mneptok> ;)
<RichiH> mneptok: of course i am ;)
<mneptok> @lart 37 RichiH 
<jenda> RichiH: That would be hard...
<mneptok> bah
<mneptok> !lart 37 RichiH 
<ubotu> Sorry, I don't know anything about lart 37 richih - try searching on http://bots.ubuntulinux.nl/factoids.cgi
<mneptok> the bots taunt me.
<jenda> @lart 37 mneptok 
<jenda> hehe, probably not in -devel :)
<Keybuk> Mithrandir: someone beat me to it I think
<Keybuk> :p
<RichiH> jenda: not too much, with chanserv list and access list parsing, you should be able to do it rather easily in perl. the fact that you can look through private bits helps, of course
<jenda> RichiH: I meant, forcing me would be hard.
<RichiH> ah
<RichiH> jenda: they should just employ the local mafia
<jenda> RichiH: how many times am I going to tell you, 1) There is no mafia in this country 2) They wouldn't dare touch their own boss.
<mneptok> that is, if they had a boss. if they existed. which they don't.
<RichiH> jenda: 42
<pitti> \sh: I'm currently evaluating 5.0.37; what was it you wanted to see there?
<gnomefreak> guys the correct ops are now listed when called !ops in here 
<mvo> Riddell: AYT?
<Riddell> mvo: whit?
<mvo> Riddell: 
<mvo> Riddell: I wonder about #100074
<mvo> Riddell: (and duplicates). it seems its only triggered under kde, is the tmpdir extraction in adept changing the permissions of the files somehow?
<Riddell> shouldn't do
<jenda> mneptok: you can take off the bling now ;)
<Riddell> mvo: what's it trying to run?
<jenda> adios
<mvo> Riddell: a included script that is run after the upgrade
<mvo> Riddell: urgh, I just checked, it seems to remove all "x" bits 
<Riddell> mvo: mm, so it does
<Riddell> mvo: I wonder why it would do that
<mvo> Riddell: I work around it for now
<linuxero> hello
<linuxero> a question
* mode/#ubuntu-devel [-o mneptok]  by mneptok
<dholbach> pitti: bughelper is broken with the new LP UI
<dholbach> pitti: just to let you know that a fix for launchpadBugs is in the works
<pitti> dholbach: oh, thanks for notifying; for the public LP as well, or just for beta?
<StevenK> pitti: Beta has been released.
<pitti> uuh, indeed
<pitti> no beta. any more
<StevenK> For about a week, sabdfl said in his blog.
<Fujitsu> Beta is still beta, just public.
<pitti> Fujitsu: not visible in the URL any more, then
<Fujitsu> That too.
<dholbach> pitti: ok, seems that Bug() is unaffected
<dholbach> pitti: BugList seems broken though - which does not need to bother you :)
<pitti> dholbach: I think it does
<pitti> ./bin/launchpad-crash-digger:        for b in BugList(Struct(url = self.list_url, upstream = None
<dholbach> pitti: oh ok - I'm poking it
* pitti hugs dholbach, thank you!
<pitti> dholbach: /me wants xmlrpc
<Mirv> pitti: do you know why some of the 20070329 language packs are not getting build?
<pitti> Mirv: no, I don't; buildd congestion?
<Mirv> pitti: yeah, I tried to find out but to no avail. there are many packages that have been built since. but I just found a bug report too: https://bugs.launchpad.net/ubuntu/+source/language-pack-gnome-pt-base/+bug/99525
<ubotu> Malone bug 99525 in language-pack-gnome-pt-base "Can't install Portuguese Language gnome " [Undecided,Confirmed]  
<Mirv> but maybe some builds are done at a different place and there is a congestion somewhere that only affects some packages
<Mirv> anyway, five days is quite a long time for packages not to build
<shawarma> cjwatson: I found the bug mjg59 talked about last night. The one about doing an edgy->feisty userland upgrade breaks. 
<shawarma> cjwatson: I don't know if you saw the patch I sent?
* cjwatson <- not initramfs-tools maintainer
<shawarma> cjwatson: Oh. you're the last uploader. :-)
<cjwatson> also on holiday today, so going to do other things now ;)
<shawarma> cjwatson: Oh, right. I forgot. Sorry.
<cjwatson> shawarma: no I'm not (the last uploader) ..
<shawarma> cjwatson: Oh, ok. I must be a few days behind on the updates.
<ogra> hmm, whats wrong with the mailman archives ? https://lists.ubuntu.com/archives/feisty-changes/ doesnt have any april entrie
<ogra> *entries
<ajmitch> it's getting further & further behind
<pochu> do we know when the herd6 candidates will be available?
<ajmitch> iirc the box can't keep up 
<Fujitsu> ubuntu-bugs is 12 hours behind.
* doko -> lunch
<shawarma> ogra: The disk is full, AFAIK.
<Fujitsu> (that's not the archives, but the actual mail)
<ajmitch> shawarma: I thought that was a separate issue?
<shawarma> ajmitch: Possibly. 2 sec.
<cjwatson> shawarma: that's a different machine.
<Fujitsu> I know one of the LP servers filled up a few days back...
<cjwatson> mailman archiving => slow, merge-o-matic => ENOSPC
<shawarma> 01:33 < smithj> the ubuntu-patches mailing list seems to have not gotten any patches since march 7. given that i don't think ubuntu has ceased  development, what's up with that?
<ogra> shawarma, ah
<Fujitsu> cjwatson: Ah.
<shawarma> 01:44 < cjwatson_> smithj: I believe that's because the machine running that has run out of disk space; there's a sysadmin ticket open for it
<shawarma> ajmitch: ^^
<ajmitch> shawarma: yes, that's what I was referring to
<shawarma> cjwatson: Ah, ok. Sorry.
<Fujitsu> It's still an issue after almost a month? Must be busy sysadmins.
<ajmitch> very
<Keybuk> Fujitsu: canonical has just moved office, I suspect they're mostly tied up with that :-/
<Keybuk> not to mention the LP beta, upcoming Ubuntu release *and* other pending releases
<Fujitsu> Keybuk: Ah.
* StevenK comes to the conclusion that Vmware does not like 64-bit hosts. :-/
<Keybuk> StevenK: ?
<ajmitch> StevenK: why so? I run vmware server without any issues
<pitti> StevenK: xcb assertion startup?
<StevenK> No, worse than that. It wants /lib/ld-linux.so.2
<\sh> pitti: rational bug: http://bugs.mysql.com/bug.php?id=25526, there is a patch which is really fixed in http://bugs.mysql.com/bug.php?id=21322
<ajmitch> you have the relevant ia32-libs stuff installed?
<\sh> pitti: sorry for answering now...but I had some nightmare with out ldap servers
<StevenK> ajmitch: It seems not, given I hadn't heard of that package.
<pitti> \sh: I'll check if it is applied in 5.0.37
<ajmitch> StevenK: not sure if it'll help
<StevenK> ajmitch: That seems to be it.
<\sh> pitti: if not, I 'll prepare a patch...we (@combots) are running all the time into this error
<\sh> brb...dner time ,-)
<Keybuk> kebab?
<pitti> \sh: Guten Appetit
<ogra> hmm
* ogra ges hungry
<ogra> *gets
* pitti too
* seb128 lunch
<ogra> to bad i just sat down in my deckchair in the garden and am to lazy to pock up a kebab
<ogra> *pick
* Fujitsu notes that we're being overrun by Germans here.
<mneptok> ogra: wait for a squirrel to fall into your mouth?
<ogra> haha
<ogra> no barbecue in the trees here ....
<ogra> i dont eat raw squirrels .... way to furry
<bhale> ogra: you wre supposed to skin them
<mneptok> Fujitsu: die Weltherrschaft ist fast komplett.
<ogra> bhale, bah
<ogra> i thought *they* are supposed to fall in my mouth
<Fujitsu> mneptok: Nein!
<Fujitsu> mneptok: Geh Heim.
<mneptok> Fujitsu: 
<mneptok> 
<mneptok> Fujitsu: Babel Fish Translation   	Help
<mneptok> Auf deutsch:
<mneptok> ;)
<mneptok> OK, time to go home.
* Fujitsu speaks very limited German.
<mneptok> ach so.
<mneptok> just wait. you'll learn more soon.
<mneptok> yes. very soon now ...
<bhale> mneptok: tschuss!
<pitti> bhale: you still have to practice Umlauts :)
<Fujitsu> mneptok: Macht spass!
<bhale> pitti: my keyboard doesnt enjoy them.
<ogra> bhale, ou can fix that by adding an e behind ...
<bhale> if i change the layout there is something to be done with the Compose key
<ogra> tschuess would be the right one ;)
<shawarma> bhale: I think Compose+" followed by u would do it?
<Fujitsu> shawarma: That'd be right.
* Fujitsu tries.
<pitti> \sh: doesn't look like even being committed upstream, let alone released; there's an almost-correct patch attached to http://bugs.mysql.com/bug.php?id=27294 
<pitti> \sh: that one's easy enough to adapt, though
<Nafallo> Keybuk: packages? :-)
<bhale> shawarma: i changed keymap to us intl with deadkeys, set caps lock to compose in gnome-keyboard-properties, every time i hit capslock-u it beeps at me
* Fujitsu just uses US, with Right-Alt set to compose.
<Monk-e> Fujitsu, how does that work exactly?
<shawarma> bhale: If you've got deadkeys, you shouldn't need compose.
<shawarma> bhale: On Danish keyboards there's a button with an umlaut. Pressing that and then an a gives me .
<Nafallo> Keybuk: btw, http://home.nafallo.info/bugs/udev.txt :-)
<pitti> seb128, tepsipakki: indeed, StevenK brought it up: of course vmware uses the ia32-libs version of libx11, which still has xcb; so we'd just need to update it once again
<pitti> tepsipakki: so my recent failure was due to the recently updated ia32-libs
<seb128> pitti: ah, ok
<pitti> seb128: so I'll update ia32-libs after the new libx11 is in
<seb128> ok
<jwendell> hi, pitti 
<pitti> Hi jwendell 
<jwendell> pitti, is there any problem with language-pack-gnome-pt-base package build?
<jwendell> pitti, it's not available in repository yet
<Mirv> jwendell: i just asked pitti about it, there's a bug reported about it and other similar problems
<pitti> not sure, it says 'successfully built'
<Mirv> jwendell: https://bugs.launchpad.net/ubuntu/+source/language-pack-gnome-pt-base/+bug/99525
<ubotu> Malone bug 99525 in language-pack-gnome-pt-base "Can't install Portuguese Language gnome " [Undecided,Confirmed]  
<pitti> jwendell: language-pack-gnome-pt-base | 1:7.04+20070329 | http://archive.ubuntu.com feisty/main Packages
<pitti> jwendell: looks good ot me
<pitti> s/ot/to
<pitti> jwendell: even on the German mirror already
<jwendell> pitti, 
<jwendell> wendell@wendell-laptop:~$ LANG=C apt-cache policy language-pack-gnome-pt-base
<jwendell> language-pack-gnome-pt-base:
<jwendell>   Installed: 1:7.04+20070313
<jwendell>   Candidate: 1:7.04+20070329
<jwendell>   Version table:
<jwendell>      1:7.04+20070329 0
<jwendell>         500 http://archive.ubuntu.com feisty/main Packages
<jwendell>  *** 1:7.04+20070313 0
<jwendell>         100 /var/lib/dpkg/status
<pitti> so, that's fine; where's the problem?
<shawarma> Who to bug about initramfs-tools bugs? The kernel team? infinity?
<jwendell> wendell@wendell-laptop:~$ LANG=C apt-cache policy language-pack-gnome-pt
<jwendell> language-pack-gnome-pt:
<jwendell>   Installed: 1:7.04+20070313
<jwendell>   Candidate: 1:7.04+20070313
<jwendell>   Version table:
<jwendell>  *** 1:7.04+20070313 0
<jwendell>         500 http://archive.ubuntu.com feisty/main Packages
<jwendell>         100 /var/lib/dpkg/status
<pitti> jwendell: ah, that's not -base
<jwendell> pitti, yep, sorry :)
<pitti> successfully built as well
<pitti> Mithrandir: any idea why some built packs might be missing? failed-to-move again?
<Mirv> yeah, language-pack-gnome-pt, language-pack-gnome-fi-base and language-pack-fi as examples are not in the archive
<Keybuk> Nafallo: http://people.ubuntu.com/~scott/packages/
<Mirv> while eg. language-pack-gnome-fi and language-pack-fi-base are
<pitti> Mithrandir: (not that I would know what f-t-m is all about, but it was the reason for such problems in the past)
<Mithrandir> pitti: yes, 19 packages, reprocessing.
<\sh> pitti: 5.0.38 should have it, afaik
<pitti> Mithrandir: cheers
<pitti> \sh: latest upstream release is .37
<Mirv> Mithrandir: thanks!
<\sh> pitti: jepp, but .38 is on it's way ;) but nothing for feisty, yes
<Mithrandir> 11 language packs in accepted now.
<\sh> pitti: and we can backport this patch to dapper/edgy
<janimo> can a TB member please extend my membership in MOTU and core-dev? LP has been mailing me that it will expire in a few days.
<Mirv> mpt: thanks for https://bugs.launchpad.net/launchpad/+bug/100000 , I just happened to check if 100k has been reached and it was :)
<ubotu> Malone bug 100000 in malone "There are still too many bug reports" [Undecided,Confirmed]  
<Keybuk> Janimo: done
<janimo> Keybuk: thanks
<siretart> Nafallo: run_program: '/lib/udev/watershed' (stderr) 'mdadm: failed to add 8:35 to /dev/md/2: Invalid argument' <- this sounds scary.. 
<Nafallo> ouch :-P
<Nafallo> maybe I should wait til I figured out why my client dies all the time...
<siretart> but according to the log, it seems that your lvs are started as they should
<siretart> hm
<Nafallo> aha. you were looking at my log :-)
<siretart> oh, I should have told you before ;)
<Nafallo> case still holds though. my headless server is the only reliable computer I have atm :-/
<Nafallo> not sure if I can do much testing while I don't know when things are going to die hard.
<jsgotangco>  hey Hobbsee
<tepsipakki> pitti: ok, maybe I should just upload libx11 which doesn't use xcb, unless someone objects
<pitti> tepsipakki: *nod*, works fine here
<pitti> tepsipakki: oh, can you upload yourself now?
<tepsipakki> pitti: sure ;)
<pitti> tepsipakki: oh, cool
<tepsipakki> for a week now
<Hobbsee> heya jsgotangco!
<ogra> sladen, did you merge the seeds with edubuntu after your NM change to ubuntu-meta
<ogra> ?
* ogra looks himself ...
<ogra> Riddell, the ubuntu seeds look wierd, what is rev 935 about ? ("Merge with Ubuntu" but not further note)
<Riddell> ogra: err, I messed up, hang on
<ogra> looks like a kubuntu entry ... :)
<Riddell> yes, it should have been
<Riddell> ogra: the -debug change reverted
<kwwii> anyone know which package this bug should correctly be assigned against? #17561
<Mithrandir> kwwii: xserver-xorg-video-nv, I'd guess
<kwwii> Mithrandir: thanks :-)
<pitti> _ion: hm, may it be that the 'bc03' matching algorithm is buggy somehow? (bug 101883)
<pitti> _ion: also, since the device class consists of four digits, why do the bc* patterns only have two?
<Riddell> pitti: http://kubuntu.org/~jriddell/tmp/edgy-updates/
<Riddell> Seveas: ubotu seems not to be in #kubuntu
<Seveaz> Riddell, it's still connecting/join
<pitti> Riddell: hmm, can you please make the changelog SRU conformant? I. e. include the names of the testers, and the SRU bug number?
<Seveaz> bugtracker is dead by the way, I'm fixing it but it may take a while
<pitti> Riddell: also, code changes relative to -proposed are not policy conformant
<Keybuk> siretart, Nafallo, keescook: how do you handle swap and md/lvm ?
<Riddell> pitti: how else could I do that meta-release-{,development} change?
<Riddell> Seveaz: thanks
<pitti> Riddell: ah, that's for preventing people from upgrading to feisty prematurely? I see
<Keybuk> (or anyone else who thinks that mounting a root filesystem should be "fun" :p)
<siretart> Keybuk: swap is on /dev/mapper/cswap, which is an encrypted swap space (key /dev/random) on /dev/md1 (mirrored raid)
<Keybuk> so you have raid-mirrored swap?
<pitti> Riddell: ok, except for the tester names, these look ok
<Keybuk> md1 being sda2 and sdb2 ?
<siretart> md1 being sd{a,b}5
<siretart> Keybuk: yes, swap is mirror, so my system doesn't lockup if a harddrive dies
<Keybuk> right
<Keybuk> so if I set the following up
<Keybuk> hmm
<Keybuk> actually, where is your /boot ?
<Keybuk> I assume grub can't read lvm-on-md ?
<siretart> no, /boot is on /dev/md1, which is mirrored on /dev/sd{a,b}2
<Keybuk> I thought you said swap was /dev/md1 ?
<siretart> no, /boot is on /dev/md0, which is mirrored on /dev/sd{a,b}2
<siretart> sorry, typo
<Keybuk> lol
<siretart> ;)
<Keybuk> what's sda,b 1?
<Keybuk> grub can read md then?
<siretart> NTFS partition, reserved for future use ;)
<Keybuk> ah
<Keybuk> so sda/b 6 is your lvm?
<siretart> Keybuk: grub doesn't need to deal with md. if the volume is mirror, grub doesn't really care, I think
<Keybuk> ok...
* siretart checks docs
<iwj> Well, yes, provided you tell grub the right drives etc.
<Keybuk>    Device Boot      Start         End      Blocks   Id  System
<Keybuk> /dev/sdb1               1          63      506016   fd  Linux RAID autodetect
<Keybuk> /dev/sdb2              64        1044     7879882+   5  Extended
<Keybuk> /dev/sdb5              64         126      506016   fd  Linux RAID autodetect
<Keybuk> /dev/sdb6             127        1044     7373803+  fd  Linux RAID autodetect
<Keybuk> so that would be similar?
<iwj> I'm pretty sure the default setup doesn't do that but my tests of md-based installs have all resulted in lilo.
<siretart> Keybuk: this looks pretty similar to my system
<siretart> Keybuk: in fact, I have two volume groups, one on a stripe (hades_stripe) and one on a mirrored raid device (hades_mirror)
<Keybuk> what's a stripe?
<Keybuk> ah, raid0
<siretart> Keybuk: stripe == raid level 0, data is striped on all members. improves disk access (speed)
<Keybuk> what do you do differently with them?
<siretart> I keep important data on the mirror, volatile data (chroots, checkouts) on stripe
<Keybuk> hmm, that gave me "/dev/sdb1 is too small: 0K"
<siretart> you're testing inside vmware?
<Keybuk> yes
<iwj> Keybuk: I had a similar problem with my new SATA disk, which was solved by updating to the latest feisty kernel.  I have no idea if it's related.
<_ion> pitti: bc is class, sc is subclass. A "0300" device would be equivalent to bc03sc00 in modalias format.
<pitti> _ion: ah, thanks
<pitti> _ion: so we need to fix sc* to sc00, I figure
<pitti> _ion: still, I don't see any PCI device in seb128's lspci output that would match 03*
<_ion> pitti: I'm not quite sure sc* should be changed. By default, the nvidia driver lists pci:v000010DEd*sv*sd*bc03sc02i00* and pci:v000010DEd*sv*sd*bc03sc00i00*
<iwj> siretart: Do you have a udevd --verbose --suppress-syslog output for your current booting problem ?  (lvm not triggered, you say)
<_ion> pitti: I posted a reply to the bug report.
<pitti> _ion: thanks
<_ion> seb128: 
<iwj> siretart: (thanks for your report last Friday night btw)
<siretart> iwj: not at hand, I can generate it this evening if you want
<iwj> siretart: Thanks.
<iwj> Though I really ought to think about this some more today to try to minimise the number of round trips of this kind.
<seb128> _ion: 37 lines, anything special you are looking for there?
<Nafallo> Keybuk: /dev/sd?1 is /dev/md0 is swap
<Nafallo> Keybuk: /dev/sd?2 is /dev/md1 is root
<Riddell> pitti: http://kubuntu.org/~jriddell/tmp/edgy-updates/  updated
<Nafallo> Keybuk: /dev/sd?3 is /dev/md2 is LVM
<iwj> Nafallo: You don't have a udev log from your boot which now fails just like siretarts, you say, do you ?
<Nafallo> iwj: http://home.nafallo.info/bugs/udev.txt
<_ion> seb128: If you don't mind, please paste the whole thing to the bug report, just in case i notice something important i'm not initially looking for.
<iwj> Nafallo: Oh, excellent.
<Nafallo> iwj: seemed straightforward that time though, broke premount and just did scripts/init-premount/udev :-)
<iwj> That's with the `watershed -i ... true' changed to -li I take it.
<Nafallo> yes
<iwj> Excellent.  Thanks.
* iwj looks
<ogra> can anyone explain to me why our nfs mode in initramfs-tools uses nfsmount and not mount (which is there in the initramfs anyway and supports all options /which nfsmount doesnt))
<seb128> _ion: done
* ogra curses over klibc-utils missing all the options ...
<iwj> Nafallo: Do I have a note somewhere of your raid/lvm setup ?
<Keybuk> ogra: I didn't think we had the full mount in the initramfs
<iwj> Oh, just a mo, does this udev.txt contain the second udevtrigger run too which you did to make it work ?
<iwj> Unfortunately these debug files don't have timestamps.
<Keybuk> I'm pretty sure mount comes from klibc too
<Nafallo> iwj: no, just scripts/init-premount/udev and then ctrl+d IIRC
<Mithrandir> dholbach: what is the plan for universe wrt release freeze?
<pitti> _ion: weird; there is just one bc03 in Seb's output, and that is the ATI card
<iwj> Nafallo: Hmm.  So which lvm didn't come up ?
<_ion> seb128: What does the following print? python -c 'from RestrictedManager.core import *; print connected_hardware(load_restricted_list())'
<iwj> run_program: '/lib/udev/watershed' (stdout) '  8 logical volume(s) in volume group "root" now active'
<seb128> _ion: set([] )
<Nafallo> iwj: this time none of them. and I don't think I got the annoying message :-)
<_ion> seb128: Hmm... How about python -c 'from RestrictedManager.core import *; print connected_hardware(load_restricted_list(True))'
* Nafallo checks if he can find it
<pitti> _ion: set(['vmnet', 'vmmon', 'nvidia'] ) for me in both cases; that looks right
<seb128> _ion: him
<seb128> hum
<seb128>   File "/usr/lib/python2.5/site-packages/RestrictedManager/core.py", line 231, in save_restricted_list
<seb128>     print >>restricted_file, module + " " + " ".join(alias_patterns)
<seb128> IOError: [Errno 28]  No space left on device
* seb128 makes space
<seb128> $ python -c 'from RestrictedManager.core import *; print connected_hardware(load_restricted_list(True))'
<seb128> set(['fglrx'] )
<_ion> Ok, it probably saved a b0rked cache file, and then made the decision based on it.
<_ion> Does restricted-manager -C work now?
<seb128> yes
<_ion> Alright.
<seb128> funny bug ;)
<pitti> _ion: so that seems to sort out itself when the modaliases are moved to l-r-m
<iwj> Nafallo: So what made you say the lvm didn't come up ?  Or perhaps it only doesn't work if you do a normal uninterrupted boot (which would be about typical ...)
<_ion> As it had *no* patterns for either nvidia or fglrx in the cache file, it assumed it's better just to show the hardware as a choice in the list. In the case of -C, the same code decided the driver should be installed, which might not be exactly what we want...
<_ion> pitti: But yeah, that will sort it out.
<_ion> s/hardware/driver/
<Keybuk> iwj: so, my investigation so far seems to say that there is an unknown time period between (ADD /block/md*) and the array being useful enough to run things like vol_id on
<pitti> _ion: hmm, wouldn't that also hit people who uninstalled l-r-m? it doesn't seem to do this in that case
<_ion> pitti: I think r-m should specifically check that l-r-m is installed, and offer to install it if it isn't.
<pitti> _ion: it does that now on interactive startup
<iwj> Keybuk: Right but IIRC what I told Nafallo and siretart to do included the strange blocking PROGRAM= call which ought to make vol_id start only after mdadm has finished.
<pitti> but not with -C
<_ion> pitti: Perhaps it should print an error message and exit, if it's called with -C and l-r-m isn't installed.
<pitti> _ion: right, I agree; that won't prevent that funny broken cache behaviour, though
<_ion> pitti: The save_restricted_list exception handling probably should let the exception propagate forward if there was an error *during* the write operation, but ignore the error if it occurred during the file was being opened for writing.
<iwj> Keybuk: And indeed I can see evidence of it in Nafallo's udev.txt.
<Keybuk> iwj: then it gets "unknown volume type"
<Keybuk> run_program: 'watershed -li udev-mdadm true'
<Keybuk> run_program: '/lib/udev/watershed' returned with status 0
<Keybuk> run_program: 'vol_id --export /dev/.tmp-9-2'
<Keybuk> run_program: '/lib/udev/vol_id' (stderr) '/dev/.tmp-9-2: unknown volume type'
<Keybuk> run_program: '/lib/udev/vol_id' returned with status 4
<pitti> _ion: oh, right, in this case l-r-m modaliases won't help us
<bddebian> Heya folks
<Keybuk> because the md has been added, but no drives yet added to it
<Keybuk> md* get created whenever you run mdadm for the first time and vaguely go near that device
<Keybuk> ADD /block/md0 doesn't mean md0 is ready
<iwj> Keybuk: Yes, that's expected.  But you get a change later, right ?
<Keybuk> it means you have at least one block device of the set now
<Keybuk> no
<iwj> Oh, FFS.
<Keybuk> you don't get a CHANGE with current kernels
<Keybuk> that's the problem I was talking about on friday
<Keybuk> that's the patch we're waiting for
<iwj> I don't want to try to fix this in the kernel.  Just more different versions of crack.
<Keybuk> BenC: ping
<iwj> The trick perhaps is to remove all non-active md's in the local-top/mdadm script ?
<Keybuk> I'm not sure that'll help?
<Keybuk> the kernel still seems to know about it
<iwj> If we remove the device when it's dead then when local-top/mdadm finally decides to activate it it will ... 
<iwj> ... damn.
<Keybuk> there doesn't seem to be a kill-the-md-and-forget-about-it except rmmod
<Keybuk> just "stop"
<Nafallo> iwj: found the log from my tests. when I runned it without break=premount it stopped with this:
<iwj> And after it's created you get nothing.
<Nafallo>   mdadm: No devices listed in conf file were found.
<Nafallo>   Failure: failed to assemble all arrays.
<Keybuk> (you certainly don't get a remove caused by stop)
<Keybuk> quest md% grep kobject_uevent md.c
<Keybuk>         kobject_uevent(&mddev->gendisk->kobj, KOBJ_CHANGE);
<Keybuk> hmm
<Keybuk> that's interesting
<Keybuk> the kernel code does call change
<iwj> Keybuk: If you're right there are three answers: 1. kernel patch you mention to produce change on change; 2. make mdadm synthesize a udev event somehow; 3. make the mdadm bootup script never attempt to assemble arrays which aren't completely ready by replicating all of the logic in mdadm.
<iwj> Oh and  4. make a special test mode for mdadm which doesn't actually create the device.
<iwj> If it segfaults you know you can run it for real :-).
* Nafallo won't reboot until he has a backup client running though.
<Keybuk> ok, well, in theory, if I reboot this vmware image, I now have a root md-on-lvm just like siretart's set up
<iwj> Keybuk: Just a mo.
<iwj> No, never mind.
<iwj> Keybuk: I have one here and obviously it WFM.
<Keybuk> iwj: I haven't got any thoughts yet :-/
<iwj> If I knew where to put sleeps ...
<Keybuk> putting a sleep in the udev rules for md devices cures the problem
<Keybuk> loooong sleep :p
<iwj> Keybuk: Oh, that's probably coincidence.  Something else makes vgscan run and then you're fine.
<iwj> Let me get my own log and see if I can see the change I'm expecting.
<iwj> This machine has a usb stick as half of the root mirror so it ought to demonstrate the race if it's just the lack of this change event.
<iwj> Of course it doesn't but maybe the log will tell me something.
<Keybuk> hmm, that didn't work to boot
<Keybuk> it couldn't find the kernel
<iwj> I don't think that's relevant.  I hope ...
* Keybuk takes "/boot" off the parameters
<ogra> Keybuk, well, mount supports a lot more options ... like proto=tcp/udp for nfs ....
<ogra> and i think nfsmount is only a sylink to klibc-munt
<ogra> *mount
<ogra> but i might be wrong here 
<Keybuk> iwj: I'm trying a test
<iwj> Keybuk: I'm definitely getting some kind of event relating to md0 when my md0 changes from   mdadm: /dev/md0 assembled from 1 drive (out of 2), but not started  to  /dev/md0 has been started with 2 drives
<iwj> It then runs vol_id and gets the right answers.
<Keybuk> what event?
<iwj> It's a bit hard to tell what with all the usb noise.
<iwj> udev_event_run: seq 1631 forked, pid [2877] , 'change' 'block', 0 seconds old  I think.
<iwj> Err, these seqs are sequence numbers, right ?  Why do I see the same one more than once ?
<iwj> root@samual13:~# grep 'seq 1631 forked' /root/ul  | wc -l
<iwj> 22
<iwj> But I'm sure this event is happening because I see
<iwj> udev_node_add: creating device node '/dev/md0', major = '9', minor = '0', mode = '0660', uid = '0', gid = '0'
<iwj> and then it runs vgscan.
<iwj> Perhaps the device isn't useable even immediately after mdadm returns although you would have expected someone else to notice that.
<iwj> Nafallo, siretart: I really need that failing udev log I think which an explanation of why you think the log is of a failing run :-).  (See my previous request for info, as I sent to the bug on Friday ...)
<iwj> s/which/with
<ogra> mdz, !!!
<ogra> mdz, WELCOME TO EUROPE !!!!!
<ogra> :D
<mdz> hi
<Keybuk> iwj: multiple things forked for the same event?
<iwj> Keybuk: Oh, IC, like that.
<iwj> Anyway, it's clear that I do get an event which looks like a change.
<Keybuk> yeah
<Keybuk> looking for that now
<Keybuk> (I stuck udevmonitor in the initramfs)
<Keybuk> MD/LVM-lovers
<Keybuk> how do you persuade GRUB that your /dev/md0 is actually /boot and not / ?
<Keybuk> or do you lie to it, and just use / ?
<Nafallo> Keybuk: my /dev/md1 is / :-)
<Nafallo> plan to change that in the future though :-)
<Keybuk> Nafallo: where's your /boot then?
<mdz> Keybuk: I think making a symlink boot -> . is the traditional hack
<Nafallo> Keybuk: on / :-)
<Keybuk> Nafallo: oh, you literally fill your / with kernel images and have a /grub ?
<wasabi_> Wait what's up with this?
<Nafallo> Keybuk: no, I have a / with a /boot and everything else that's usually on / :-)
<wasabi_> --root-device on grub-install
<Keybuk> wasabi: yeah, but then grub doesn't know where /boot is?
<wasabi_> or root (the md partition)
<Keybuk> if my root is LVM-on-MD, grub can't read that, so cannae find kernels
<wasabi_> Shouldn't care...
<Keybuk> it needs to load the kernel? :p
<wasabi_> pop open teh grub console...   root(partiton of /boot)     setup (real drive)
<wasabi_> repeat for each drive.
<Keybuk> yeah, but then you have to put kernel /vmlinuz... and initrd /initrd.img...
<wasabi_> in /boot, yes.
<Keybuk> which update-grub cheerfully overwrites with /boot/...
<wasabi_> But you've told it what partition.
<Keybuk> you're not understanding me
<wasabi_> guess not. ;0
<Keybuk> update-grub writes me entries that look like this:
<Keybuk>   root     (hd0,0)
<Keybuk>   kernel   /boot/vmlinuz-2.6.20-13-generic root=UUID=...
<wasabi_> Oh, that's groot in meny.lst
<wasabi_> Oh with the /boot in front of it.
<Keybuk>   initrd   /boot/initrd.img-2.6.20-13-generic
<wasabi_> hmm mine isn't doing that.
<Keybuk> the problem is that hd0,0 is /boot
<Keybuk> so those need to be /vmlinuz and /initrd.img
<Keybuk> if I change it to hd0,6 (the real root) then it fails, because that's LVM-on-MD
<Keybuk> and doesn't contain /boot anyway
<wasabi_> not sure. mine is just doing /kernel name
<wasabi_> looking around
<wasabi_> my groot is set to (hd0,0)
<Keybuk> groot?
<wasabi_> in menu.lst
<bddebian> :)
<Keybuk> what's a groot?
<Keybuk> oh, the option thingy
<wasabi_> The option grub uses to find it's own partition.
<wasabi_> I bet it uses that and realizes the kernels are in the same dir.
<wasabi_> maybe heh
<wasabi_> # directory's to look for the grub installation and the menu file
<wasabi_> grub_dirs="/boot/grub /boot/boot/grub"
<wasabi_> then i think it steps up one level to find the kernels.
<Keybuk> . o O { one day, there's going to be an accident, and mdadm and lvm2 are going to accidentally slip into universe }
<wasabi_> no no no. =(
<wasabi_> # figure out where grub looks for the kernels at boot time
<wasabi_> kernel_dir=/boot
<wasabi_> if [ -n "$boot_device" ]  ; then
<wasabi_>         kernel_dir=
<wasabi_> fi
<wasabi_> Hmm.
<wasabi_> That has something to do with it. :0
<Nafallo> Keybuk: . o O { ...and then Keybuk will have to move them back to main again ;-) }
<Keybuk> Nafallo: "have to" ? :p
<Nafallo> Keybuk: if you don't want to break users setups :-)
<Keybuk> Nafallo: does your setup work perfectly? :p
<Keybuk> (and it wouldn't result in things being uninstalled, after all)
<wasabi_> Mine is NEAR perfect.
<wasabi_> I'm missing only evms. ;0
<Keybuk> I'm just saying that we appear lack the skills, and the patience, to make this work :p
<Nafallo> Keybuk: it did pre-feisty ;-)
<wasabi_> Which I made sure to propose for feisty heh
<wasabi_> The udev stuff helped.
<wasabi_> watershed and all that
<Keybuk> actually, I'll be fair
<Keybuk> lvm seems to largely work
<Keybuk> it's mdadm that's causing problems
<Nafallo> agreed
<wasabi_> I still vote for discarding mdadm.
<wasabi_> And using evms. :0
<wasabi_> A single cohesive system that knows about all the moving pieces.
<Keybuk> wasabi: evms has the same problems ... it doesn't generate events to say that it's finished moving the pieces :p
<wasabi_> Fixable.
<Keybuk> you get an "I'm going to make a move sometime soon" event
<Keybuk> wasabi: by whom?
<wasabi_> The same guy who would potentially fix mdadm. :0
<wasabi_> (you)
<Keybuk> and who is that? :p
<Keybuk> isn't me
<wasabi_> Do we not have a demand for these things yet? I mean, "raid" is a commodity these days.
<Keybuk> with any luck, someone with lots of mdadm, evms and LVM experience will apply for one of those open Ubuntu Server Developer positions
<Keybuk> (planet-sized-hint :p)
<wasabi_> Heh.
<Nafallo> LOL
<Nafallo> must be Win2K serial :-)
<iwj> Keybuk: My setup works perfectly :-).  But I'm using lilo which is what the dapper installer gives you.
<iwj> I think lilo uses fancy kernel ioctls to find out where the real data is.
<iwj> Presumably it only reads from the first half of a mirror.
<wasabi_> I dunno, my grub has been working perfectly.
<wasabi_> It writes entries without /boot in front of them
<Keybuk> randomly, GRUB has started behaving as wasabi says now
<Keybuk> it must have not liked me having the old disk partially around
<wasabi_> Oh, it's working?
<Keybuk> apparently
<Keybuk> last update-grub removed /boot from the front of everything
<wasabi_> What'd you change?
<Keybuk> it's still slightly kooky having grub peer at one half of a RAID-1, but it suffices
<Keybuk> wasabi: nothing
<wasabi_> Yeah, that's all you can do though.
<wasabi_> What we need is a grub that can try bios drives in order.
<wasabi_> Or some list there of.
<Nafallo> that would rock! :-)
<BenC> Keybuk: pong
<wasabi_> linuxbios actually seems to have stuff for this. Which is very slick.
<Keybuk> BenC: unping
<wasabi_> So any drive can fail, and it can still boot.
<iwj> wasabi_: If your BIOS doesn't do raid then are you hoping it will boot of your second disk ?
<iwj> s/ of / off /
<wasabi_> iwj: Yes.
<iwj> I haven't tried that I have to admit.  I suppose it probably even works with SATA ...
<wasabi_> iwj: It depends on your bios.
<wasabi_> Most crappy one will just hang.
<wasabi_> Some of the intel server boards I've used will actually try the next drive.
<wasabi_> Which works wonderfully.
<Keybuk> SATA scares me
<wasabi_> Probably also depends on how the drive dies.
<Keybuk> it randomly reordered my drives because I added a new one
<wasabi_> Yeah, but we're not supposed to care about that naymore.
<wasabi_> With evms and uuids and stuff.
<wasabi_> Another solution is to grab a flash ROM and put that in there. ;)
<Keybuk> grub still cares which one hd0 is, no?
<wasabi_> Yup. Grub does.
<wasabi_> Actually, I guess I'm not totally sure how it deals with that. The BIOS grabs stage0 or something, then that loads stage1? And I'm not sure how stage0 finds stage1.
<Keybuk> iwj: oh, now this is a random failure
<Keybuk> raids are assembled
<Keybuk> lvm has been activated
<Keybuk> but no uuid
<wasabi_> so what do you mean about evms? It doesn't emit events for stuff in /dev/evms?
<Keybuk> wasabi: I haven't even looked at evms yet
<Keybuk> I'm still stuck on mdadm
<wasabi_> heh.
<poningru> [11:56:11]  <Keybuk> SATA scares me <--- that statement scares me to no avail
* poningru ducks
<dholbach> Mithrandir: what do you think about bug 98525?
<seb128> Mithrandir: could you have a look on https://bugs.launchpad.net/ubuntu/+source/rhythmbox/+bug/101953 also?
<iwj> Keybuk: Freaky.
<iwj> You've got lvm-on-raid ?
<Keybuk> iwj: yeah
<iwj> SATA is great.  You too can confuse your boot device with a camera.
<Keybuk> iwj: ?  shouldn't; BIOS normally offers boot from removable/USB storage separately than SATA
<iwj> Keybuk: The lack of uid is a bit odd but normally you wouldn't expect a uuid link for an lvm volume.
<iwj> Keybuk: Yes, the bios knows but the modern Linux approach makes it a bit harder.
<iwj> mkfs.msdos /dev/sdb2
<iwj> oops!
<iwj> and other amusements.
<Keybuk> how would you name them to avoid that?
<Keybuk> by path?
<ogra> BenC, https://launchpad.net/ubuntu/+source/ltsp/+bug/97456 do you think its possible we can sit down together at UDS and talk about a -ltsp kernel flavor (i'm willing to take over maintenance/responsibility for the config)? 
<BenC> ogra: Sure
<iwj> Keybuk: Something like that.  Part of the problem is homogenisation of the device names.  If the USB drives were /dev/usbda1 or something (udev could tell from the path) then it would be much less confusing.
<Keybuk> iwj: it's certainly doable
<Keybuk> SUBSYSTEM=="block", SUBSYSTEMS=="usb", NAME="usbd%n"
<Keybuk> type thing
<iwj> Right.
<iwj> Not sure what to do to make SATA drive naming more stable.  (As stable as scsi used to be would be fine ...)
<ogra> BenC, seems the feisty kernel needs minutes instead of secods to boot on certain HW
<Keybuk> SATA is stable
<iwj> Keybuk: What, different drives on different controllers are always numbered in the same order ?
<Keybuk> the single kernel storage device layer is the bit that isn't stable, since drives get assigned a letter in the order they request it
<iwj> Keybuk: So anyway re your booting problem.  You say you have no uuid but why is that a problem ?
<Keybuk> that was never stable for SCSI
<iwj> Keybuk: In practice it was stable for scsi.
<iwj> Anyway, this is a very old argument :-).
<Keybuk> sure, -v will'#s patches
<Keybuk> and in practice, it's equally stable for SATA
<Keybuk> the problem is that SCSI, SATA and USB are all vying for the same enumerated namespace
<iwj> Keybuk: That's part of it, yes.
<Keybuk> and tbh, it just exposed a problem that was always there
<Keybuk> dicking around with cables could always change the order
<iwj> I tend to think removeable devices should be named by path.  So usb stuff would be named by the port you put it in.
<iwj> dicking> very true.
<Keybuk> so kinda like /dev/disk/by-path then?
<iwj> Keybuk: Yes, only less crazy.
<Keybuk> iwj: *shrug*
<Keybuk> it's not that crazy
<iwj> I mean, more friendly.
<Keybuk> people actually do care which pci controller it turned up on
<iwj> Yes, yes, but normal people want to know which usb stick is the one in the top hole.
<Keybuk> sure
<Keybuk> and this lets you do that, no?
<iwj> So you should number the holes sequentially.
<iwj> Like it used to be with disks and floppies.
<Keybuk> pci-0000:00:02.1-usb-0:7:1.0-scsi-0:0:0:0@
<iwj> It doesn't matter if the top hole turns out to be called 4 and the bottom one 3 provided it stays that way.
<iwj> Keybuk: Nice string for the user's desktop.
<Keybuk> first usb device in hole 7 on the second hub of the internal USB controller
<iwj> That 7 doesn't necessarily correspond to a hole.
<Keybuk> and that's a device name in /dev, that never shows up on the user's desktop
<iwj> And most of the numbers there are useless.  Anyway, let's talk about this in a bar sometime.
<Keybuk> HAL icons show up on the users desktop
<iwj> I'm trying to talk to you to debug mdadm :-).
<Keybuk> and those have a pretty picture that looks kinda like what you plugged in, and describe it
<Keybuk> in my case "1GB disgo flash device"
<Keybuk> right
<Keybuk> so
<Keybuk> err
<Keybuk> what I've got, consistently is
<Keybuk> /dev/md0..2 fired up, both drives active, etc.
<Keybuk> /dev/mapper filled out, with /dev/ubuntuvg containing both things
<Keybuk> but nothing in /dev/disk/by-uuid
<iwj> Right.
<iwj> That's correct.
<iwj> Why do you need /dev/disk/by-uuid ?
<Keybuk> no, I should have the UUIDs of the filesystems on the LVM LVs
<iwj> Last time we had this conversation you said `no, we should be using the lv names'.
<Keybuk> sure
<Keybuk> but then I thought about it a bit more
<iwj> Ah.
<Keybuk> and realised that if that didn't work, it meant there was a race somewhere
<Keybuk> which would be mad for trying to mount it anyway
<iwj> I think it is more correct to use the name because if you re-mkfs the lv then you still wanted mounted the same way.
<Keybuk> so may as well turn on uuid-for-dm and see what happens
<iwj> IC
<Keybuk> sure, I'm making a pathological test case though
<Nafallo> Keybuk: feisty+1 please :-)
<Keybuk> tower-of-hanoi of drives
<iwj> Keybuk: OK.  I have lvm-on-md-on-(lvm-on-usb)+(lvm-on-ide)
<iwj> But the crazier the better.
<iwj> Anyway, your 65-persistent-storage.rules, does it run vol_id and persistent_storage_path_uuid stuff for dm-* change ?
<iwj> The one I have here seems to although the LABELs are misnamed.
<Keybuk> yes
<iwj> So it runs vgchange and then after that has finished it runs vol_id but vol_id fails ?
<iwj> vgchange> I mean this command:  watershed sh -c '/sbin/lvm vgscan; /sbin/lvm vgchange -a y'
<Keybuk> interesting, running udevtrigger causes the uuids to show up
<Keybuk> so definite race
<Keybuk> but between _what_ ?
<Mithrandir> dholbach: 98525 looks good to me
<iwj> Yes, running udevtrigger fixes most things in this area :-).
<dholbach> Mithrandir: gracias
<iwj> There are practically no bugs but races.
<Keybuk> iwj: an evil hacky solution occurs to just stick a once-a-second udevtrigger into the "Waiting for root filesystem" loop
<iwj> OMG WTF BBQ
<Keybuk> assuming we don't find the (ahem) root of the problem
<j1mc> anyone know when the herd6 candidates will be announced?  i'd like to coordinate for xubuntu testing.  thanks.
<iwj> You know I'm almost tempted to say `do it anyway'.
<ogra> BenC, also, will all debugging flags get switched off in the fial kernel image ? 
<ogra> *final
<siretart> Keybuk: I can confirm this behavior. udevtrigger virtually always fixes things for me, but only when called manually. putting it into the boot script didn't :/
<iwj> Turn it off again for the early feisty+1's to give us a chance to find more bugs.
<Mithrandir> seb128: rhythmbox > go for it.
<Keybuk> udevtrigger is cheap, it just tickles the kernel
<seb128> Mithrandir: thank you
<ogra> j1mc, afaik we wont do herd6
<iwj> Keybuk: Every 1s would probably be too often though; some of these things seem to take more than 1s to do and it might get tangled up with itself.
<Mithrandir> j1mc: oh, thanks for reminding me, I'll send a mail to u-d-a saying we won't have them.
<Keybuk> which, since it can only repeat uevents that have already happened, implies that an event happens too early to be useful
<iwj> Keybuk: It makes udevd repeat all the processing some of which is quite slow.
<Keybuk> yeah
<Keybuk> udev sulks if it receives too many events
<siretart> on my system (amd64 3000+, it takes about 3 seks for udevtrigger to settle down)
<iwj> Keybuk: So do you have a udevd --verbose --suppress-syslog >>something  for your symptoms ?
<j1mc> Mithrandir: thanks.  we'll just have the single RC release then?
<ogra> siretart, get an amd64 6000+, then it will only take 1.5 :P
<Keybuk> well
<iwj> Keybuk: Maybe we should have an optional boot arg  `udevtrigger_repeat_interval'  which defaults to 0 meaning turned off.
<Keybuk> the good news is that we *do* get a CHANGE /block/md0
<iwj> Keybuk: Yes, I get one too.
<Mithrandir> j1mc: yes.
<Keybuk> UDEV  [1175529927.085968]  change   /block/md0 (block)
<Keybuk> UDEV_LOG=6
<Keybuk> ACTION=change
<Keybuk> DEVPATH=/block/md0
<Keybuk> SUBSYSTEM=block
<Keybuk> SEQNUM=1596
<Keybuk> MINOR=0
<Keybuk> MAJOR=9
<Keybuk> UDEVD_EVENT=1
<Keybuk> DEVNAME=/dev/md0
<iwj> So that's supposed to run    watershed sh -c '/sbin/lvm vgscan; /sbin/lvm vgchange -a y'
<iwj> which evidently works.
<Keybuk> and the result of the change is that the dm-* appear
<Keybuk> oh, d'oh, vol_id isn't run for change because I forgot about the silly udev != | bug
<j1mc> Mithrandir: ogra: thanks.  :)
<iwj> Keybuk: Oh, that'll be it.
<iwj> Doesn't happen for me because my rules look different.
<iwj> We're still in the dark about Nafallo and siretart's systems though.
<keescook> Keybuk: did you get what you needed wrt swap-on-md?  (It looks like you did from the irc log)
<Nafallo> iwj: I'm fine if you fix your systems first ;-)
<iwj> Nafallo: Mine works just fine, as I say.  If only it would break like yours that would be lovely ...
<Keybuk> keescook: yeah, I have that working
<Keybuk> iwj: given change, I really don't think we need the extra watershed -l bit ?
<keescook> Keybuk: anything I can help with atm?
<Nafallo> iwj: hmm. nothing could have made it break because the computer was installed a long time ago? warty or so... ;-)
<iwj> Keybuk: Well, you can take it out if you like but I'm mistrustful.
<iwj> It's definitely harmless (I think) and we don't understand mdadm well enough to be sure it's not needed.
<iwj> And of course we can't prove it's not needed without fully analysing mdadm.
<iwj> Nafallo: My test install is from dapper.  It might make a difference but the right approach is to try to collect debugging data etc. so we can try to understand your system's failure.
<Nafallo> iwj: ofcourse :-)
<iwj> I don't think I read through what was in your initramfs udev rules but I assume it's similar to siretart's which I did eyeball.
<Keybuk> ok, now if I do (from break=premount), /scripts/init-premount/udev
<Nafallo> as soon as I have a backupclient online and working I can try some more reboots :-)
<Keybuk> after a few seconds, my three MD and two LVs are both assembled
<Keybuk> and UUIDs are available for all of them
<Nafallo> Keybuk: kewl! :-)
<Keybuk> so I can do mount-by-uuid for LVM-on-MD
<iwj> Keybuk: Congratulations on failing to reproduce the bug :-).
<Keybuk> actually probe-for-root-fs (since that's the root= one)
<Keybuk> and that's before scripts/local-top/mdrun or scripts/local-top/mdadm are even called
<Keybuk> so, err, what do those do?
<iwj> .../mdrun is a fossil and exits because .../mdadm exists.
<iwj> .../mdadm is the thing run from udev.
<Keybuk> right, but does initramfs need to run it as well?
<Keybuk> I guess it doesn't hurt, but it's worth remembering we might be able to take it away later
<iwj> It used to be called manually from init (and I think it still is) and I decided not to move it.
<iwj> Indeed. so.
<Keybuk> likewise for the two init scripts in the main boot sequence
<iwj> I didn't want to rename it since it was full of stuff I didn't want to understand too closely.
<Keybuk> we don't appear to need either the mdadm-raid or lvm init scripts either
<Keybuk> the only thing we do need to do is "understand" the mdadm initramfs script, and turn it into a /lib/udev/mdadm that we can use in both initramfs and the real filesystem
<Nafallo> do we need lvm-common to dep mdadm? :-)
<Keybuk> Nafallo: no
<Nafallo> Keybuk: you might want to change that then... ;-)
<Keybuk> already done
<Nafallo> kewl! :-)
<iwj> mdadm-raid is ebw.
<iwj> Keybuk: It's not clear to me what the right functionality for /lib/udev/mdadm is.  I don't like the security properties of all this automatic device scanning.  But I think I'm probably just doomed.
<Keybuk> ebw?
<pitti> seb128, dholbach, *: launchpad-crash-digger updated for new python-launchpad-bugs, so it now actually works again with new LP
<dholbach> nice
<seb128> pitti: rock on
<iwj> Evil, Bad and Wrong.
<pitti> Mithrandir: yay, https://launchpad.net/ubuntu/+milestone/ubuntu-7.04 finally sorts correctly after 'Status'; I guess that makes you really happy :)
<pitti> Mithrandir: if only it would ignore duplicates...
<seb128> doko, pitti: do you remember what component has the bug ctrl-left,right doesn't work on a command line? bash? readline?
<seb128> pitti: I do reject duplicates ;)
<pitti> seb128: I never knew, I think
<seb128> ok
<pitti> just that it is really annoying :/
<seb128> pitti: do you know if there is a bug open or if that was only mentionned on IRC?
<seb128> there was one on gnome-terminal which is wrong
* pitti is clueless this evening
<seb128> I reassigning to bash, not sure though
<seb128> Mithrandir: do you have an opinion on whether "dcraw" should be added to desktop or ship or somewhere else?
<Mithrandir> seb128: for f-spot?  -desktop, then.
<seb128> Mithrandir: yes, ok, thank you
<mvo> cjwatson_: could it cause any problems if I change ubuntu-meta so that the Section is "metapackages" instead of "base"? this should fix bug #82876
<ubotu> Malone bug 82876 in apt "Synaptic wants to reinstall all recomended packages on upgrade" [Undecided,Confirmed]  https://launchpad.net/bugs/82876
<Mithrandir> mvo: apart from the fact that you need it changed in the archive? :-P
<mvo> Mithrandir: its overwritten for the Packages files already (if that is what you mean)
<Mithrandir> mvo: the overrides in the archive would be where it would actually be changed, what's in the package is just advisory.
<mvo> Mithrandir: right. but whats in the package goes into /var/lib/dpkg/status and I want the Section: metapackages there :) 
<mvo> Mithrandir: so that even if the archive is not available (or the version in the archive) the section is correct. apt is currently doing some magic (recommends, auto-install) for section. metapackages
<mvo> Mithrandir: I just want to be sure that it does not break any assumptions somewhere else (soyuz, germinate etc)
<Mithrandir> ogra: can you respond to svu on 97342, please?
* ogra looks
<ogra> oh, indeed
<siretart> iwj: do you have anything to test for me?
* siretart finally @home
<ogra> siretart, there were two uploads on -changes ....
* siretart checks
<siretart> mmh. shall I dare to break^Wupgrade my system? ;)
<ogra> you have a fallback laptop, dont you ? ;)
<siretart> I do :)
<desrt> so
<desrt> launchpad got bling
<desrt> looks nice :)
<siretart> hm. I see uploads of lvm, mdadm and udev, but I only see the udev binaries in the archive. hmm
<siretart> desrt: launchpad got bling?
<siretart> oh, finally the beta phase ended! \o/
<siretart> ok. first try with Keybuks packages: success. let's try another boot.
<siretart> 2nd boot as well. w00t! \o/ :)
<ajmitch> morning
<Burgwork> morning ajmitch
<ajmitch> Burgwork: you mentioned something about zope earlier?
<Burgwork> yep, poor fedora people are still struggling with the python2.4 issue
<ajmitch> ah
<da_man_2007> hi,,does the crash handler code really help ?
<da_man_2007> I have direct reason for asking so bear with me
<boitono> I recently upgraded a server from dapper to edgy and one of the packages we rely on, otrs, was downgraded from 2.0.4 to 1.33~.  I found that otrs 1.33~ was added to the edgy repository and took the name otrs and otrs 2.0.4 was renamed otrs2. Why did this happen? Can anyone give me some more info?
<KnowledgEngineer> hello
<KnowledgEngineer> make menuconfig return a strange output
<KnowledgEngineer> http://rafb.net/p/PaU1bK89.html
<KnowledgEngineer> someone can help me please?
<KnowledgEngineer> i need just to change the timer frequency 
<KnowledgEngineer> and recompile the kernel
<LeeJunFan> KnowledgEngineer: you need ncursed-dev
<LeeJunFan> libncurses5-dev
<LeeJunFan> really not a question for the devel channel though.
<KnowledgEngineer> tks
<KnowledgEngineer> for low latency kernel i must change the timer frequncy from 250 to 1000 or form 250 to 100
<KnowledgEngineer> Hz
<Mithrandir> uh, why not just install the low-latency kernel from universe?
<KnowledgEngineer> a good
<KnowledgEngineer> the rest of configuration is the same of default ubuntu kernel ?
<Mithrandir> should be
<Nafallo> no
<Nafallo> something with PREMPT aswell :-)
<KnowledgEngineer> i need enable preempt
<KnowledgEngineer> in what submenu is preempt ?
<LeeJunFan> KnowledgEngineer: not if you install the low-latency kernel.
<Nafallo> KnowledgEngineer: as Mith said, just install it from universe :-)
<KnowledgEngineer> i prefer do not install the low latency kernel if i'm not totally sure that the rest of configuration is the same of current kernel that i'm using
<Nafallo> KnowledgEngineer: the only changes are HZ and PREEMPT AFAIK
<Nafallo> KnowledgEngineer: just try it and see if it works?
<KnowledgEngineer> ok
<KnowledgEngineer> apt-get install what ??
<Nafallo> linux-image-2.6.20-13-lowlatency
<Nafallo> or linux-image-lowlatency to be up-to-date
<Lure_> KnowledgEngineer: these are all the changes between generic and lowlatency: http://git.kernel.org/?p=linux/kernel/git/bcollins/ubuntu-2.6.git;a=blob_plain;f=debian/config/lowlatency.config;hb=HEAD
<KnowledgEngineer> Nafallo, apt do not find linux-image-lowlatency
<KnowledgEngineer> source.list
<KnowledgEngineer> deb http://archive.ubuntu.com/ubuntu/ edgy universe main multiverse restricted
<Mithrandir> it's only in feisty.
<KnowledgEngineer> deb http://archive.ubuntu.com/ubuntu/ edgy-updates universe main multiverse restricted
<KnowledgEngineer> and other ....
<Mithrandir> doko: why is glibc built with -g1 and not just -g?
<KnowledgEngineer> 1) ( ) No Forced Preemption (Server)
<KnowledgEngineer> 2) ( ) Voluntary Kernel Preemption (Desktop)
<KnowledgEngineer> 3) ( ) Preemptible Kernel (Low-Latency Desktop)
<KnowledgEngineer> what of this option i need to select?
<KnowledgEngineer> aaa 3
<Mithrandir> KnowledgEngineer: this channel is not for support; try #ubuntu
<mjg59> pochu: New liferea crashes whenever I try to view the original post
<mjg59> pochu: That is, whenever I click on the subject line to spawn the viewer
<pochu> mjg59: actually updating it
<mjg59> pochu: Score :)
<pochu> mjg59: there is a new release (5 minutes ago)
<pochu> mjg59: and there are already 5 bugs about it ;)
<mjg59> Ha, excellent
<pochu> mjg59: are you in the release team?
<mjg59> Nope
<pochu> ok, np
<tbf> hi, notification-daemon 0.3.6 seriously leaks X11 windows
<tbf> each notification leaves two root windows behind
* tbf visits launchpad
#ubuntu-devel 2007-04-03
<tbf> https://bugs.launchpad.net/ubuntu/+source/notification-daemon/+bug/102128
<ubotu> Malone bug 102128 in notification-daemon "Notification daemon leaks X11 windows" [Undecided,Unconfirmed]  
<pochu> mjg59: still there? can you test 1.2.10c-0ubuntu1?
<pochu> mjg59: bug 102114, if you're interested :)
<ubotu> Malone bug 102114 in liferea "[UVFe]  Liferea 1.2.10c" [Undecided,Unconfirmed]  https://launchpad.net/bugs/102114
<mjg59> pochu: Sure - in the archive, or elsewhere?
<pochu> mjg59: do you have i386?
<pochu> if you want a .deb, you have it here: http://emilio.pozuelo.org/deb/ (built in pbuilder)
<pochu> mjg59: otherwise, bug 102114
<ubotu> Malone bug 102114 in liferea "[UVFe]  Liferea 1.2.10c" [Undecided,Unconfirmed]  https://launchpad.net/bugs/102114
<pochu> :)
<mjg59> pochu: Not much good without liferea-mozilla.deb as well :)
<pochu> LoL
<pochu> hehe
<pochu> one sec :)
<pochu> mjg59: refresh please :)
<KnowledgEngineer> hello
<KnowledgEngineer> is possible install ubuntu in a Macintosh
<KnowledgEngineer> ??
<mjg59> KnowledgEngineer: Please ask support questions in #ubuntu
<mjg59> pochu: Works fine!
<pochu> mjg59: cool! feel free to comment in bug 102114 :)
<ubotu> Malone bug 102114 in liferea "[UVFe]  Liferea 1.2.10c" [Undecided,Unconfirmed]  https://launchpad.net/bugs/102114
<fabbione> morning guys
<ajmitch> hi fabbione 
<fabbione> yo
<manchicken_> Anybody got any clue why libmjs-dev conflicts with firefox, libnss3, and evolution among others?
<manchicken_> libmjs0 didn't...
<bluefoxicy> huh
<bluefoxicy> does nmap fall under debian notfree?
<bluefoxicy> it is licensed under the GPL
<crimsun> no, it's in main.
<bluefoxicy> however, its license considers any program that executes nmap and parses (not displays raw) the results as a "derivative work"
<Treenaks> bluefoxicy: which then should be GPL too
<bluefoxicy> and if the program reads nmap-os-fingerprints or nmap-service-probe files, it's a "derivative work" as well
<bluefoxicy> (i.e. if it looks for installed nmap and reads the contents of those files)
<desrt> the GPL supports neither of those claims
<bluefoxicy> Treenaks:  so if I run, say, 'ls' and run the result through 'cut' and display an aggregate of ownership of files (who owns how many), that program has to be GPL because it's a derivative work of ls and cut?
<bluefoxicy> desrt:  man nmap and go down to line 1635
<desrt> not installed :p
<bluefoxicy> are you nuts?
<Treenaks> bluefoxicy: Real Men use telnet + seq ;)
<desrt> vrms complained so i removed it
<bluefoxicy> vrms?
<Treenaks> bluefoxicy: apt-cache show vrms
<desrt> are you nuts?
<bluefoxicy> wow, that's horriffic.
<desrt> bluefoxicy; nmap's claims are almost definitely bogus
<bluefoxicy> desrt:  it's part of the license
<desrt> no.  it's not.
<desrt> This program is free software; you may redistribute and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; Version 2.
<desrt> i am therefore licensed to do anything authorised by the GPL
<bluefoxicy>   Nmap Copyright and Licensing
<bluefoxicy>        The Nmap Security Scanner is (C) 1996-2005 Insecure.Com LLC. Nmap is also a registered trademark of Insecure.Com
<bluefoxicy>        LLC. This program is free software; you may redistribute and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; Version 2.
<desrt> the person owning the copyright doesn't matter.  they grant certain rights by distributing under GPL.
<bluefoxicy> Note that the GPL places important restrictions on derived works, yet it does not provide a detailed definition of that term. To avoid misunderstandings, we consider an application to constitute a derivative work for the purpose of this license if it does any of the following:
<bluefoxicy> <insert random rules here>
<bluefoxicy> desrt: amap is no longer available in Ubuntu because it's GPL + you're not allowed to use it to hack into peoples' machines illegally.
<desrt> oh.  by the way:  i consider an application a derived work if it was written by a person who has ever talked to me on IRC.
<desrt> ...
<bluefoxicy> desrt:  oh plus you have to mention the name and version etc if you distribute commercially.
<bluefoxicy> http://www.thc.org/thc-amap/ under disclaimer.
* desrt yawns
<desrt> GPL is GPL.  these claims are meaningless.
<desrt> under GPL, for example, you can choose to redistribute without this manpage.
<bluefoxicy> heh
<desrt> so what?  again -- makes no difference
<desrt> the GPL does not have a plugin infrastructure :p
<desrt> (yet...)
<bluefoxicy> oddly enough there's a special exception for linking programs with openssl and .. what the fuck does this say
<desrt> that's a grant of additional rights
<desrt> and it's a modification of the actual license
<bluefoxicy> http://rafb.net/p/HvjQsC57.html
<bluefoxicy> thaaaaat makes no sense.
<desrt> it makes a lot of sense
<desrt> and it's a modification of the actual license
<bluefoxicy> "If you received these files with a written license agreement or contract stating terms other than the terms above, then that alternative license agreement takes precedence over these comments."  Also nmap is apparently REALLY BSD licensed  :p
<tbf> desrt: but even gpl3 only will allow you to widen permissions
<desrt> if nmap wanted to do what they are trying to do then they should have modified the GPL
<bluefoxicy> tbf:  as the copyright holder you can do whatever the hell you want
<bluefoxicy> you can say something is LGPL but you have to only run it when entertaining a dancing monkey or else the license is invalid.
<desrt> bluefoxicy; but then it's _not LGPL_
<desrt> it's a new licensed based on LGPL
<bluefoxicy> desrt:  hey you see the point!
<desrt> nmap says quite clearly "This program is free software; you may redistribute and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; Version 2.
<desrt> i can therefore chose to ignore their additional claims and redistribute straight-up under GPL2
<desrt> *choose
<bluefoxicy> technically not
<desrt> technically i may redistribute and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation
<desrt> and technically they can bite me if they try to stop me
<bluefoxicy> the additional claims are described as their interpretation of the license; copyright holder's interpretation, if documented, is then open to interpretation by court as part of the license.
<tbf> bluefoxicy: you'd need to receive the alternate license agreement from some legitime copyright holder
<tbf> bluefoxicy: otherwise that clause is void
<bluefoxicy> technically my interpretation of the GNU GPL is that the linking clause is invalid and I treat the GPL exactly as the LGPL
<bluefoxicy> so by desrt's logic I can pretty much ignore that part of the GPL
<tbf> bluefoxicy: guess you'll fail with that interpretation in court
<bluefoxicy> tbf:  are you up to speed on what we're talking about?
<desrt> bluefoxicy; In addition, mere aggregation of another work not based on the Program with the Program (or with a work based on the Program) on a volume of a storage or distribution medium does not bring the other work under the scope of this License.
<desrt> bluefoxicy; installsheild is definitely a distribution medium
<tbf> bluefoxicy: you claimed the linking clause of the GPL invalid
<desrt> bluefoxicy; so not only are their ideas bogus... but some of them are outright contradictory....
<tbf> bluefoxicy: and my believe is you'll fail in court with that interpretation
<tbf> bluefoxicy: when GPL was tested in german courts reasoning of the judges always was: "GPL enhances your rights. the restrictions to not reduce your rights below the default case. so every restriction of it is valid."
<bluefoxicy> tbf:  http://rafb.net/p/PTpOZj96.html  desrt's claim is that once you reach line 4, lines 10-24 are invalid
<tbf> *do
<bluefoxicy> (particularly 16-19)
<Mithrandir> bluefoxicy: a licence is not a program, it has to be interpreted as a whole.
<bluefoxicy> Mithrandir:  that is my argument, yes.
<bluefoxicy> <desrt> nmap says quite clearly "This program is free software; you may redistribute and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; Version 2. <desrt> i can therefore chose to ignore their additional claims and redistribute straight-up under GPL2
<bluefoxicy> is what I'm arguing against
<_ion> This discussion is pointless. Everyone knows that GPL is invalid and SCO owns the rights to your code.
<popey> bluefoxicy: line 31 specifically states that they see it as an interpretation of the GPLv2, not a change to or addition to the GPL
<desrt> bluefoxicy; do you not believe that i may redistributed and/or modify nmap under the terms of version 2 of the GNU General Public License as published by the Free Software Foundation?
<popey> so I would agree with desrt, you can re-release under flash GPLv2
<desrt> bluefoxicy; if you don't believe this then perhaps you need to learn to read....
<bluefoxicy> popey:  i.e. you can ignore their interpretation and substitute your own?
<popey> you can ignore their interpretation and continue to redistribute the code under the *same* license - GPLv2
<popey> IMO
<Mithrandir> popey: you have to distribute it with the interpretations from Insecure.com LLC
<bluefoxicy> who here is actually a lawyer
<bluefoxicy> because I sure as hell ain't
<popey> thats fine, interpretation != license
<tbf> bluefoxicy: those are restrictions not found in original GPL and line 4 allows usage of original GPL
<Mithrandir> popey: those definitions are parts of the licence.
<popey> "We dont consider these to be added restrictions on top of the GPL,"
<tbf> bluefoxicy: so the nmap authors better should have contacted a laywer to get their restrictions right
<Mithrandir> bluefoxicy: I review quite a bit of licences, so even though I'm not a lawyer, I have a bit of training in reading them.
<bluefoxicy> Mithrandir:  close enough.  I try to figure out what something logically says (you are distributing under X license, you specifically clarify that you think X says Y, so you are distributing under Y); but nobody said courtroom battles involved logic.
<bluefoxicy> then again
<bluefoxicy> Xerol tutors contract law, I could go ask him.
<Mithrandir> bluefoxicy: but then, what is the problem?
<desrt> nmap's claims appear to self-contradict even themselves
<bluefoxicy> Mithrandir:  I was curious if those interpretations fell under debian non-free; amap was squashed out of ubuntu entirely (not even in multiverse, although we have ADOBE FLASH) for its weird license
<desrt> they say that they consider a program a derived work if it reads nmap's files
<desrt> but only if nmap is shipped by the same company as the program reading the files
<tbf> hmm..... stop: have to correct me.
<desrt> if the company directs you to the nmap website to download nmap (instead of giving you a copy) then they're OK again
<bluefoxicy> "reads or includes" "does any of the following"
<Mithrandir> bluefoxicy: which one do you believe makes it non-free?
<bluefoxicy> these are both inclusive or
<desrt> insane.
<tbf> they use the loophole of GPL-2 not properly describing the term "derived works"
<desrt> "derived works" is a legal term
<desrt> it doesn't need to be defined
<desrt> it already has a meaning
<bluefoxicy> Mithrandir:  I don't know.  The license defines what a "derivative work" is and I'm simply not sure if that pushes it for debian or not.
<desrt> (people disagree on this meaning... but that's really for a judge to decide)
<desrt> bluefoxicy; the license is the GPL2.  it says so VERY VERY clearly.
<bluefoxicy> I'm not an expert on debian policy either, I'm just a curious neophyte
<tbf> desrt: if that's true, the only questions is: is their definitition more restrictive or more permissive?
<desrt> tbf; if someone decides exactly what "derived work" means in a given country then it will affect all GPL code
<desrt> for example... many contend that the idea that a program that links to a library is a "derived work" of that library to be quite bogus...
<Mithrandir> tbf: that's irrelevant, given that it doesn't link with any GPL-ed libs.
<bluefoxicy> desrt:  that is mostly because you can link to a similar library you wrote (that doesn't even provide any functionality), then copy the resulting program to a new machine and (lo and behold) it happens to use the other library instead, not exactly your fault.
<bluefoxicy> yes irrelevant for this discussion
<tbf> rofl: "Links to a library or executes a program that does any of the above."
<tbf> so you connect via pipe to a GPL program doing the parsing
<tbf> .oO(programmers really should not try to mess with licenses)
<bluefoxicy> and you are automagically gpl
<desrt> this conversation is mental.  bye.
<bluefoxicy> tbf:  in the same fashion as with the linking clause argument I give above, imagine you connect via a pipe to an MIT-licensed program that has its own (shitty) built-in scanner; and the new version uses nmap instead and parses the result to look the same.
<bluefoxicy> now what happens, does your program become a derivative work immediately when that program is born?  When the first end user runs it in this way?  When you release a new version?
<Mithrandir> bluefoxicy: it probably depends on intent.  If you created the program so that you could use nmap, it ends up being a derivative work, if you didn't intend it to, it doesn't.
<bluefoxicy> Mithrandir:  it depends on intangible assets, awesome.
<Mithrandir> bluefoxicy: yes, computer people doesn't like those kinds of things, but it's important in law.
<bluefoxicy> Mithrandir:  if I wrote a pure nmap clone and the program could use nmap because of this I'm safe, but if I write it without doing this I'm not safe.
<Mithrandir> bluefoxicy: http://ansuz.sooke.bc.ca/lawpoli/colour/2004061001.php talks a bit about it.
<bluefoxicy> Let us propose instead that the pure nmap clone theoretically exists, and just ignore that whole chunk of the license based on the theory that I can rectify any legal claims you bring up to me in about 3 days.
<Mithrandir> bluefoxicy: that doesn't really help you if you intended it to be used with nmap, even though it could be used with something else.
<Mithrandir> but we are getting very, very off-topic for this channel now. :-)
<LaserJock> :-)
<bluefoxicy> the channel was idle anyway.  It WAS relevant when I started, it's not NOW :)
<bluefoxicy> (unless someone added #ubuntu-legal behind my back...)
<Mithrandir> hence "getting", not "has been for a while".
<StevenK> Oh no, debian-legal is messy enough already, we don't need to fuel that fire by creating ubuntu-legal.
<StevenK> Mithrandir: If there's no herd 6, surely this week won't be so hard...
<StevenK> Mithrandir: Or does it merely save the pain until the week of the 19th? :-P
<Mithrandir> StevenK: I'm already tired and it'll be worse over the next two weeks.
<StevenK> Mithrandir: Anything I can do to help?
<mneptok> Mithrandir: can we release Herd 6/Beta 2 in ~12 minutes
* mneptok runs
* StevenK suspects he knows the answer.
<Lathiat> mneptok: 12 minutes?
<Lathiat> mneptok: getting a bit slack...
<mneptok> Lathiat: "getting?"
<Mithrandir> mneptok: no, our publishing machine isn't that fast. :-P
<Mithrandir> StevenK: look at the RC bug list and see if there's anything there that you know how to fix.
<mneptok> Mithrandir: ooo! you got a new business card to match the change in title? ;)
<StevenK> Mithrandir: I had a look at the bug list for the ubuntu-7.04 milestone which are all mostly assigned.
* Mithrandir slaps mneptok 
<Mithrandir> StevenK: indeed, there are a few which aren't, some of which are Hard.
* mneptok polishes his halo
<StevenK> Mithrandir: I had a look at elmo's nmap bug, which I can't reproduce.
<Mithrandir> I can't either
<StevenK> Shall we slam it into Needs Info, and bounce the ball into elmo's court?
<Mithrandir> yes, I think that makes sense.
<tbf> crap: how do i create 99_autoreconf.patch files?
<StevenK> Bad elmo. He isn't even subscribed to it.
<tbf> i want to rebbuild notification-deamon-0.3.7 after applying https://bugs.launchpad.net/ubuntu/+source/notification-daemon/+bug/102128
<ubotu> Malone bug 102128 in notification-daemon "Notification daemon leaks X11 windows" [Undecided,Confirmed]  
<TheMuso> Mithrandir: When you have a chance, could you please consider bug 91868 for casper?
<ubotu> Malone bug 91868 in casper "Magnifier does not start from accessibility menu due to incorrectly referenced file." [Undecided,Unconfirmed]  https://launchpad.net/bugs/91868
<orkid> ubotu shut up
<ubotu> Sorry, I don't know anything about shut up - try searching on http://bots.ubuntulinux.nl/factoids.cgi
<Mithrandir> TheMuso: sure.
<StevenK> tbf: Which patch, there are 3?
<StevenK> Mithrandir: Shall I be evil, and subscribe elmo to the nmap bug?
<TheMuso> Mithrandir: Thanks.
<Mithrandir> StevenK: yes, please.
<tbf> StevenK: bugfix is the first one
<tbf> StevenK: the other two patches are needed as some folders were moved
<tbf> StevenK: currently patching the remaining 5 patches of the package, but to test them i want to build the package
<StevenK> Mithrandir: All done (nmap bug)
<tbf> StevenK: problem: applying the autoreconf patch fails even after recreating it
<tbf> (by running autoreconf -i --force and diffing)
<StevenK> tbf: Okay, so you only want to add the first patch to notification-daemon and rebuild?
<tbf> StevenK: in a ideal world it would be that simple.
<tbf> StevenK: but as folders have moved, i have to adjust all patches
<tbf> StevenK: duh stop.
<StevenK> tbf: Stopping. :-)
<tbf> StevenK: maybe i just was too lazy to create a changelog entry
<pitti> Good morning
* StevenK waves to pitti.
<pitti> hey StevenK 
<tbf> StevenK: that plus the incredibly trick to create a recursive version of the autoregen patch containing a patch against itself
<imbrandon> moins all
<StevenK> tbf: Hurray!
<pitti> \sh_away: I'm packaging mysql 5.0.38 now, let me know how it goes
<tbf> woah! new launchpad's avatar scaling blows
<popey> indeed
<popey> you have to use a fixed size image
<popey> padd it out with whitespace yourself :(
* popey also notes that this wasn't even shown in the private beta, then when the public beta hit the streets, suddently I had a badly scaled avatar on my "home" page
* popey removed it
* Treenaks filed a bug about it
<popey> bug #?
<Treenaks> 101858
<popey> bug 101858
<ubotu> Malone bug 101858 in launchpad "User image in user info page is stretched" [Undecided,Confirmed]  https://launchpad.net/bugs/101858
<popey> ta
<popey> you know it does say on the +branding page "An image of exactly 64x64 pixels that will be displayed in the heading of all pages related to you." and "A large image of exactly 192x192 pixels, that will be displayed on your home page in Launchpad. "
<Fujitsu> popey: The new avatar stuff was added about 24 hours before it went public.
<popey> and the public beta was 3 days before it was originally planned?
<Fujitsu> I didn't know that it was planned for any specific point.
<popey> thats what i was told
<dholbach> good morning
<tbf> popey: well, but some people already uploaded avatars to the old launchpad ;-)
<popey> yes, like me
<tbf> well, just added some padding now.
<tbf> don't have a 192x192 version of that photo and also do not know if i want such a high-res foto of mine in the public
<StevenK> tbf: Scale it to 192x192 and then blur it a lot? :-P
<tbf> StevenK: too much effort :-)
<tbf> .oO(somehow the new look of launchpad triggers this "want to have it" feeling)
<pochu> Mithrandir: if you have a moment, could you please review bug 102114? Thanks :)
<ubotu> Malone bug 102114 in liferea "[UVFe]  Liferea 1.2.10c" [Undecided,Unconfirmed]  https://launchpad.net/bugs/102114
<Mithrandir> pochu: approved
<pochu> cool, thanks! :)
<mdke> Mithrandir: is it ok if translations for *ubuntu-docs come in by the NonLanguagePackTranslation deadline? we've done that in previous releases, there shouldn't be any possibility of serious bugs being introduced by adding translations in those packages
<Mithrandir> mdke: yes, that should be ok.
<mdke> Mithrandir: sorry, misspoke
<mdke> I mean the LanguagePackTranslation deadline
<mdke> we'll struggle to get them in by the first deadline, and translators haven't had very long at them
<Mithrandir> that should be ok, yes.
<mdke> great
<mdke> Mithrandir: just to warn you, although you will probably know already, brining in translations increases the size of the -docs packages quite a lot; might have an impact on iso size if things are tight
<Mithrandir> mdke: yes, we would probably need to drop a language or two off the CD.
<mdke> ok, I'll try and get them in ASAP so you can see
<Hobbsee> Mithrandir: what's happening now with syncs, which have uvfe approval?  are we poking?  presumably you're not doing all syncs this close to release.
<pitti> StevenK: new ia32-libs uploaded; this should unbreak vmware on amd64
<Hobbsee> (or pitti)
<pitti> Hobbsee: should be processed as part of normal archive days
<StevenK> pitti: Great!
<pitti> Hobbsee: subject to the usual freezes, of course
<StevenK> Which means no more syncs at all after Thursday?
<Hobbsee> pitti: right.  yes, it already has an exception.  https://bugs.launchpad.net/ubuntu/+source/basket/+bug/102252
<ubotu> Malone bug 102252 in basket "UVFe - Sync Basket 1.0.1 from experimental" [Undecided,Confirmed]  
<pitti> StevenK: I just had to install the edgy version a second time and got sick of it ;)
<pitti> Mithrandir: oh, no 0403 CDs; is the daily image process on manual already?
<Mithrandir> pitti: no, it shouldn't be.
<Mithrandir> pitti: they might just not be ready yet.
<Mithrandir> Hobbsee: archive days, or poke if it's urgent.
<carlos> pitti: did you upload the new language packs for Feisty?
<Hobbsee> Mithrandir: right.  it's only urgent in the fact that id' like to see it tested more widely.  it can wait.
<pitti> carlos: yes, I did
<carlos> pitti: ok, cool
<seb128> carlos: Hi. Do you know if the french translations have been changed? I got your mail bug no reply
<carlos> seb128: the language pack that pitti uploaded had that change done, and I asked Stuart about that a couple of minutes ago, to see whether is on production, once he answers I will tell you...
<seb128> carlos: ok, thank you!
<carlos> you are welcome
<siretart> Nafallo: around?
<mneptok> ogra: ping
<ogra> mneptok, pong
<tkamppeter> Mithrandir, ping
<dholbach> Mithrandir: what do you think about bug 102274?
<ubotu> Malone bug 102274 in libsexy "UVF: libsexy 0.1.10 -> 0.1.11" [Medium,Unconfirmed]  https://launchpad.net/bugs/102274
<Mithrandir> dholbach: looks sane to me.
<dholbach> Mithrandir: gracias
<Mithrandir> tkamppeter: don't just ping, ask me the question you want to ask.
<mneptok> Mithrandir: i have a complex issue i need help with when you have a chance.
<Mithrandir> mneptok: shoot
<tkamppeter> Mithrandir, for the update to HPLIP 1.7.3 I did a user survey now to exclude regressions. I got 12 users going through my testing program and no one found any regression, this eaven lead to additional bugs getting found and fixed by HP. See bug 98520.
<ubotu> Malone bug 98520 in hplip "Feisty UVF ER: New HPLIP 1.7.3 release fixes lots of bugs" [Medium,Needs info]  https://launchpad.net/bugs/98520
<Mithrandir> tkamppeter: cool, great.  Go ahead and get your sponsor to upload then.
<tkamppeter> Thanks, Mithrandir.
<pitti> Mithrandir: weird; current live CDs are now two hours late, and alternate (http://cdimage.ubuntu.com/daily/current/) is empty
<Mithrandir> pitti: I'll take a look at what's broken.
* pitti hugs Mithrandir 
<fabbione> pitti: could you be so kind to eyeball the patch to #98518 before i prepare edgy/feisty? specially if you want more details and so on...
<fabbione> pitti: it's just to save time before i install edgy and feisty and blablabla
<Arby> pitti: is it the same build system that provides the kubuntu daily builds as well?
<Arby> I do some kubuntu iso testing and todays builds are late there as well.
<pitti> fabbione: Tore's last suggestions don't sound bad; does this need to be addressed as well?
<fabbione> pitti: adding the docs? yes.. i will do that too... i don't think they are critical for the proposed patch
<fabbione> pitti: i need to know first if the code changes are ok with the SRU team. they are more important a bit intrusive.. hence priority to them first
<pitti> fabbione: I meant using sg_turs as a test and checking vendor ID, too
<kwwii> seb128: can you look at bug #43398
<ubotu> Malone bug 43398 in ubuntu-artwork "Blurry icons in applications menu" [Medium,Fix released]  https://launchpad.net/bugs/43398
<kwwii> seb128: at first I thought it was the icons themselves, but that does not seem to be the case
<fabbione> pitti: oh that comment was not there when i reloaded the page 5 minutes ago!.. just one minute :)
<pitti> fabbione: the udev rule ensures that the changes are confined to a specific type of hardware; if the change is tested on such hardware, the current amount of information is good for moe
<pitti> fabbione: s/moe/me/
<fabbione> pitti: i have the HSG80 here at home :)))
<pitti> splendid
<fabbione> pitti: ok.. i will need to recheck with Tore suggestions.. 
<fabbione> pitti: they were just not there when i asked you :)
<pitti> fabbione: right, I understand :)
<fabbione> pitti: thanks tho :)
<carlos> Riddell: hi, around?
<seb128> kwwii: do you really think they are blurry? ;)
<seb128> kwwii: the panel uses the 24x24 icon, it might scale it to 22x22 though
<HiddenWolf> Guys, is something up with the ML archives?
<HiddenWolf> haven't been any logs this month so far
<Mithrandir> HiddenWolf: they're lagging
<HiddenWolf> ok
<fabbione> pitti: updated debdiff.. and i am off for lunch
<pitti> fabbione: I can't claim that I would understand it completely, but given the specific udev rule I'm ok with it
<pitti> fabbione: certainly much better than the weird init script h4ck
<mvo> cjwatson_: hello! will it be ok if I change the section for ubuntu-meta from "base" to "metapackages" ? this will ensure that the section is correct in /var/lib/dpkg/status 
<seb128> kwwii: http://bugzilla.gnome.org/show_bug.cgi?id=343437
<ubotu> Gnome bug 343437 in Panel "Use correct size for launcher icons (on the panel and in the menu)" [Minor,Resolved: fixed]  
<seb128> mvo: are you working on the seed?
<kwwii> seb128: if you check that screenshot I attached, it is definitely blurry
<mvo> seb128: no, this is just about the "ubuntu-meta" package, not the seed
<seb128> mvo: ok, I thoguh it was built from the seed
<kwwii> seb128: the difference in icon sizes between kde and gnome is a real pain
<kwwii> seb128: so, are we going to stick to using 22x22 icons?
<seb128> kwwii: the panel logic should handle 24x24 correctly, I'm talking to upstream
<kwwii> seb128: excellent, thanks :-)
<seb128> np
<Riddell> carlos: pong
<carlos> Riddell: hi, I know it's quite late in the development process
<carlos> Riddell: but when k3b was updated to 1.0
<carlos> k3b-i18n was not updated
<carlos> so we have old translations
<Riddell> carlos: very good point
<Riddell> carlos: I'll get onto it now and chastase the people who forgot it (including myself)
<carlos> Riddell: thank you
<seb128> kwwii: could you try to:
<seb128> - add 'gtk-icon-sizes = "panel-menu=24,24"' to the Human gtkrc
<seb128> then change theme
<seb128> or restart the panel
<seb128> and let me know if you think it's nicer
<kwwii> seb128: will do
<doko> Mithrandir: please could you consider bug 102268 ?
<ubotu> Malone bug 102268 in neon26 "UVF exception and sync request (0.26.3)" [High,Confirmed]  https://launchpad.net/bugs/102268
* thom wishes idly that apt'd build faster
<kwwii> seb128: yes, that fixes the problem for all the gnome icons although the kde icons in the menu now are blurry instead (but I think that as one is running gnome by choice it is better to have the gnome icons look nice as you'll see many more of those)
<cjwatson> mvo: ubuntu-meta Section: metapackages> no problem
<fabbione> pitti: thanks
<fabbione> pitti: but if you want a full more detailed explanation i can give it to the sru team. it's just complex..
<Mithrandir> doko: looks good; approved
<mvo> cjwatson: cool, thanks!
<fabbione> seb128: i saw your last gamin upload.. so i was right this time it wasn't a kernel issue :P
<seb128> kwwii: right, better to have the GNOME icon theme looking nice on GNOME
<seb128> fabbione: yep ;)
<kwwii> seb128: exactly :-)
<Riddell> carlos: uploaded
<dholbach> kwwii: tangerine+tango-stock-icons uploaded
<tbf> seb128: may you have a look at bug 102128 and apply at least the first patch?
<ubotu> Malone bug 102128 in notification-daemon "Notification daemon leaks X11 windows" [Undecided,Confirmed]  https://launchpad.net/bugs/102128
* kwwii hugs dholbach
<seb128> tbf: I've already showed it to mvo
<tbf> seb128: ah, cool :-)
<Seveas> elmo, mako: CC meeting in 4 minutes - sabdfl available?
<cjwatson> I can probably sit in for a while
<Keybuk> fabbione: could you mail me your /var/log/udev
<carlos> Riddell: ok, thank you
<mvo> Riddell: I will do a upload of kubuntu-meta to change the Section to metapackages (just FYI)
<mvo> ogra:  I will do a upload of edubuntu-meta o change the Section to metapackages (just FYI)
<ogra> oki
<Riddell> mvo: oki
<mvo> thanks :)
<seb128> mvo: will you update an ubuntu-meta?
<mvo> seb128: no, I haven't
<seb128> mvo: "will" you ;)
<seb128> mvo: I've commited changes to the desktop seed yesterday and I'm wondering if I can be lazy and wait on your upload :p
<cjwatson> mvo: xubuntu-meta too?
<stgraber> Hey, anyone willing to sponsor the upload for : bug 68818 ?
<ubotu> Malone bug 68818 in squid "squid transparent proxy is broken" [High,In progress]  https://launchpad.net/bugs/68818
<mvo> seb128: no, I uploaded already and changed only the section. if you need a seed change you will have to upload again, sorry 
<mvo> cjwatson: all of them
<seb128> mvo: ok
<mvo> cjwatson: ubuntu,xubuntu,edubuntu,kubuntu
<mvo> -meta
<mvo> seb128: what change do you need?
<ogra> does anyone know where /sbin/update-modules.modutils belongs to ?
<seb128> mvo: I commited it yesterday, added dcraw to desktop
<ogra> seems its broken so debootstrap doesnt work
<Fujitsu> `diversion by module-init-tools to: /sbin/update-modules.modutils'
<ogra> (linux-sound-base.postinst calls it)
<cjwatson> ogra: full log please?
<mvo> seb128: ok, sorry. I can do another upload for you if you want me to
<cjwatson> no, linux-sound-base.postinst calls update-modules
<seb128> mvo: no, that's fine, I'm just wondering how you did update the package without using the change on bzr
<cjwatson> though that execs update-modules.modutils
<ogra> cjwatson, which in turn calls update-modules.modultils here
<ogra> right
<ogra> which in turn calls itself
<ogra> a very excessive while 1; do :P
<fabbione> Keybuk: yes... but it's the one without lvm/mdadm & co running from init.d
<Keybuk> that's ok
<Keybuk> I'm initially interested in the whole | thing
<Keybuk> which I suspect is why the second bunch of init scripts stop
<Keybuk> (they'll probably carry on after an hour or so <g>)
<NDAKOTA> hi
<NDAKOTA> anyone familiar with the python scripting bounty posted on ubuntu website
<NDAKOTA> hello
<NDAKOTA> !
<NDAKOTA> developers
<NDAKOTA> echo
<thom> NDAKOTA: look, please be polite and show some patience
<thom> if someone knows, they'll answer you. either way, everyone is busy preparing for a new release
<NDAKOTA> alright, I'm being impatient.
<NDAKOTA> yea, sorry i did not know
<asac> pitti: simple question: how are dbgsym packages generated for your archive? Just a plain buildpackage or with "noopt"?
<seb128> asac: the dh_strip way after build
<pitti> asac: they are not compiled at all; just what objcopy --only-keep-debug gives us
<pitti> asac: it hooks into dh_strip
<asac> yeah i know about the strip
<asac> but where do you get the debug symbols from if you don't build the package?
<pitti> asac: they are copied from the already built ELF file during the normal build process
<pitti> asac: in debian/rules binary stage, after dh_install and everything
<asac> ok ... so you hooked into the buildd ?
<asac> didn't know that ... thought you generate them on your own ... ok, then i understand
<mvo> seb128: new ubuntu-meta with refreshed dependencies uploaded 
<seb128> mvo: cool!
* seb128 hugs mvo
* mvo hugs seb128
<jwendell> how to make reportbug tool report bugs in debian, instead of ubuntu?
<Hobbsee> jwendell: reportbug -B debian, iirc.  man reportbug tells you
<Hobbsee> along with lots of other options
<jwendell> Hobbsee, thanks
<ogra> fabbione, did you change anything in update-modules with your last module-init-tools upload ? i cant build chroots anymore, linux-sound-base hangs at /sbin/update-modules.modutils which seems to call itself in an endless loop
<fabbione> ogra: no.
<ogra> hmm
<ogra> root@edubuntu:/# cat /sbin/update-modules.modutils
<ogra> #!/bin/sh -e
<ogra> if [ -x /sbin/update-modules.modutils ] ; then
<ogra>   exec /sbin/update-modules.modutils "$*"
<ogra> fi
<ogra> exit 0
<ogra> that doesnt look right to me ...
<cjwatson> looks like it's been mistakenly diverted twice
<ogra> yes
<Saied> all,hi
<Saied> we are working on conexant winmodem driver
<Saied> currently at start stage
<Saied> we heared that the ubuntu community are working on a free conexant modem driver, is it true?
<mjg59> Saied: Not currently
<mjg59> (As far as I know)
<miladmovie> Saied, na inja ham khabry nist
<gicmo> grml
<gicmo> wlan still doesnt work
<gicmo> ohh and sound stopped working too
<gicmo> wtf
<Saied> miladmovie: tablo baazi dar nayar
<Saied> miladmovie: :D
<miladmovie> Saied, ;)
<gicmo> Feisty from 2 weeks before worked way better ;-)
<Saied> mjg59: are there any plans in future?
<mjg59> Saied: It's quite likely that you'd find someone interested in working on it
<mjg59> Saied: Who's currently working on it, and what sort of skills do they have?
<seb128> gicmo: you might want to be specific about your configuration if you want any constructive reply :p
<Saied> mjg59: yaah, we want to work on it
<gicmo> seb128: I am not sure if I already have given up
<seb128> gicmo: if you have opened a bug maybe join #ubuntu-kernel and ask if you can give extra details or something
<Saied> mjg59: we have another team and currently we are at planning stage
<Saied> mjg59: do you have any links to this project of ubuntu community?
<mjg59> Saied: I'm not aware of anything having been produced
<mjg59> Saied: do you have any pointers to your planning?
<Saied> mjg59: in our country we have lots of problems with this winmodems and we want to solve it at least locally. in #technotux we are speaking on it
<mjg59> Saied: What sort of implementation are you currently planning?
<Saied> mjg59: HCF and HSF implementation for linux kernel 2.6.20 or above. maybe user space , udev based , etc
<mjg59> Saied: Have you determined any of the functionality of the codec?
<mjg59> Saied: slmodemd already provides an (admittedly closed-source) modem stack
<Saied> mjg59: codec? what do you mean?
<siretart> Keybuk: re bug #102089 - I'm not sure how to interpret your last comment
<ubotu> Malone bug 102089 in devmapper "latest devmapper upload breaks booting" [High,Needs info]  https://launchpad.net/bugs/102089
<mjg59> Saied: Hm. I think you need to do a little more research.
<siretart> Keybuk: I had to downgrade libdevmapper1.02 in order to boot my system correctly again
<mjg59> Saied: Precisely which hardware are you looking at? A great deal of modern Connexant chips are connected to an AC97 or HDA bus
<mjg59> There's already some infrastructure for dealing with them
<mjg59> But no support for the chip itself
<Saied> mjg59: i mean modems that can attach to PCI bus. (internal winmodems)
<ilovelinux> Saied: it seems irc.ubuntu.com is here !!!
<iwj> ogra: So re update-modules.modutils, does anyone know of a fix or know who's responsible or is anyone working on it or what ?
<Keybuk> siretart: right, you need to upgrade it to break your system and follow the second stage of "Needs Info" in that bug
<Keybuk> iwj: isn't that a dpkg bug
<Keybuk> ?
<Keybuk> where's the diverted update-modules coming from
<mjg59> Saied: The base functionality of the chip is the same whether it's on a PCI bus, an AC97 bus or a USB bus
<Mithrandir> you can also just debootstrap a chroor
<iwj> Keybuk: I don't know.  I don't know anything yet; I've only just stumbled over this.
<Mithrandir> chroot, even
<iwj> ogra: If you have some information please let us know :-).
<Keybuk> iwj: I've only seen one bug report from somebody about it
<Keybuk> ogra: does it affect you?
<siretart> Keybuk: ok., will do this evening
<iwj> Keybuk: In my case it breaks debootstrap.
<Keybuk> siretart: this evening is going to make it practically impossible for this to be fixed before release candidate :-/
<ogra> Keybuk, yes for ltsp chroots
<Keybuk> ok
<siretart> Keybuk: that's sad :( - but I can't leave work right now
<iwj> ogra: You make those with debootstrap ?
<Keybuk> ogra: dpkg -S /usr/bin/update-modules and .modutils
<ogra> yes
<Keybuk> siretart: if you could investigate heavily into what it is about those scripts that breaks things for you -- that would be very useful
<ogra> Keybuk, i need to build a new one ... i'm currently totally into something else, give me a minute
<Keybuk> siretart: rather than just "downgrade"
<Keybuk> siretart: since those packages do fix things for (afaict) the majority of people, and only cause new breakage for a few (important) people
<Keybuk> siretart: afaik those two init scripts (mdadm-raid and lvm) are completely useless; so we need to understand what they do, and why -- and why it breaks things (because they should have no effect)
<siretart> Keybuk: the thing is that I didn't find enough documentation which explained how things are supposed to work and how to do useful diagnostics
<iwj> ogra: Do you want me to pick this up ?  It's blocking me and I'm not too deeply nested right now ...
<bddebian> Heya
<Keybuk> siretart: you're subscribed to a bug where it's quite heavily detailed
<siretart> Keybuk: I could upgrade them from here, but I'd better don't reboot. perhaps this helps you as well?
<Saied> mjg59: we want to reimplement linuxant hcf and hsf winmodem drivers 1-free 2-with full bandwidth
<Keybuk> iwj: there's not much you can do unless you can be around this evening to help siretart debug
<ogra> iwj, that'd be great, i'm totally swamped with ltsp tests
<iwj> Keybuk: No, I meant the update-modules thing.
<Keybuk> iwj: err, sorry, ignore that :)
<ogra> but i'm building a chroot already again, so if you need info i'll keep it around
<mjg59> Saied: Then you have to care about AC97 and USB as well as PCI
<iwj> Keybuk: Although I can try to help if you like and might be able to be around this evening at least a bit.
<iwj> Keybuk: If so then I'll need to look over what you did in your most recent packages ...
<Saied> mjg59: you said infrustructure. which infrustructure do you mean?
<mjg59> Saied: So it makes sense to work out what the fundamentals of the chip behvaiour are, independent of the bus
<Keybuk> iwj: I may be also, but I haven't gone to the new hotel yet, so haven't found out what their "High Speed Internet Access In Every Room" really means
<iwj> Keybuk: Also you should know I have a cold so am a bit stupid atm.
<iwj> Keybuk: *snort*
<mjg59> Saied: For the ac97 case, you'll want to interface with the existing snd-intel-modem, snd-atiixp-modem and so on drivers
<Saied> mjg59: hmm, maybe at beggining only for PCI . it is great if possible to work bus independent
<Keybuk> siretart: bottom of #75681
<siretart> bug #75681
<ubotu> Malone bug 75681 in mdadm "boot-time race condition initializing md" [High,Fix released]  https://launchpad.net/bugs/75681
<Keybuk> well, second-to-bottom
<Keybuk> since someone can't read the "file a new bug with your symptoms, to avoid a hijack-fest" :p
<jandark> Saied, yup
<siretart> Keybuk: are there any diagnostics I can do with you which do not involve rebooting the system?
<Keybuk> siretart: I can't think of any that won't hose your system
<mjg59> Saied: You'll also need a modem protocol stack. As I said, slmodemd provides one. Rather than write one from scratch, it would make sense to make your driver provide an interface that slmodemd can use
<Keybuk> I'd certainly recommend a console for "muck around with root filesystem"
<ogra> ogra@edubuntu:~/devel/feisty-ltsp$ sudo chroot /opt/ltsp/feisty/ dpkg -S /sbin/update-modules 
<ogra> diversion by module-init-tools from: /sbin/update-modules
<ogra> diversion by module-init-tools to: /sbin/update-modules.modutils
<ogra> module-init-tools: /sbin/update-modules
<ogra> ogra@edubuntu:~/devel/feisty-ltsp$ sudo chroot /opt/ltsp/feisty/ dpkg -S /sbin/update-modules.modutils
<ogra> diversion by module-init-tools from: /sbin/update-modules
<ogra> diversion by module-init-tools to: /sbin/update-modules.modutils
<ogra> iwj, Keybuk ^^^^^^
<mjg59> Saied: That way, if someone wants to write an entirely free modem stack, they can just replace slmodemd. Then it doesn't just benefit the Connexant hardware, it benefits all Linux modem users.
<Keybuk> ogra: dpkg-divert --list /sbin/update-modules
<iwj> ogra: Yes.
<siretart> Keybuk: any idea which command could cause theses 'Rendevouz with udev timed out' error messages?
<Keybuk> siretart: using dmsetup (or anything linking to libdevmapper) and expecting a name to appear that's different to what the kernel knows for that name
<ogra> ogra@edubuntu:~/devel/feisty-ltsp$ LANG=C sudo chroot /opt/ltsp/feisty/ dpkg-divert --list /sbin/update-modules
<ogra> diversion of /sbin/update-modules to /sbin/update-modules.modutils by module-init-tools
<Keybuk> so where's that other /sbin/update-modules.modutils come from?
<iwj> AFAICT the problem happens as follows: debootstrap extracts (dpkg -x) update-modules.  Then it installs (dpkg -i, effectively) module-init-tools, diverting module-init-tools's update-modules to update-modules.modutils.
<ogra> chaos :D 
<Keybuk> iwj: but that shouldn't happen, because the diversion is listed against module-init-tools
<yacoob> can anyone explain me what's so nifty about https://wiki.ubuntu.com/NoMoreSourcePackages ?
<Keybuk> yacoob: rationale is in the spec
<iwj> Keybuk: Yes, but the first module-init-tools is _extracted_ ie nothing looks at diversions, just dump the files in the fs.
<ogra> Keybuk, no clue, its there when deboostrap hangs itself
<Keybuk> I think iwj is right
<Keybuk> but why's it suddenly happening now?
<yacoob> Keybuk, it doesn't convince me :) Or rather, I'm not sure about the consequences.
<iwj> And what is the point of diverting update-modules and replacing it with a file which just runs the original update-modules ?!
<ogra> there is none
<ogra> especially since it conflicts with modutils
<ogra> which is the only other package providing it
<Keybuk> does it conflict?
<Keybuk> the original purpose was that you could install module-init-tools and modutils at the same time
<iwj> debootstrap installs don't normally have modutils, do they ?
<ogra> well, it Conflicts: modutils (<= 2.4.21-1)
<iwj> Keybuk: Yes, but why the crazy wrapper script ?  AFAICT the only effect would be to make attempts to run update-modules silently succeed if modutils's update-modules isn't installed (at least, that seems to be the intent).
<ogra> right, there is no modutils in my chroot
<Keybuk> right
<yacoob> my first concern is, where would upstream sources end up in this scheme?
<iwj> Maybe the bug is that debootstrap shouldn't be installing module-init-tools.
<Keybuk> because there's no reason to *have* an update-modules if you're using module-init-tools
<yacoob> second: it doesn't mean apt-get source is going away, does it?
<Keybuk> yacoob: 1) in revision control
<Keybuk> yacoob: 2) yes, for normal development
<ogra> iwj, maintainer scripts call update-modules ....
<ogra> so you need a dummy at least
<iceman> mvo: Is it possible at this time to upgrade to the beta via update-manager? I'd like to offer my help to test it out now if it's already supposed to work.
<yacoob> Keybuk, so we're throwing .tgz into rcs?
<yacoob> and what about those folks that want to recompile the packages?
<iwj> Hmm.  All a bit lame really.
<mvo> iceman: yes, please run "update-manager -d" (e.g. via terminal or alt-f2)
<yacoob> (not popular among 'standard users', but popular when you're taking care of server, not workstation, and you have specific needs)
<iwj> Maybe module-init-tools's update-modules should test whether $0 is update-modules.modutils and if so it should exit 0 and perhaps delete itself :-).
<StevenK> seb128: I have a ~2K debdiff for zenity to fix 2 of the outstanding bugs if you have a moment, and the last bug open against zenity can be closed.
<iceman> mvo: I knew how to do it, I just didn't know if it was already working. Thanks, I'm doing it right-away. ;-)
<mvo> iceman: let me know about any problem
<iceman> mvo: of course, that was the point ;-)
<Keybuk> yacoob: they'd have a similar tool to grab the "package" in one command, taking just the name
<iwj> Maybe this has just started happening now because we've stopped including modutils ?
<yacoob> Keybuk, hmm.
<yacoob> if it won't be a matter of http/ftp transfer, I'm cooked.
<yacoob> (I have a bunch of machines behind very restrictive proxy)
<ogra> iwj, did we ?
<ogra> that'd be silly ... we dont have 2.4 kernels why should it have been in a default bootstrap
<iwj> I don't know - I'm just speculating.
<yacoob> ah, I see.
<yacoob> * Source package and binaries are built and published into the archive
<yacoob> so, the source package is still there, but is rather output, instead of input
<iwj> The change to update-modules is from Debian in 2004.
<iwj> Although we seem to have adopted it only somewhat recently.
<Keybuk> iwj: we never needed to adopt it
<Keybuk> ?
<Keybuk> we've always had it
<Keybuk> since that predates Ubuntu
<Keybuk> something else (debootstrap, maybe) must have changed recently
<iwj> I don't think I'm going to go any further into the archaeology.  I think I'll just add a fixup to the debootstrap script.
<Keybuk> ogra: when did it break?
<Keybuk> or, to ask a better question
<Keybuk> when did it last work?
<ogra> Keybuk, i didnt do any chroots since a week ..
<ogra> and it broke with the first one today
<iwj> Keybuk: I'm not sure either.  It's been a while since I regenerated.
<ogra> all i found were fabios uploads, but that didnt change any maintainer scripts 
<Keybuk> yeah, I'm just going to look at those carefully
<iwj> I looked at them already, they're not relevant I think.
* iwj edits /usr/lib/debootstrap/scripts/feisty.
<BenC> anyone know how to add keymappings for special keys on laptops (like media keys)?
<Keybuk> ogra: confirmed, no changes there
<Keybuk> BenC: setkeycodes thingy
<BenC> Keybuk: thanks
<Keybuk> there's an mjg59-tastic init script
<iwj> But some laptops have buttons that aren't keys.
<Keybuk> iwj: those usually generate acpi events
<Keybuk> BenC: hotkey-setup package
<BenC> iwj: these produce key codes, but they just aren't mapped to do anything
<iwj> BenC: Oh, right, setkeycodes IYF
<BenC> Keybuk: I'll check that too
<_ion> benc: Hi, have you received my messages? I might be able to help with the l-r-m changes re: the nvidia drivers  is there a VCS branch for l-r-m?
<BenC> _ion: I've gotten them, and I'm working on it today
<Keybuk> BenC: that has little bits of shell for known laptop models so we can map them for everyone
<BenC> Keybuk: ah, that's probably what I want then, thanks
<Keybuk> so you should add your laptop to it, and then upload so everyone can share the KEY_COFFEE
<iwj> Yep that change to the feisty script worked and I think that's the right fix because it's really a "bug" in the way debootstrap works (that is, it's a result one of the assumptions invalidated by debootstrap).
<iwj> ogra: Tell me your email address and I'll pipe the diff to mail -s something you so you can try it.
<Keybuk> what I don't understand is why this is suddenly happening
<ogra> iwj, ogra@ubuntu.com :)
<ogra> yeah
<Keybuk> that code has been in module-init-tools since hogley
<wasabi> Sometimes I think if launchpad was foss (or even commercial), I'd buy it for use at work.
<wasabi> Sure works nice when it works.
<Keybuk> fabio's uploads don't go near it
<iwj> Keybuk: Yes.  I don't know what the problem is.  I suspect that module-init-tools has only recently shown up in debootstrap installs.
* ogra wonders why he just read artwork above
<iwj> ogra: Mail on the way.  Please don't reply to that email; the From: will be a bit crazy.  (root@mytestbox)
<ogra> yeps :)
<cjwatson> iwj: is module-init-tools by chance now Priority: required?
<cjwatson> iwj: please hold off on debootstrap for a second
<iwj> cjwatson: I don't know but perhaps
<iwj> cjwatson: Sure, I won't upload anything just yet ...
<ogra> could mvo's base-Ymetapackage section change have something to do with it ?
<cjwatson> iwj: stuff that's Priority: required gets extracted then unpacked; stuff that's Priority: important only gets unpacked
<cjwatson> ogra: no
<ogra> s/Y/>/
<iwj> cjwatson: ISTR a message from debootstrap about it being an additional required package (due to dependency chasing) but I don't have a relevant log to hand.
<cjwatson> iwj: aha
<iwj> cjwatson: Is it wrong for module-init-tools to turn up in debootstrap ?
<cjwatson> so somebody added a dependency from a Priority: required package on module-init-tools, I guess
<cjwatson> iwj: it should be in the important set but not in the required set (at least until it learns how to cope with being extracted first)
<iwj> initramfs-tools ?
<Mithrandir> i-t is just priority: important
<cjwatson> Priority: important
<iwj> cjwatson: udev
<iwj> Also important.
<iwj> Hmm.
<iwj> Bear with me, I'll run it again and get real information.
<iwj> I: Found additional required dependencies: busybox-initramfs cpio initramfs-tools klibc-utils libklibc libvolume-id0 module-init-tools udev volumeid 
<Mithrandir> nothing I have installed at least is Priority: required and depends m-i-t
<cjwatson> whoa, that's a lot
<pitti> asac: tbird upload> ah, that would explain crappy retrace results
<cjwatson> dmsetup Priority: required Depends: udev
<Keybuk> why is dmsetup required?
<Mithrandir> Keybuk: depended on by libdevmapp1.02
<Mithrandir> libdevmapper1.02, even
<cjwatson> I don't think it needs to be. libblkid1 -> libdevmapper1.02 -> dmsetup
<Mithrandir> (which is priority: required)
<Keybuk> why is that required?
<cjwatson> but libblkid1 isn't depended on by anything else required
<cjwatson> so I think we can demote that whole shebang
<cjwatson> I'll try it out and see
<Mithrandir> cjwatson: e2fsprogs depends on libblkid1
<cjwatson> oh, Pre-Depends, that's why I missed it
<Keybuk> ah, I added that dmsetup -> udev dependency
<Keybuk> so that explains why it's suddenly appeared
<Keybuk> but yes, that whole lot should not be Required
<cjwatson> Keybuk: no, Mithrandir's right, it needs to be due to libdevmapper1.02 -> dmsetup
<Keybuk> but devmapper doesn't need to be Required
<Keybuk> tracking its rdepends back doesn't find anything critical
<cjwatson> libblkid1 Depends: libdevmapper1.02. Yes it does
<Keybuk> what uses blkid?
<cjwatson> 16:02 <Mithrandir> cjwatson: e2fsprogs depends on libblkid1
<Mithrandir> e2fsprogs
<Keybuk> oh, hmm
<Mithrandir> which is Essential and required.
<Keybuk> bugger
<cjwatson> it's a pre-depends so if you were using grep-dctrl -FDepends like me you'd have missed it
<Keybuk> yeah I just forgot that
<iwj> libblkid doesn't use any of the device-creation stuff on libdevmapper, surely ?
* Mithrandir generally uses aptitude's browsing mode.
<cjwatson> iwj: I think it's linked against it ...
<iwj> Which is what the dependency on udev is for (to stop the udev rendezvous not working)
<Mithrandir> can it be turned into a breaks instead?
<iwj> So perhaps libdevmapper -Recommends-> udev instead ?
<cjwatson> so it doesn't have a choice unless the dmsetup -> udev Depends arc can be dropped somehow
<Keybuk> hmm
<iwj> I assume it's libdevmapper -> udev not dmsetup -> udev directly, surely ?
<cjwatson> iwj: nope, it's dmsetup
<iwj> How bizarre.
<Keybuk> that's probably wrong :)
<iwj> Yes :-).
<Keybuk> it should be a breaks on udev
<Mithrandir> 17:05 < Mithrandir> can it be turned into a breaks instead?
<Mithrandir> :-P
<iwj> Although I thought I'd made the libdevmapper rendezvous stuff only happen if /dev was udev.
<cjwatson> so, either fix this dependency graph or make module-init-tools tolerate being dpkg -x'ed - preferably both
<Keybuk> [ Uploading job devmapper_1.02.08-1ubuntu7_source
<Keybuk>  devmapper_1.02.08-1ubuntu7.dsc 0.7 kB, ok (1 s, 0.73 kB/s)
<Keybuk>  devmapper_1.02.08-1ubuntu7.diff.gz 48.2 kB, ok (0 s, 48.24 kB/s)
<Keybuk>  devmapper_1.02.08-1ubuntu7_source.changes 1.2 kB, ok (0 s, 1.24 kB/s) ] 
<pitti> dholbach: http://daniel.holba.ch/bugs/ FTW! *hug*
<iwj> Keybuk: Oh, you meant Breaks.
<iwj> cjwatson: Right.
<iwj> The latter I think is debootstrap's bug, or do you disagree ?
<cjwatson> I disagree; module-init-tools should tolerate it itself if at all possible
<cjwatson> if absolutely necessary it could be special-cased in debootstrap but I'd much rather not
<iwj> OK.  I think I know how to do that although it's a bit freaky.
* dholbach hugs pitti back
<dholbach> pitti: i hope everybody starts contributing their clue files now :)
<cjwatson> I realise debootstrap's arrangement is odd although I counter that getting a base system to exist at all fundamentally involves oddness :-)
<iwj> cjwatson: Fair point.
<cjwatson> freaky> something like diverting it only if we think the file belonged to modutils?
<cjwatson> *oww*
<iwj> cjwatson: Yes.  Otherwise we trash it.  Perhaps we look at the file to see if it looks like one of ours.
<iwj> Put a magic comment in it for that purpose.
<Keybuk> [ Uploading job udev_108-0ubuntu2_source
<Keybuk>  udev_108-0ubuntu2.dsc 0.7 kB, ok (0 s, 0.66 kB/s)
<Keybuk>  udev_108-0ubuntu2.diff.gz 53.8 kB, ok (0 s, 53.78 kB/s)
<Keybuk>  udev_108-0ubuntu2_source.changes 1.3 kB, ok (0 s, 1.34 kB/s) ] 
<cjwatson> why does it divert it anyway if it's just going to exec the old one?
<Keybuk> those two should sort it out
<cjwatson> oh, it's just making sure that update-modules exists even if modutils isn't installed
<asac> pitti: yes ... should be fixed now. that's why I asked you about dbgsym generation process, so i could verify :)
<iwj> cjwatson: So that if the old one doesn't exist you get `true' rather than ENOENT.
<Keybuk> cjwatson: right, maintainer scripts call it
<cjwatson> yeah
<cjwatson> argh, evil ancient workarounds
<iwj> Why do they call it with absolute path ?
<cjwatson> if stuff had done 'if which blah >/dev/null; then ...' then we wouldn't have this problem
<iwj> Move it to /usr/sbin :-).
<Keybuk> we could strip all the evil diversion out, since we don't have modutils anyway
<iwj> Keybuk: Oh, don't we ?  I see ...
<cjwatson> maybe which was less reliable back then and we didn't want to do if [ -x /absolute/path ] 
<cjwatson> modutils is in main
<cjwatson> something must depend on it
<asac> who maintains the latest and greatest greasemonkey scripts for lp beta?
<cjwatson> it's not seeded
<Keybuk> cjwatson: yeah, I keep eradicating those, and they keep coming back
<cjwatson> so we can't break the diversions because people have modutils installed
<iwj> Oh, FFS, how do you tell whether /boot/vmlinuz-2.6.19-4-generic is (a) a normal kernel (b) a Xen kernel (c) something else ?
<iwj> (a) shows up in `file' as `Linux kernel x86' etc.
<cjwatson> nvidia-kernel-common Depends: modutils | module-init-tools
<iwj> (b) shows up as `gzip compressed data' which when you decompress it is `ELF 32-bit LSB executable, Intel 80386'
<cjwatson> as does laptop-net
<cjwatson> and modconf
<cjwatson> nvidia-kernel-common is probably what's causing it to be in main though
<Mithrandir> nothing depends on modutils without an alternative on module-init-tools
<cjwatson> Mithrandir: indeed, but sometimes germinate gets a bit confused by inconsistent alternates
<Mithrandir> and since it's 2.4-only, we can just remove it.
<fabbione> Keybuk: i guess those 2 uploads will fix my problem? :)
<Keybuk> fabbione: which?
<fabbione> Keybuk: udev and devmapper
<Keybuk> fabbione: nope, nothing to do with your problem
<ogra> fabbione, that fixes debootstrap
<fabbione> Keybuk: ok :(
<cjwatson> anyway, I maintain that there's a decent chance that people will have it installed since it's in main, and even if we remove it that doesn't mean we get to delete maintainer script code which causes it not to break
<Keybuk> fabbione: I'm waiting for the further information I asked for from you before I can debug your problem
<fabbione> Keybuk: i did send you all the info you asked?!?
<Keybuk> fabbione: you only send me your udev.log
<fabbione> Keybuk: what's missing?
<Keybuk> fabbione: still waiting for the output of running the mdadm-raid and lvm scripts by hand with sh -x, noting where things go wrong
<fabbione> Keybuk: nope.. i did reply to the mail too
<fabbione> Keybuk: ah ok.. sure.. i can add those but i know where it hangs
<fabbione> and i did add the strace of it
<Keybuk> I don't :)
<Mithrandir> cjwatson: fwiw, I have it installed. :-P
<Keybuk> err, where's the strace?
<iwj> Aha!  A __xen_guest section in the ELF.
<fabbione> Keybuk: in the first email
<Keybuk> "VG fucking" :)
<fabbione> Keybuk: yeah that one
<fabbione> at least i am sure it's unique :)
<Keybuk> the bit I can't understand is how you have LVM-on-devmapper
<Keybuk> what are those /dev/mapper/hda2 and /dev/mapper/hdb1 things?
<ogra> 
<Keybuk> where are those created/what by?
<fabbione> Keybuk: i have no idea... i just upgrade on this box.. how can i check?
<Mithrandir> Keybuk: evms
<Keybuk> you have evms installed?
<fabbione> probably yes
<Keybuk> what happens if you remove evms? :p
<Mithrandir> (with a 87.3% certainity)
<fabbione> Keybuk: it's installed...
<Keybuk> (purge it, in fact)
<Keybuk> it shouldn't be depended on by this stack, since I don't have it installed
<fabbione> Keybuk: i can try to remove it but lvm runs before evms on this machine
<fabbione> ok i can try... 
<Keybuk> evms is part-installed in the initramfs
<Keybuk> that might explain where your /dev/mapper/lvm2|vgname|lvname things are coming from
<fabbione> just keep in mind that everybody upgrading from warty up to dapper will have it installed by default
<Mithrandir> Keybuk: yes, it does.  (I have lvm2|xoog1|home in /dev/mapper)
<Keybuk> iiinteresting
<fabbione> Keybuk: ok.. rebooting now.. if you don't see me back in 20 minutes i suggest start sending patches this way :PPPP
<Keybuk>     EVMS is able to manage block devices ordinarily managed by both LVM and MDADM, for this reason these two services will be disabled if EVMS is installed, ideally we'd like to prevent them from being installed at all, but this has consequences for upgrades from when we used to install evms by default.
* Keybuk reads the spec
<Keybuk> "we didn't do this bit"
<Keybuk> and I suspect I can already see the bug
<Keybuk> (assuming this isn't a total evms vs. world fuckage)
<Keybuk> add -> add|change
<Keybuk> fabbione: it booted?
<fabbione> Keybuk: yes it booted and no hangs on the scripts
<fabbione> 2 bugs then
<fabbione> 1) evms blocks
<fabbione> 2) evms must update initramfs on purge
<Keybuk> ok
<Keybuk> I think I have a fix
<Keybuk> could you install evms again for me
<fabbione> does it require me to reboot again?
<fabbione> (installing)
<Keybuk> yes
<Keybuk> once installed, edit /etc/udev/rules.d/70-evms.rules
<Keybuk> change both instances of ACTION=="add" to ACTION=="add|change"
<Keybuk> update-initramfs -u
<Keybuk> then try rebooting
<fabbione> both the ACTIONS ?
<Keybuk> yes
<Keybuk> basically run evms_activate whenever a devmapper (or other block) device gets updated
<fabbione> SUBSYSTEM=="block", ACTION=="add|change", ENV{ID_FS_USAGE}=="raid", GOTO="evms_activate_do"
<fabbione> SUBSYSTEM=="block", ACTION=="add|change", KERNEL=="dm-*", GOTO="evms_activate_do"
<fabbione> GOTO="evms_activate_end"
<fabbione> LABEL="evms_activate_do"
<fabbione> RUN+="watershed /sbin/evms_activate"
<fabbione> LABEL="evms_activate_end"
<Keybuk> yup
<Keybuk> try with that
<fabbione> is the call to watershed ok?
<Keybuk> looks ok, iwj?
<fabbione> or does it need fancy paramentes?
<Keybuk> not that I know of
<Keybuk> that's fine
<fabbione> ok.. brb
<Keybuk> iwj's manpage is helpful (pointed look) :p
<iwj> Yes, should be fine.
<iwj> The usage message ought to be sufficient.  Sorry for the lack of manpage ...
<iwj> And yes, you're supposed to be able to just wrap things up with watershed.
<Keybuk> if this doesn't work, then evms must be doing rude things to devmapper
<Keybuk> and asking it to create/wait for devices that are named differently to what it tells devmapper
<Keybuk> (actually, that may not work anyway, because udev will "sanify" the names, but it'll give us a good start)
<vciaglia> hello
<fabbione> Keybuk: better but not good enough.
<Keybuk> fabbione: what happened this time?
<fabbione> Keybuk: with that change to the rule initramfs gets to mount / and that's good
<Keybuk> ok, still hangs during boot though?
<fabbione> Keybuk: as soon as mdadm init script triggers udev events -> BAM
<Keybuk> it apparently only hangs for 3-9 minutes per LV, so it's not eternal
<Keybuk> anyway, I think I know why
<Keybuk> did you manage to boot with evms installed?
<Keybuk> or did you go back to LNG without it?
<fabbione> i had to purge it to reboot
<Keybuk> ok
<Keybuk> so you're in a clean no-evms system now?
<fabbione> it's just a matter of time.. 9 minutes for lv on my system it means about 1h:30m per boot :)
<Keybuk> heh
<fabbione> Keybuk: yes.. i am without now
<Keybuk> can you install evms again, and make the add -> add|change modification to 70-evms.rules again
<Keybuk> no need to reboot for this test though
<Keybuk> root fs mounting = good
<Keybuk> I think I know what is causing the hang
<fabbione> Keybuk: not right now.. i need to feed my son and getting ready for a conf call in 1 h
<fabbione> it will need to wait a little bit.. but later i can do it for sure
<Keybuk> ok, when's good for you?
<fabbione> after the conf call.. that means around 6:30pm your time
<fabbione> or Mithrandir can probably help you there too. he even uses evms :)
<bluefoxicy> Wow.  One of my bugs went from NeedsInfo => Rejected => Confirmed over the course of 2 days.
<fabbione> i don't.. it was just installed there since.. hmmmm sid -> warty ?!?
<Keybuk> bluefoxicy: which?
<Keybuk> Mithrandir: do you use LVM as well?
<bluefoxicy> Keybuk: https://bugs.launchpad.net/bugs/66820
<ubotu> Malone bug 66820 in linux-source-2.6.15 "nobody cares about via interrupt" [Undecided,Needs info]  
<Keybuk> heh
<fabbione> gotta run now...
<fabbione> bbl
<bluefoxicy> oh, okay..  Change in linux (upstream) I see.
<bluefoxicy> upstream rejected, then confirmed it.  (I'm getting e-mails about this somehow)
<bluefoxicy> by the by, there should be a message center in Launchpad, so it stops spamming my e-mail.  Imagine having about 30 active bugs, and every day you have 12 messages coming down your pipe.
<bluefoxicy> I can't imagine what the developers must face.  5000 messages per day?
<pitti> bluefoxicy: I feel like that, yes ;)
<pitti> bluefoxicy: message center is called 'bug views' ;)
<bluefoxicy> pitti:  ah thx
<TomaszD> has feisty-changes list gone off the record?
<cjwatson> TomaszD: the list archiving machine is having trouble keeping up
<TomaszD> ok
<yacoob> is there a way to find out for a closed bug on launchpad which package version brought in the fix?
<Keybuk> yacoob: sadly not yet, that is being worked on so we can close bugs with the upload and thus record that information
<yacoob> mmm, good.
<_ion> I thought that feature already works.
<yacoob> (debian does that? by scaning package changelog, no?)
<_ion> I probably thought wrong, then.
<Keybuk> yacoob: exactly, we're going to be doing it a similar way
<Keybuk> we've already made the necessary modifications to dpkg, and already set a policy for the changelog format
<Keybuk> so many uploads actually already include the list of bug numbers to be closed
<Keybuk> but the LP part isn't yet finished (the LP team have been hard at work preparing for the 1.0 Beta)
<_ion> Alright.
<yacoob> why it wasn't just taken from debian? :)
<Keybuk> yacoob: because Debian use a different bug tracking system from us
<Keybuk> and we upload Debian changes as well
<yacoob> Righto.
<Keybuk> so uploads using exactly the same format would've closed randomly unassociated bugs
<Keybuk> (since they would be from Debian changelog entries, thus referring to Debian bug numbers)
* yacoob needs to read up on ubuntu's developement rituals/procedures, I'm mostly familiar with debian's
<_ion> "rituals", interesting way to put it. :-)
<yacoob> _ion, things that are done the way they're done because... everyone did those that way :D
<Keybuk> ours are mostly they're done that way because nobody came up with something better at the time
<yacoob> Keybuk, any url you can point me to, for above?
<Keybuk> wiki.ubuntu.com/UbuntuDevelopment
<yacoob> thanks.
<siretart> Keybuk: okay, just returned home, now following your instructions
<Mithrandir> Keybuk: sorry, got distracted; no, I don't use LVM on this machine, just evms
<Mithrandir> and lvm2 isn't installed either
<siretart> Mithrandir: would you consider evms more mature than lvm2?
<Keybuk> Mithrandir: ok
<Mithrandir> siretart: I haven't used lvm2, so I can't comment on that.
<siretart> i see
<siretart> Keybuk: manually exec'ing /sbin/init shows the same symptopms (bug #102089)
<ubotu> Malone bug 102089 in devmapper "latest devmapper upload breaks booting" [High,Needs info]  https://launchpad.net/bugs/102089
<siretart> Keybuk: what whas the rune again to make upstart boot into single user mode? booting with option 'single'?
<Keybuk> siretart: yes
<Keybuk> (busy right now, will look into these problems in a bit)
<siretart> Keybuk: no problem
<siretart> I'm glad I've caught you  at all
<Keybuk> siretart: do you have evms installed?
<siretart> Keybuk: booting with 'single' shows the same symptoms
<zyga> hello
<siretart> Keybuk: evms: yes, it is installed
<siretart> shall I remove it?
<Keybuk> siretart: try removing it, yes
<siretart> do I need to rebuild the initramfs?
<Keybuk> yes
<siretart> k
<siretart> huch? "filesystem doesn't have /sbin/init?!
<siretart> but it does have!
<siretart> hmm
<siretart> seems my initramfs is fucked up. I get a Usage error message from modprobe
<keescook> are packages in main allowed to Recommend packages in universe?
<seb128> yes
<siretart> keescook: we already have some
<keescook> seb128, siretart: okay, thanks.  Just wanted to be sure.  :)
<seb128> keescook: that might change when we do the "install Recommends by default" though
<siretart> seb128: I hope it doesn't
<keescook> seb128: the specific issue is that an Inkscape python extension needs python-numpy.  I figured the best course was to add it to Recommends
<seb128> siretart: why?
<seb128> siretart: change it to Suggests if it's an universe package
<seb128> siretart: or get the recommended package promoted
<siretart> seb128: xine is nearly useless without libxine1-ffmpeg, but it must not depend on it
<seb128> siretart: we have no real reason to recommand a package we don't support officially
<seb128> well, you need easy codec installation ;)
<siretart> seb128: we do: it must not go on the livecd, but having it on installed systems is really recommended
<siretart> seb128: aaah, then I have you as volunteer to implement  it. Thanks! :)
<seb128> siretart: no
<seb128> siretart: well, if it's to main it can be recommended, if it's not then we don't support it and we should not recommend it anyway
<seb128> yeah, patents suck :/
<siretart> seb128: true, libxine1-ffmpeg is indeed in main, so that's a non-issue here. you're right
<siretart> perhaps we need some switch in apt for that: install recommends only from main by default or something
<siretart> and optionally recommended packages from universe as well
<LaserJock> keescook: I'll probably be interested in promoting python-numpy and python-scipy for Feisty+1
<siretart> Keybuk: update: removing evms seems to 'cure' it
<kofler> Has anyone experienced issues with the i810 on ViewSonic monitors before? If my case ends up being compelling enough, a patch to the kernel modules package may be in store.
<keescook> LaserJock: cool.
<siretart> Keybuk: somehow I managed to produce a fucked initramfs, removing some backup files (*.~ and *.dpkg-old) and regenerating it fixed that for me
<kofler> If I start GDM up, login with resolution at 1440x900, then logout, GDM produces an effective I can only label as "radioactive."
<kofler> Er, no sorry, that's with the intel drive. With the i810, it doesn't scale the resolution out to the full width of the monitor.
<kofler> driver even.
<Keybuk> siretart: ok, can you reinstall initramfs
<Keybuk> errr
<Keybuk> EVMS
<Keybuk> reinstall that
<Keybuk> modify 70-evms.rules to change ACTION=="add" to add|change
<Keybuk> exit 0 in the two problematic init scripts
<Keybuk> and then reboot
<Keybuk> and see how far that gets
<siretart> you mean exit 0; in mdadm-raid?
<Keybuk> yeah
<Keybuk> just at the top so it doesn't get run
<siretart> and you mean both lines with ACTION=="add", right?
<Keybuk> yup
<siretart> rebooting
<siretart> oh nice, now it seem to hang at "Starting Enterprise Volume Management System"
<Keybuk> heh, exit 0 that one too
<siretart> ok, killing it with SysRq-i
<Keybuk> (I think I know why they hang - I just need you to get to the end of the boot to confirm my hypothesis)
<siretart> so I get a rootshell at least
<siretart> rebooting
<mvo> ogra: can you please check #94712 ? I assume you have a current edubuntu addon-cd?
<siretart> Keybuk: ok, now it hangs somewhere after fsck.
<siretart> Keybuk: but I've seen this before
<siretart> any idea how to figure out what's actually blocking here?
<siretart> hm. after some timeout, I get the well known message: "Rendevouz with udev timed out for '...'; stat failed: No such file or directory
<siretart> killing it with SysRq-i
<Keybuk> siretart: please get to the end of the boot and have a shell
<Keybuk> anywhere in the boot with a shell
<siretart> Keybuk: by pressing SysRq-i I kill rcS, but the boot procedure continues
<siretart> Keybuk: not all filesystems have been mounted, but it is enough to get my gdm started
<Keybuk> ok
<siretart> Keybuk: read: I do have a rootshell now
<Keybuk> ok
<Keybuk> exxxxcellent
<Keybuk> can you look for /dev/mapper/lvm2* for me
<siretart> I suspect the cryptdisks init script are blocking here
<Keybuk> do you have any of those?
<siretart> has, there are several /dev/mapper/lvm2_* devices there
<Keybuk> do you have lots of things that look like /dev/mapper/lvm2_vgname_lvname
<Keybuk> (note _s)
<siretart> yes, I see e.g. my root device as /dev/mapper/lvm2_hades_stripe_ubunturoot
<Keybuk> ok
<Keybuk> now, looking at those Rendezvous error messages
<Keybuk> do those refer to the same devices BUT with | instead of _ ?
<Keybuk> ie. /dev/mapper/lvm2|hades|stripe|ubunturoot
<siretart> gnarf, it just scrolled away :/
<siretart> and nothing to see in /var/log/boot :
<siretart> :/
<Keybuk> ok
<siretart> need to reboot and retimeout
<Keybuk> can you check that for me?
<siretart> to be sure, I'm disabling the cryptsetup initscripts and reboot, okay?
<Drakeson> I want a patched/enhanced dpkg, apt-utils to manage local stuff ($HOME/bin, $HOME/lib, $HOME/share). I don't like ruby gems, not evan cpan ...
<Drakeson> (this was a wish actually)
<Treenaks> Drakeson: there's cpanplus, that can create debs..
<Drakeson> suggested in debian-devel, and found out there is lack of man-power
<Drakeson> what about a dpkg based one?
<Drakeson> dpkg is already very good
<Keybuk> siretart: sure
<Keybuk> siretart: just want to know whether the timeout errors are due to lvm2|...|...| where you have _ instead
<siretart> Keybuk: timeouting now...
<siretart> ok
<siretart> is there some way to lower the timeout?
<siretart> it seems rather high to me
<Drakeson> imagine if that happens... I can build, install and test packages locally (dpkg --prefix=$HOME), and then install them in my system (dpkg --prefix=/usr)
<LaserJock> Drakeson: if Debian has a lack of man-power I'm not sure you'll find more in Ubuntu
<Drakeson> and then I can finally forget about all the lousy package managers (gems, ...)
<Drakeson> LaserJock: maybe my imagination, but I thought ubuntu has some mechanisms to develop special stuff more quickly
<Drakeson> e.g. polishing the desktop
<Drakeson> maybe this is not important enough...
<kofler> Anyone heard of such a phenomenon before where GDM goes "radioactive"?
<LaserJock> Drakeson: right, but those resources are going into polishing the desktop, etc. not rewriting dpkg
<Drakeson> actually not rewriting but just patching. if I could somehow fakeroot apt and feed it my custom sources, I could provide some repos for various locally installed packages
<siretart> hm. now it hangs for too long without timeout :/
<LaserJock> Drakeson: I don't think there's really a common usecase that can't be handled by existing tools
<Drakeson> to me a local package manager is as important as cvs/svn/git/... , of course I am only a single user, but I can see many uses in many many applications for a locally managed repos. Starting from monthly repos for wallpapers, themes, ..., to speciall purpose software packages
<LaserJock> Drakeson: well you can easily do locally managed repos
<LaserJock> with existing tools
<cjwatson> Drakeson: that's been discussed in Debian, but I'm afraid making that work would involve changes to a very large number of packages, and I just don't think there's enough impetus to make it happen
<siretart> Keybuk: wow. on my 2nd boot with just disabling the cryptsetup scripts, now I have /dev/mapper/lvm2|hades_stripe|.. devices
<siretart> Keybuk: and most of my LVs are missing
<cjwatson> doing it in Ubuntu would involve us maintaining a pretty huge diff from Debian, which we try to do only when it's a very big win for us
<siretart> rebooting again to see if that's reproducible
<Drakeson> LaserJock: by locally I mean as a non-root user
<cjwatson> Drakeson: packages are built with many expectations about paths, and in general are not relocatable
<cjwatson> dpkg is not the real problem here
<cjwatson> it's more 10000 packages each with their own different and exciting absolute path assumptions
<Drakeson> cjwatson: but user-mode could discard many of the expectations for stuff like e.g. $HOME/shar/emacs/lisp stuff
<siretart> Drakeson: many packages's maintainer scripts (postinst, prerm, etc) expect to be run as root and have assumptions about the exact location of shipped binaries
<cjwatson> Drakeson: it cannot be done automatically, and would involve experts in each package going through it with a fine tooth-comb
<cjwatson> that sort of thing is actually better tried in Debian than here
<Drakeson> are we talking about relocating an existing package?
<cjwatson> but as I say, it has come up before, and it's basically come down to too much effort for not enough gain
<siretart> perhaps someone could invent *.rdeps, (relocatable debs), which have like normal debs, but can be relocated by a future dpkg
<Drakeson> relocating already built packages is not my main point.
<mvo> Drakeson: something like "klik" might actually be a better option to spend resources on
<cjwatson> source packages also have extensive assumptions
<cjwatson> siretart: rpm has a Relocatable: yes flag or similar, but that still leaves changing all the packages
<LaserJock> I think zeroinstall is kinda close too
<cyt> I am curious why my friends use Debian for a long time think Ubunut is bug-prone than Debian?
<Drakeson> mvo: klik is just another example
<cyt> Is that ture, or any misunderstanding?
<siretart> cjwatson: yes. at least, this becomes an opt-in rather than an opt-out decision
<Drakeson> I already know there are many other projects and package-managers out there in the wild.
<cjwatson> personally, I honestly don't think it's worth the introduction of bugs that the facility would imply
<Drakeson> but dpkg is very strong in my opinion.
<Drakeson> well, let me focus on my first use-case:
<Drakeson> I want to manage stuff like matlab toolboxes, octave pkgs, emacs lisp pkgs, gems, ...
<Drakeson> they all have the same concepts
<cjwatson> we understand your request, but explaining them further here will not cause (a) manpower to magically appear or (b) the potential for bugs due to introducing this facility and hacking up loads of packages to be able to use it to go away
<cjwatson> s/them/it/
<cjwatson> I'm afraid this is just an extremely long-term project and not a quick hack at all
<cjwatson> and TBH I would just recommend using a test box and then installing them as root
<cjwatson> given path assumptions strewn throughout many projects, test-installing in $HOME is not going to be very reliable anyway
<Drakeson> well, the problem is that some packages are not even meant to be put in /usr
<cjwatson> test hardware, or even a virtual machine, is pretty cheap these days
<Drakeson> thanks for the clear answer ;)
<keescook> siretart: none of my LVM starts up any more, even if I do break=mount
<keescook> on the other hand, the md is okay.  :)
<siretart> keescook: huch?
<keescook> To boot these days, I'm doing   break=mount, waiting for it to settle, then "lvm vgchange -a y" followed by "exit" when it settles again
<siretart> keescook: yes, this was the situation for me before yesterday
<siretart> Keybuk: can I modify /etc/event.d/rcS somehow so I can see which scripts it is actually executing?
<siretart> Keybuk: I was thinking about replacing the "exec /etc/init.d/rcS" line with "exec sh -x /etc/init.d/rcS"
<Drakeson> cjwatson: just let me ask your opinion, what do you think of a (small) project to fork dpkg (and discard/remove many of its capabilities) or maybe patch it and build dpkg-local to manage fancy stuff like user wallpapers, small perl/ruby/... packages, ... ?
<siretart> Drakeson: did you already have a look at zeroinstall and/or klik? - aren't they doing what you have in mind?
<cjwatson> Drakeson: it's free software, you can do whatever you like
<cjwatson> I'm just saying I think you will find it difficult, that's all
<Drakeson> cjwatson: ok, thanks a lot.
<Keybuk> siretart: yeah, /etc/init.d/rc has a startup() function
<Keybuk> siretart: the | vs. _ thing is caused by udev
<Keybuk> udev makes the devices but "sanifies" their names
<Keybuk> http://people.ubuntu.com/~scott/packages
<Keybuk> that has a udev you should build and install
<siretart> k
<Keybuk> and then modify 25-dmsetup.rules and add OPTIONS+="all_partitions" into it before the PROGRAM= bit
<Keybuk> uh
<Keybuk> no
<Keybuk> OPTIONS+="no_replace"
<siretart> Keybuk: ok. btw, editing /etc/event.d/rcS to say 'exec /bin/sh -x /etc/init.d/rcS' didn't show the bash traces :/
<siretart> Keybuk: I added that OPTIONS+="no_replace", directly before the only line ACTION=="add|change", PROGRAM="..." bit, correct?
<iwj> Drakeson: You might get some mileage out of a bizarre combination of fakeroot and --admindir etc. options, but please don't come running to me when you can't get it to work.
<Keybuk> ACTION=="add|change", OPTIONS+="no_replace", PROGRAM="/sbin/devmap_name %M %m", \
<Keybuk>                 NAME="mapper/$result", GOTO="dmsetup_end"
<Keybuk> ^ should look like that
<Treenaks> *growl* panel crashed _again_
<siretart> ok. that's how it looks here
<siretart> anything else?
<Keybuk> nope
<Keybuk> update initramfs and try again
<siretart> rebooting
<Drakeson> iwj: thanks
<siretart> Keybuk: wow. now this is much better. it doesn't block anymore
<siretart> hald takes ages, but that's another story (and I've noticed that before)
<siretart> Keybuk: I'm reenabling the cryptsetup scripts and evms, okay?
<Keybuk> ok
<Keybuk> try it with that
<tkamppeter_> pitti, doko, anyone there?
<siretart> Keybuk: happy with enabled evms and cryptsetup scripts, now reenabling crypted swap
<Adri2000> Keybuk: can you please take a look at http://librarian.launchpad.net/7130514/buildlog_ubuntu-feisty-i386.filezilla_3.0.0%7Ebeta7-0ubuntu1_CHROOTWAIT.txt.gz ?
<tkamppeter_> who is responsible for dmsetup?
<siretart> tkamppeter_: better don't ask ;)
<tkamppeter_> sirestart, why?
<siretart> tkamppeter_: I'm fighting with it together with Keybuk and iwj for some days if not weeks!
<siretart> Keybuk: all happy now. seems that the test udev package with the new dmsetup udev rule does the trick
<Keybuk> Adri2000: any particular reason?
<Keybuk> missing depends
<tkamppeter_> I have a problem with it. Someone (doko or Pitti) has uploaded HPLIP 1.7.3 for me and the build server cannot build it as it chokes on installing dmsetup for the chroot. See http://librarian.launchpad.net/7130499/buildlog_ubuntu-feisty-i386.hplip_1.7.3-0ubuntu1_CHROOTWAIT.txt.gz, In the end there is 
<tkamppeter_> Setting up dmsetup (1.02.08-1ubuntu7) ...
<tkamppeter_> /var/lib/dpkg/info/dmsetup.postinst: line 4: update-initramfs: command not found
<Keybuk> siretart: everything works, mdadm-on-lvm crypted-swap-on-md ?
<siretart> btw, does anyone now why at the end of feisty boot, I get a "HOME not defined in environment!" why?
<siretart> Keybuk: yepp!
<Keybuk> tkamppeter_: err, don't you have initramfs-tools installed?
<Adri2000> Keybuk: missing depends in dmsetup, right? you are the last uploader
<siretart> Keybuk: err, it's the other way round: lvm-on-mdadm rather than mdadm-on-lvm
<Keybuk> siretart: right
<Keybuk> what's your cryptroot on?
<Keybuk> or cryptswap?
<siretart> I don't have cryptroot, only cryptswap
<tkamppeter_> keybuk, if dmsetup tries to use it it must depoend on it and then the build server should install it automatically into the chroot.
<Keybuk> err
<Keybuk> oh bugger
<siretart> crpytroot is horribly broken in ubuntu, I'm sure it was already broken in edgy, not sure about dapper
<Keybuk> we can't depend dmsetup -> initramfs-tools
<Keybuk> because that'll reintroduce the module-init-tools problem again
<Keybuk> cjwatson: HELP!
<siretart> cryptswap is pretty easy to setup: just install cryptsetup, create a /etc/crypttab, and add swap on /dev/mapper/cswap in /etc/fstab. 
<tkamppeter_> So the buold servers are broken now, shortly before main freeze?
<tkamppeter_> Please fix that ASAP, there will be tons of uploads which do not come through.
<iwj> Keybuk: The mistake is mine; the postinst should do that only if type update-initramfs succeeds.
<iwj> (Sorry about the delay noticing this here.)
<tkamppeter> iwj, can you fix this to revive the build servers, amd64 and i386 are broken, ia64 seems not to be affected.
<tkamppeter> iwj, see https://launchpad.net/+builds/+build/316099 and https://launchpad.net/+builds/+build/316098.
<tkamppeter> What happens with the failed builds of HPLIP, will they be retried automatically as soon as the build servers get fixed?
<Keybuk> tkamppeter: no, a buildd admin has to retry them
<Adri2000> Keybuk: then please retry filezilla builds as soon as it's fixed, please :)
<Mithrandir> Keybuk: except that the chroots seem slightly busted ATM; I'll handle it.
<Keybuk> Mithrandir: thanks
<jbaloul> hi all
<jbaloul> i am trying to save stream in kaffeine and it seems to be brocken since this last upgrade
<jbaloul> used to work on dapper, but doesn't work neither on edgy nor feisty
<Mithrandir> Keybuk: making dmsetup call update-initramfs isn't the best idea.
<Mithrandir> at least not without making initramfs-tools priority: required and adding the necessary dependency.
<Mithrandir> Keybuk: ^ ; do you want to look at that?
<Keybuk> Mithrandir: iwj is already making it call update-initramfs only if that exists
<Keybuk> Mithrandir: can't make initramfs-tools required, since it depends on module-init-tools, which debootstrap hates
<Mithrandir> yup, makes sense.
<Mithrandir> do you know when he's going to upload it?
* Keybuk concentrates
* Keybuk crosses his eyes
<keescook> jbaloul: sorry, this isn't a support channel.  Please use #ubuntu, #ubuntu-bugs, or file a bug report on launchpad.net.
* Keybuk hums
<Keybuk> nope
<jbaloul> ok thanks
<iwj> Keybuk: Oh, you want me to upload new dmsetup ?  Fine, give me a moment.
<Keybuk> yes
<iwj> Keybuk: devmapper_1.02.08-1ubuntu8_source.changes 1.3 kB, ok (0 s, 1.30 kB/s) ] 
<iwj> It works here on a system with module-init-tools, at least.
<iwj> Ohhhh.  edubuntu-desktop installs network-manager which _completely funts the testbed's networking_ of course.
<vprints> Good evening!
<vprints> who sets the default applications for firefox  ?
<vprints> firefox in KDE opens pdf's with Kghostview, but in kghostview the page previews don't work
<fabbione> Keybuk: did you solve the evms issue or do you still need me to test?
<vprints> in the desktop environment pdf's are opened with KPDF, what works very well
<vprints> so we could just change the default app for opening pdf's through firefox to KPDF
<Riddell> vprints: asac would know
<vprints> Ridell, thanks =)
<vprints> *Riddell
<vprints> asac, are you around?
<Keybuk> fabbione: it looks like it's solved
<Keybuk> in scrollback you'll find something if you're interested
<Keybuk> I may have chance to put real packages together on thursday or next tuesday
<Nafallo> Keybuk: how far up? :-)
<asac> vprints: gnome mime handling afaik
<asac> if that doesn't give a result it tries mailcap
<Keybuk> <Keybuk> siretart: the | vs. _ thing is caused by udev
<Keybuk> <Keybuk> udev makes the devices but "sanifies" their names
<Keybuk> <Keybuk> http://people.ubuntu.com/~scott/packages
<Keybuk> <Keybuk> that has a udev you should build and install
<Keybuk> <Keybuk> and then modify 25-dmsetup.rules and add OPTIONS+="no_replace" into it before the PROGRAM= bit
<Keybuk> <Keybuk> ACTION=="add|change", OPTIONS+="no_replace", PROGRAM="/sbin/devmap_name %M %m", \
<Keybuk> <Keybuk>                 NAME="mapper/$result", GOTO="dmsetup_end"
<Keybuk> <Keybuk> ^ should look like that
<Keybuk> -- 
<Keybuk> Nafallo, fabbione ^
<vprints> do you maintain it asak?
<asac> y
<Keybuk> (that assumes you have also edited 70-evms.rules and changed both occurances of ACTION=="add" to ACTION=="add|change")
<manchicken> Does anybody know what package provides jsapi.h these days since libsmjs-dev is a migration package?
<ajmitch> morning
<vprints> asac, could you change it from kghostview to kpdf ?
<asac> me? no ;) its not in firefox package .... e.g. mailcap
<asac> you have to file a bug against either khostview to lower priority or kpdf to raise priority of their mailcap entries
<asac> vprints: ^^
<vprints> k
<vprints> thankyou
<asac> vprints: maybe ask in kubuntu channel as well
<Majost> does anyone have the i386 daily iso for 20070327?
<Majost> Trying to do a regression test
<vprints> asac, i did that, but those who were active at that moment were quite, well, impolite
<cyberix> Feisty has quake3-data package, but not the game itself. Is the final version going to have the game also? :-P
<jdong> BenC: just a heads-up, the new fglrx 8.35.5 is pretty quirky for me; control center crashes on startup, random hangs when switching PowerStates.... I wouldn't recommend it for feisty :)
<asac> vprints: yeah ... file a bug. if they still don't want it, there is not much you can really do
<jdong> yay for the fglrx lottery.
<BenC> jdong: thanks
<jwendell> seb128, will feisty be shipped with gnome 2.18.1 ?
<seb128> jwendell: yes
<asac> vprints: feel free to subscribe to that bugs, so i see what happens
<jdong> seb128: is that magical fglrx compiz thing still on your todo list?
<jdong> (not meant in a pushy way; just curious)
<seb128> jdong: no, it's not working as expected and it's too late now for such change on 7.04 anyway
<jdong> seb128: ok, cool, sounds reasonable. Is that patch public anywhere, or any description of how it works?
<tkamppeter> Wo are the buildd admins? Is Keybuk one of them?
<tkamppeter> s/Wo/Who/
<jdong> infinity I think is one of them.
<seb128> jdong: I think it's the same hack as used on beryl, not sure if it works on aiglx, gandalfn was not really clear about it, he spoke about fglrx and then about old card with ati driver
<seb128> jdong: I've not really looked at it
<jdong> seb128: hmm... well, Beryl surely doesn't work natively on fglrx; without using Xgl _and_ a special beryl-xgl binary :(
<jdong> so it probably doesn't work as magically as we expected :(
<seb128> hum, k
<seb128> clearly not a 7.04 thing then ;)
<jdong> right, totally agreed on that point :)
<jdong> at least compiz under Xgl works like a total dream.
<seb128> nice
<tkamppeter> jdong, thanks.
<vprints> asac, bug 102544
<ubotu> Malone bug 102544 in kdegraphics "Firefox uses not fully functional Kghostview to open PDF's in KDE instead of the system default KPDF" [Undecided,Unconfirmed]  https://launchpad.net/bugs/102544
<ds> seb128: you around?
<seb128> ds: yes
<ds> http://www.schleef.org/~ds/xvideo_test
<ds> I'm showing this causing problems on Edgy
<ds> is it too late to get these kinds of things fixed in Edgy?
<ds> er, *Feisty*
<ds> yeah
<ds> it would be nice to not have people complain about xvimagesink being broken, especially since it's a driver problem
<seb128> ds: well, do you know of any driver broken atm and how much changes are required to fix it?
<ds> radeon
<seb128> ds: we are not frozen yet, so we can still apply patches that make sense
<tepsipakki> I have 6.6.191 running, and will test this now
<ds> probably "not much", and I'll track it down
<seb128> ds: ok, just tried with my radeon card using the open source ati driver, colors are good
<ds> seb128: what version?
<seb128> feisty one
<tepsipakki> thats 6.6.3
<seb128> (II) ATI: ATI driver (version 6.6.3) for chipsets: ati, ativga
<ds> ok, that's what I have
<seb128> and it's buggy for you?
<ds> yes
<seb128> weird
<ds> curiouser
<ds> tepsipakki: what driver?
<tepsipakki> ati-6.6.191
<tepsipakki> it's not going in feisty, but just testing it
<seb128> tepsipakki: does the Ubuntu 6.6.3 has some patch that could fix that?
<tepsipakki> doesn't seem likely
<seb128> ds: if you know about any driver shipped on feisty which is broken and have a patch we can probably get it applied this week
<seb128> ds: do you want us to make a call for testing with your xvideo_test?
<ds> seb128: that's probably a good idea
<seb128> ok, I'll send a mail on ubuntu-devel then
<tepsipakki> btw, here I get an error "ERROR: Pipeline doesn't want to pause." and it kinda fails :)
<ds> seb128: it could be better, and print out some debug info
<seb128> ds: I'll send the mail tomorrow, if you want to do some changes you can do them
<ds> and, of course, there are other errors that it doesn't check for
<seb128> and I'll point your URL so if you made any change users will get the new version
<ds> tepsipakki: define "fails"
<ds> seb128: ok
<seb128> ERROR: Pipeline doesn't want to pause.
<seb128> ERROR: from element /pipeline0/xvimagesink0: Could not initialise Xv output
<seb128> Additional debug info:
<seb128> xvimagesink.c(1243): gst_xvimagesink_get_xv_support (): /pipeline0/xvimagesink0:
<seb128> No port available
<seb128> 
<seb128> it prints that
<seb128> it does display the window though
<tepsipakki> one window
<tepsipakki> when it should wait for ctrl-c and then open another with new settings
<tepsipakki> right?
<manchicken> Is there a reason why libmozjs-dev wants to remove firefox when I try to install it?
<ds> tepsipakki: correct
<seb128> manchicken: the lib from firefox and xulrunner conflict apparently
<manchicken> I'm trying to get spidermonkey libs installed so I can use Test::JavaScript Perl modules.
<tepsipakki> ds: it needs #!/bin/bash :)
<tepsipakki> since /bin/sh is normally dash
<tepsipakki> on ubuntu
<ds> tepsipakki: just figured that out :)
<seb128> ahhhh
<seb128> ds: now it's buggy :p
<seb128> the UYVY screen has many small lines
<seb128> ds: did you open a bug upstream for the ati driver?
<tepsipakki> hah, 6.6.191 works fine :)
<tepsipakki> although it does skip four of the tests for some reason
<tepsipakki> but UYVY looks fine
<ds> tepsipakki: yeah, it's supposed to skip tests
<tepsipakki> ok
<seb128> tepsipakki: ok, your next mission is to backport to fix then ;)
<tepsipakki> seb128: ouch, the commitlog is loooong :)
<Adri2000> nobody wants to fix MoM? :-(
<LaserJock> Adri2000: MoM is not open source so there's only a limited number of people who can "fix" it
<LaserJock> Adri2000: and I doubt it's a high enough priority to get it "fixed" before Feisty is released
<Adri2000> LaserJock: how would you merge a package manually?
<seb128> debdiff?
<LaserJock> Adri2000: debdiff
<LaserJock> if the Ubuntu changes are trivial you should be able to grab the new Debian package and make the changes
<LaserJock> but you can alse debdiff <old debian package> <old Ubuntu package>
<LaserJock> I put a little how to in the Ubuntu Packaging Guide
<Adri2000> the debdiff between the current ubuntu package and the current debian one is 1175 lines
<LaserJock> not current
<tkamppeter> doko, are yiu there
<LaserJock> debdiff the current Ubuntu source to the Debian package it was based on
<tkamppeter> doko, are you there?
<seb128> Adri2000: I usually read the Ubuntu changelog to know what changes are applied to it
<LaserJock> yep
<seb128> then debdiff | diffstat
<seb128> and you know what you need to copy usually
<seb128> Adri2000: now if not a moment to merde packages anyway
<Adri2000> it's a bit more complicated here because we have a -0ubuntu1... and where can I find the "old" debian version? is it still available in their archive?
<seb128> just grab a change from the Debian version if you need it
<geser> Adri2000: snapshots.debian.net
<LaserJock> Adri2000: and now a -1 package in Debian exists?
<Adri2000> LaserJock: yes
<Adri2000> -2 even
<LaserJock> Adri2000: k, then first thing is to see if it's syncable
<Adri2000> geser: snapshot without "s" :), thanks
<geser> Adri2000: simply debdiff the Ubuntu package and the Debian package so get an impression what needs merging
<Adri2000> http://changelogs.debian.net/mpd < our package is based on 0.12.1-1.1
<Adri2000> we have a bug for PulseAudio support, which is fixed in debian
<Adri2000> and there are some other interesting fixes...
<Adri2000> I have the debdiff debian base version / current ubuntu version, but if I try to apply it to the new debian version, it doesn't work... even for the changelog... how does MoM handle that?
#ubuntu-devel 2007-04-04
<geser> with black magic :)
<Adri2000> geser: I'm sure you are a magician
<geser> :)
<Adri2000> the packaging guide just says apply manually the ubuntu changes to the new debian package :-/
<Adri2000> so, behind MoM, there is either black magic, or someone who is paid by canonical to apply the ubuntu diffs to the new debian packages
<ajmitch> or just boring old diffs that you apply
<mjg59> MoM is magic
<mjg59> Though it's also possible that it's got confused somehow
<mc44> Keybuk does it all by hand really
<tepsipakki> was it just suffering from full hd's?
<tepsipakki> no disk space in other words
<sharms> so is the switch to gcc 4.2 in feisty + 1 a done deal, or is that still up in the air?
<tkamppeter> Any bbuild admin here?
<mjg59> tkamppeter: It's not morning in Australia yet, and it's night in Europe
<mjg59> Just wait. Nothing's going to miss the freeze because of a buildd issue.
<Tonio_> hum, the buildfarm looks like broken, due to dmsetup
<Tonio_> fails to install to build the chroot... is that known problem ?
<Tonio_> exact error message is /var/lib/dpkg/info/dmsetup.postinst: line 4: update-initramfs: command not found
<mooey> there was talk of such in here earlier
<Tonio_> mooey: okay so that's probably known....
<Tonio_> I just keep my source packages in case reupload is required once fixed (shouldn't but anyway..)
<cjwatson> tkamppeter: easy, dude. Everything will be retried.
<zen> Can I ask packaging questions here, or should I take that elsewhere?
<Burgwork> zen: -motu
<zen> thanks
<Hobbsee> drat.  mvo isnt here.
<jsgotangco> too early!
<Hobbsee> likely, yes
<Hobbsee> the dist-upgrader disables unofficial repos - including unofficial mirrors.
<Hobbsee> if the mirror is containing the exact same content as the archive.u.c, then surely we could keep them in as well?
* Hobbsee wonders how broken au.a.u.c is today...
<Hobbsee> oh bloody hell.  30b/s is not an acceptable download speed.
<mjg59> Hobbsee: Well, if you will live in the bandwidth wastelands of .au...
<Hobbsee> mjg59: i get faster than that off the archive.ubuntu.com
<Hobbsee> and way faster off that unofficial mirror
<Hobbsee> deb http://mirror.pacific.net.au/ubuntu edgy main restricted universe multiver
<Hobbsee> se
<Hobbsee> mjg59: even that is extremely poor in australian standards
<Hobbsee> unless you're on dialup
<Fujitsu> I regularly saturate my bandwidth from Pacific and Optus, Hobbsee...
<Hobbsee> Fujitsu: huh?
<Hobbsee> Fujitsu: ahhh.  i knew it would be broken.  the au.archive... *is* the optus mirror
<Fujitsu> Hobbsee: I thought you would have known that...
<Hobbsee> i didnt - i'd not researched it, beyond knowing it was broken, and finding another mirror
<Hobbsee> ahhh, there we go.  downloading at 550 kb/s
<Hobbsee> much better.
<Hobbsee> fabbione: please see https://bugs.launchpad.net/ubuntu-bots/+bug/102715 when you get back
<ubotu> Malone bug 102715 in ubuntu-bots "ubuntulog is not in #ubuntu+1" [Undecided,Unconfirmed]  
<fabbione> morning
<fabbione> Hobbsee: ok thanks
<Hobbsee> fabbione: :)
* Starting logfile irclogs/ubuntu-devel.log
<jdong> nixternal: blurg, ktorrent 2.1.3 was released with a crashfix to the 2.1 series :(
<nixternal> I seen that
<nixternal> have you created a package yet?
<nixternal> you can flip it up to revu and see about getting it in, but it isn't looking so good truthfully
<fabbione> Hobbsee: all done
<fabbione> Hobbsee: logs should appear within the next hour
<Hobbsee> fabbione: great, thanks!
<fabbione> np
<jdong> nixternal: nah I don't think I'll try until feisty+1
<jdong> then -> backports
<jdong> it seems like they find new tiny bugs every other day that looks worthwhile for cherrypicking.
<dholbach> good morning
<Mithrandir> hi Daniel
<dholbach> hey Tollef
<poningru> daniel?
<poningru> wow never knew people here had real names
<poningru> ;)
<Mithrandir> heh
<poningru> Mithrandir: quick question
<poningru> re: RC
<poningru> is there going to be a 'release'
<Mithrandir> yes, it's going to be mailed to either u-d-a or u-a and we're going to freeze and all
<poningru> oh do you want us to do a walkthrough of features kinda thing?
<poningru> I mean it would be kinda pointless
<poningru> but then again a release candidate walkthrough would get lots more testing
<dholbach> dmsetup seems to need to depend on initramfs-tools
<dholbach> or something
<Mithrandir> poningru: do you think marketing-wise or testing-wise?
<Hobbsee> hey dholbach, Mithrandir 
<Mithrandir> Hobbsee!
* Hobbsee hugs Mithrandir :)
<dholbach> hey Hobbsee
* Mithrandir bounces.
<Hobbsee> hey dholbach!
<Hobbsee> Mithrandir: why are you bouncing today?
* Hobbsee puts some lead in Mithrandir's shoes
<Mithrandir> I'm barefooted so far. :-P
<Mithrandir> we're getting close to release!  I can soon sleep again!
<dholbach> Mithrandir: do you think that dmsetup should depend on initramfs-tools?
<poningru> Mithrandir: well both really... with regards to marketing it would be kinda lame to put out a 'release notes walkthrough style' for a release candidate since it would be essentially a copy of the final release notes, but on the other hand from the testing pov it would be good since puting out a release notes would boost testing especially for a release candidate
<dholbach> Mithrandir: the build failures of regexxer and bughelper seem to suggest that
<poningru> Mithrandir: thoughts?
<Mithrandir> dholbach: that's fixed, but the buildds are slightly busted ATM; Adam's working on fixing it.
<Mithrandir> poningru: just use the same one for RC and release?  The feature set should be very much the same.
<poningru> right
<poningru> thats what I am saying
<dholbach> Mithrandir: ok - thanks a lot
<poningru> it would be pretty lame to put out two release notes
<Mithrandir> I'd be fine with that, at least.
<poningru> that are exactly the same
<Mithrandir> yeah, wouldn't make much sense.
<poningru> right
<Mithrandir> just think of it as having a release candidate for the notes too?
<poningru> uh... clarify?
<poningru> didnt make sense to me
* Hobbsee stomps on Mithrandir's toes then
<Hobbsee> Mithrandir: yay!  then there's feisty+1 :P
<poningru> Hobbsee: hehe
<Mithrandir> Hobbsee: I'm already sitting with my feet underneath me, so that would entail jumping into my lap. :-P
<poningru> I wanna know what the name of that will be
<Hobbsee> Mithrandir: hrm....
<poningru> !!
* poningru walks backwards slowly
* Hobbsee  pours icecubes down your back, instead
<Mithrandir> poningru: release notes can have bugs too, so just do "we think those are final" and leave the week for any bugfixing.
<ajmitch> Hobbsee: you're so kind..
<Hobbsee> ajmitch: indeed
<poningru> !lart @28 ajmitch 
<poningru> BUUUH????
<ajmitch> poningru: sorry?
* Hobbsee attacks poningru with the Long Pointy Stick of DOOM!!!!!!!!!!!!!!! 
<poningru> eek
<poningru> ajmitch: testing out ubotu but guess they changed the commands on me
<Fujitsu> poningru: It's @lart, and doesn't work in most channels.
<dholbach> ajmitch: done
<poningru> Fujitsu: ah that I did not know
<ajmitch> dholbach: yay, thanks :)
* ajmitch doesn't want to lose people
<janimo> can someone take a look at what's wrong with https://launchpad.net/+builds/+build/316111  and force a rebuild if possible? thanks
<Mithrandir> janimo: the chroots are broken atm, we're working on it.
<janimo> Mithrandir: ah, ok
<tepsipakki> ds: I found the upstream commit for the radeon UYVY-bug
<pitti> Good morning
<Hobbsee> heya pitti 
<viviersf> silly q, is any1 having problems using debootstrap :/
<Mithrandir> viviersf: yes, stuff's broken, we're working on it
<viviersf> okies :) thx just wondering
<janimo> pitti: hi, is the box you got the gnome-mount crash an x86?
<pitti> janimo: no, amd64
<pitti> janimo: this was a really weird one
<pitti> janimo: getenv("SUDO_UID") returns an invalid pointer
<pitti> janimo: I have no idea why, just that it doesn't happen with the previous version
<pitti> janimo: I didn't manage to debug it so far (I'm pretty ill, sorry)
<janimo> pitti: np, I hope you get well soon
<janimo> weird bug indeed.
<pitti> janimo: do you get it, too?
<janimo> pitti: no, I am on x86
<janimo> but I'll look at the code and see what it could be. gnome-_program_init is changed to gtk_init that may affect it
<pitti> janimo: ah, maybe that mangles the environment somehow
<janimo> pitti: although the crash happens at the start of main() way before gtk_init is called.
<janimo> so it may be related to the shared libs linked in some way, as the gnome ones are missing but I cannot see how
<fabbione> iwj: ping?
<Lure> pitti: reminder for digikamimageplugins MIR - I suspect we can only do it before main freeze
<mdke> dholbach: I've added translations to ubuntu-docs, can you take a look today and maybe upload? I've tested, it seems to ork
<mdke> ever better, it works too
<mdke> dholbach: best to reply by email, I'll be off irc during the day. Thanks in advance!
<kwwii> dholbach: I commited changes to GDM (HumanList theme) and Human Icons
<fabbione> hey Keybuk 
<fabbione> Keybuk: i think i found a bug in the last devicemapper stuff
<fabbione> root@diapolon:/etc/udev/rules.d# cat /proc/partitions |grep 64
<fabbione>    8    64   20039544 sde
<fabbione> root@diapolon:/etc/init.d# /sbin/devmap_name 8 64
<fabbione> Command failed
<fabbione> so basically i have no dm-* anylonger
<Keybuk> fabbione: no module?
<Keybuk> ahh
<Keybuk> no, you've mis-interpreted the arguments to devmap_name
<Keybuk> the arguments are the major and minor number of the devmapper device
<fabbione> Keybuk: the module is there
<Keybuk> not the underlying device
<Keybuk> cat /sys/block/dm-*/dev
<Keybuk> and try devmap_name with those major/minor as arguments
<fabbione> there are no dm-* :)
<Keybuk> are there any dm-* in /sys/block ?
<fabbione> nope
<Keybuk> sure
<Keybuk> ?
<fabbione> yes
<Keybuk> can you paste me ls -l /sys/block
<Keybuk> (so you don't have a /dev/mapper either?)
<fabbione> root@diapolon:/dev/mapper# ls
<fabbione> control
<Keybuk> ok
<Keybuk> paste me your /etc/udev/rules.d/25-dmsetup.rules
<fabbione> this is from this morning upgrade
<Keybuk> siretart: pin
<Keybuk> +g
<siretart> Keybuk: yes?
<Keybuk> siretart: did everything we did last night work for you?
<Keybuk> has anything broken for you over night?
<siretart> Keybuk: after installing your test udev package and adding that option to the evms rule, I'm happy again with my system :)
<siretart> Keybuk: even creating snapshots works reliably now. I can finally use sbuild again :)
<Keybuk> Nafallo: did you get a chance to test?
<Keybuk> siretart: snapshots was the first thing I fixed
<siretart> Keybuk: and the last thing I tried. it managed to break my lvm metadata more than one time, and I had to boot a live cd to restore it :/
<Keybuk> what's that?
<Nafallo> Keybuk: nope. my last client suffers from a broken PSU it seems, so I don't dare to reboot the headless server ATM :-/
<siretart> what's what? lvm metadata?
<Fujitsu> siretart: snapshots work? Yay
<Fujitsu> *!
<Keybuk> siretart: what's the last thing you tried that broke?
<siretart> Keybuk: the last problem I had was that broken evms rule, I think
<Keybuk> ah, your break your lvm metadata was *before* the fixes were applies?
<siretart> yes, that was weeks ago
<Keybuk> I interpreted that as you've done something since the "fix" that broke it?
<Fujitsu> s/last thing/last time/, I presume.
<siretart> nono
<siretart> I just wanted to say that I didn't try creating lvm snapshots in the last weeks
<siretart> because I made bad experiences with it
<siretart> I tried it yesterday, and I'm pleased to say that it works reliably for me now
<Keybuk> :)
<Keybuk> yay
<Keybuk> and I actually think I understand lvm now
<siretart> :)
<tkamppeter> Keybuk, iwj, is the build server back working?
<Keybuk> tkamppeter: there's nothing wrong with the build server that I'm aware
<siretart> next step (for goofy, not feisty): root on dmcrypt on lvm on md. anything else what we could add to that? ;)
<\sh> siretart: you are crazy ;-)
<tkamppeter> Keybuk, this dmsetup problem when it sets up the chroots about which I talked yesterday
<Keybuk> tkamppeter: that's just a package problem
<Keybuk> siretart: what's the difference between dmcrypt and cryptsetup?
<siretart> \sh: actually, I don't even consider it too crazy
<tkamppeter> Keybuk, is this fixed?
<infinity> tkamppeter: Yes.
<infinity> tkamppeter: Fixed a short while ago.
<siretart> Keybuk: cryptsetup is the userspace tool which drives the dm-crypt module in the kernel via libdevmapper
<Keybuk> siretart: ah
<Keybuk> siretart: encrypted filesystems is certainly on the +1 list
<siretart> :)
<Keybuk> and in theory, the changes that finally seem to be starting to work allow infinite filesystem stackage
<Keybuk> so you could have LVM-on-MD-on-Crypt-on-LVM-on-MD-on-SAN
* fabbione will start pushing * on * and include multipath
<dholbach_> mdke, kwwii: will do
<siretart> Keybuk: could you perhaps summarise what you did to fix the race? what did actually race here?
<tkamppeter> Mithrandir, can you then put a "give-back" (Pitti told me that this is needed to be done by you) to the packages hplip_1.7.3-0ubuntu1 and cupsys-1.2.8-0ubuntu2 on the build server, so that the do the builds which failed because of yesterday's dmsetup problem?
<tkamppeter> infinity, thanks for the fix.
<Mithrandir> tkamppeter: already done.
<tkamppeter> Mithrandir, thanks.
<dholbach> kwwii, mdke: will do
<pitti> Mithrandir: yay, live system has the hwdb notification now; I guess because the postinst is set -x now :-P
<pitti> Mithrandir: (I guess the images just lagged behind after livefs.sh was fixed)
<Keybuk> siretart: so, err
<Keybuk> right
<Keybuk> one asks libdevmapper1.02 to setup a device in the kernel for you
<Keybuk> that does the ioctl() and then called mknod()
<Keybuk> the ioctl() creates the block device, triggering a uevent which udev acts on
<Keybuk> if udev and devmapper try and make the same block device, they can hurt each other
<Keybuk> either you make udev not touch it (the edgy solution)
<Keybuk> or you make devmapper not touch it
<Keybuk> we've made devmapper not make the device, instead if udev is running it spins until the device shows up
<Enola_Gay> hi all
<Keybuk> udev then has rules to obtain the intended name from the kernel, and make the device
<Mithrandir> pitti: the archive hasn't really been well for a couple of days, but it should recover today.
<Keybuk> (yesterday evening's fix was to make udev *not* replace random characters like '|' in the names for those devices)
<Keybuk> this gives us race-free devmapper device creation, and useful events to tell us they're ready
<pitti> Mithrandir: so, I'm happy now for this hwdb spec of doom :)
<Keybuk> on those events, and any other block device which looks like it's an md or lvm member, we can run mdadm and lvm
<Keybuk> and since those result in new block devices, those events can also cause mdadm, lvm, etc. to be run
<Keybuk> the evms fix was that it only responded to new block devices, and not changes to existing block devices
<Keybuk> (err, I think that's it)
<lifeless> will upstream recognize their code now ?
<Keybuk> we hardly changed anything
<Keybuk> just the devmapper tweak to make it spin if udev is running
<lifeless> :)
<Keybuk> Mithrandir: so, err problem again
<Keybuk> dmsetup needs a particular version of udev
<Keybuk> how do I force an update to that version of udev, without making the whole lot Required again? :p
<Mithrandir> Keybuk: breaks?
<Mithrandir> Keybuk: as in, add a Breaks to dmsetup
<Keybuk> so Breaks: udev (<<) is fine?
<Keybuk> that forces an upgrade of udev?
<Mithrandir> AIUI, yes.
<Mithrandir> it's like conflicts, but less hard on the dependency graph.
<dholbach> kwwii: you deleted HumanList/Human.xml but did not add a new *.xml file
<dholbach> kwwii: can you check bzr unknowns for files you might have forgot to bzr add?
<Keybuk> Mithrandir: should udev declare the breaks, or should dmsetup declare it?
<Mithrandir> Keybuk: either can, but I think I would put it in dmsetup, since it's dmsetup that needs a newer udev, not udev that needs a newer dmsetup.
<Keybuk> right
<Mithrandir> Breaks is just a weaker Conflicts.
<pitti_live> mvo:  got a minute?
<pitti_live> mvo: I'm on current amd64 live; apt-cache policy nvidia-glx only shows the archive.u.c. source, it's not taken from the CD repo
<pitti_live> mvo: however, the cdrom is added in sources.list
<mvo> pitti_live: can you do a ls -l /var/lib/apt/lists please?
<pitti_live> mvo: oh, heh, wait; nvidia-glx isn't in ship-live, apparently
<mvo> pitti_live: ok
<pitti_live> only some avm-fritz-firmware stuff
<mvo> pitti_live: the next thing would be apt-cache gencache
<mvo> but if its not there thats a easy one :)
<kwwii> dholbach: cool, thanks for the info...I'll fix that
<pitti_live> mvo: right, apt-get install avm-fritz-firmware works
<pitti_live> mvo: well, downloading from archive is good enough, I think; the driver is huge, and CDs are full anyway
<mvo> ok
<dholbach> kwwii: alrighty
<mvo> fair enough
<pitti_live> mvo: so, sorry for the noise
* pitti_live hugs mvo
<kwwii> dholbach: yeah, I missed that in my bzr add command...comitting now
<mvo> pitti_live: no worries
<dholbach> kwwii: super thanks
<kwwii> dholbach: btw...thanks so much for all the help - without you there would be no artwork - I really appreciate everything (and your patience)
* dholbach hugs kwwii
<dholbach> kwwii: np - I hope we'll manage to make it all easier at some stage and you'll have more eager helpers in the ubuntu-art team
<kwwii> dholbach: actually, the ubuntu-art team is starting to look good again - feisty+1 should be a big improvement in that area
<kwwii> I even got troy to talk positively :p
<pitti_live> wow, enabling desktop-effects on the live CD now works surprisingly well; /me hugs seb128, mvo, and Mithrandir for the fixes for this
<seb128> pitti_live: rock on, and that's nothing compared to the version uploaded yesterday which probably didn't build yet ;)
<pitti_live> seb128: I saw that huge list of patches, yes
<seb128> what's going on with the buildds BTW?
<cjwatson> dmsetup needs a manual bootstrap - infinity said he was on it shortly some hours ago
<Mithrandir> cjwatson: that's fixed now.
<cjwatson> ah good
<Mithrandir> seb128: the chroots got busted, Adam fixed it and did a mass-give-back
<Mithrandir> I think he just gave back everything that failed, not just everything that failed in the last 24 hours
<seb128> Mithrandir: ok, thank you
<dholbach> kwwii: uploaded
<kwwii> dholbach: hug, hug ;-)
<dholbach> np :)
<kwwii> cjwatson: can you tell me in which package I can find the pic used in the very first screen of the installer? (grub, I assume)
<seb128> kwwii: are you going to change ubuntulooks or should I do it?
<seb128> kwwii: the panel 24x24 icon thing
<kwwii> seb128: might be better if you did it
<kwwii> seb128: if you don't mind, that is :-)
<seb128> ok
<seb128> not at all, it's quick enough
<seb128> gicmo: Alter!
<gicmo> ALTER!
<cjwatson> kwwii: you mean the CD bootloader? it's not in a package, it's in debian-cd bzr (http://people.ubuntu.com/~cjwatson/bzr/debian-cd/ubuntu) - procedure for improving it is to e-mail a new image to me
<cjwatson> kwwii: or actually, better, file a bug on the ubuntu-cdimage product
<iwj> fabbione: What can I do for you ?
<kwwii> cjwatson: cool, thanks...I'll check that out to understand the format and then file a bug asap
<fabbione> iwj: oh sorry.. i forgot to unping.. Keybuk did look into it
<iwj> fabbione: Oh, good.  lvm stuff again no doubt.
<fabbione> iwj: it's a problem with device mapper of some kind but it might be related to the buildd being a bit laggish
<fabbione> iwj: no lvm this time :)
<fabbione> iwj: basically i have no dm-* anywhere.. and udev events are a bit strange
<iwj> Mmm, so I see in scrollback.  Well, I'll let Keybuk carry on with it unless he gets bored ...
<fabbione> iwj: ehhe thanks anyway
<iwj> I have a bunch of mails from the buildds about `chroot problem'.
<Mithrandir> iwj: has been tended to.
<iwj> Excellent.
<kwwii> cjwatson: one question...do you know if it is still necessary to only use 16 colors or can I do a full 256?
<seb128> Mithrandir: could we get gtk2-engines-pixbuf added to the desktop seed or it's late for feisty? "Installed-Size: 240" and some themes need it (https://bugs.launchpad.net/ubuntu/+source/gtk+2.0/+bug/102797)
<ubotu> Malone bug 102797 in gtk+2.0 "gtk2-engines-pixbuf needs to be installed for pixmap themes (and it isn't by default)" [Undecided,Unconfirmed]  
<Mithrandir> seb128: sure
<seb128> Mithrandir: it's a binary package from gtk+2.0
<Mithrandir> go ahead and get it done
<seb128> ok, thank you
<dholbach> kwwii: what was that 24x24/categories/applications-graphics.png in h-i-t about?
<dholbach> kwwii: was that the one you wanted to drop?
<dholbach> kwwii: ah no, apparently not
* dholbach does another upload
<heno> Mithrandir: FYI, I've milestoned bug 91868
<ubotu> Malone bug 91868 in casper "Magnifier does not start from accessibility menu due to incorrectly referenced file." [Medium,Confirmed]  https://launchpad.net/bugs/91868
<heno> a fairly trivial fix
<cjwatson> kwwii: there are two formats, *.rle which is a super-weird format and is limited to 639x320x16 but only used as a fallback, and *.pcx which is 640x480x256
<cjwatson> kwwii: the latter's what most people actually see - if you give me an image in 16 colours, I can deal with fitting it into the former format
<cjwatson> kwwii: the latter has some restrictions with the menu positioning, so try to use roughly the same areas of the screen or I'll have to make irritating code changes
<Saied> all, i remastered Kubuntu feisty and got this error in boot stage : /bin/sh: can't access tty; job control turned off . how can i solve it?
<Saied> is it a bug?
<Treenaks> maybe you remastered it the wrong way?
<kwwii_> cjwatson: excellent, thanks :-)
<Saied> Treenaks: see : http://i7.tinypic.com/3y63ns3.png
<Saied> Treenaks: i followed instructions in this page : https://help.ubuntu.com/community/LiveCDCustomization/6%2e06
<Saied> Treenaks: everything was OK previous week but this week (with a update) this problem happened
<Saied> any idea about this problem?
<PhinnFort> does the grub that comes with feisty have the gfxboot patches applied?
<Chipzz> PhinnFort: I think it doesn't
<PhinnFort> :(
<PhinnFort> i thought feisty was all about the bling-bling
<PhinnFort> :P
<dholbach> can somebody of the devmapper maintainers fix libdevmapper1.02.postinst to check if /dev/mapper does not really exist before mkdir'ing it?
<dholbach> Keybuk, iwj: ^
<alex-weej> please can someone read this and suggest where i go next? 
<alex-weej> https://wiki.ubuntu.com/StandardisedHardwareSupport
<Adri2000> was the dmsetup/devmapper issue on the buildds supposed to be fixed?
<Adri2000> http://librarian.launchpad.net/7140668/buildlog_ubuntu-feisty-i386.filezilla_3.0.0%7Ebeta7-0ubuntu1_CHROOTWAIT.txt.gz
<Adri2000> cool, dmsetup is fixed, but now it's libdevmapper1.02 which is broken
<kwwii> dholbach: sorry, missed your earlier comment
<kwwii> dholbach: I added that pic because it looks a bit nicer than the brush alone for the applications-graphics pic
<kwwii> dholbach: we dropped the old version because it was ugly and blurry, but this one fixes that
* Adri2000 pings Mithrandir and Keybuk about the buildds being broken again
<Keybuk> dholbach: done
<iwj> seb128: How well do you understand system-tools-backend and the way it creates /etc/ppp/peers/ppp0 ?  I'm trying to add `noauth' by default but the tangled mess of crazy stuff in system-tools-backends-2.2.0/Network/Ifaces.pm has me baffled.
<seb128> iwj: I don't know system-tools-backend very well, but upstream is on the GNOME IRC usually, let me ask him
<iwj> Thanks.
<seb128> np
<iwj> I could go there and chat directly.  It's a fairly obvious thing for us to change ...
<iwj> seb128: irc.gnome.orc I take it - which channel ?
<seb128> iwj: #gst
<kwwii> cjwatson: ok, I've created a bug (#102840) and attached the pics
<kwwii> cjwatson: I think I'll leave the rle pics as they are 16 colors - anything I make would look different than the pics used in the rest of the distri anyway
<kwwii> ogra, Riddell : you guys might want to check the pics in that bug as well ( although they look the same as the usplash pics)
<ogra> thats fine with me 
<ogra> if they look the same after packaging them indeed ;)
<sladen> in Soviet Russia, they use WPA.
<StevenK> seb128: Do you mind if I upload a -0ubuntu2 of zenity, closing 2 of the 3 open bugs?
<seb128> StevenK: not at all, how complicated are the changes?
<StevenK> seb128: A 17 line patch into debian/patches, and adding 4 lines to debian/rules
<seb128> StevenK: looks good
<StevenK> seb128: Happy to throw the debdiff onto the Intarweb if you want to see
<seb128> StevenK: what bug does it fix?
<seb128> could you attach it to launchpad if it fixes an Ubuntu bug?
<StevenK> seb128: #50349 and #83549
<seb128> bug #50349
<ubotu> Malone bug 50349 in zenity "no man page for gdialog" [Wishlist,Confirmed]  https://launchpad.net/bugs/50349
<seb128> bug #83549
<ubotu> Malone bug 83549 in zenity "zenity zenity --text-info --editable crashes on 56K text file on stdin" [Low,Confirmed]  https://launchpad.net/bugs/83549
<kwwii> ogra: I certainly hope they look the same after packaging ;-)
<ogra> :)
<StevenK> seb128: I'll attach the debdiff to 83549
<seb128> StevenK: ok, thank you
<StevenK> seb128: Done.
<alex-weej> does anyone actually read ubuntu-devel-discuss, btw?
<seb128> alex-weej: I do
<seb128> alex-weej: why?
<alex-weej> that's good enough for me
<alex-weej> cause its volume is very low
<alex-weej> it seems all the same kind of banter goes on in devel-discuss, except that's closed to non-ubuntu-developer minions like me :P
<cjwatson> kwwii: thanks, can't really look today but will try to remember to look tomorrow
<cjwatson> alex-weej: devel-discuss isn't moderated in any way
<kwwii> cjwatson: excellent, thanks :-)
<alex-weej> sorry, i mean ubuntu-devel
<cjwatson> it's only moderated, not closed
<cjwatson> sensible posts will still be accepted (er, eventually anyway)
<alex-weej> heh, yeah
<cjwatson> but yes, the point of the moderation is to exclude non-sensible posts ;-)
<alex-weej> fair enough
<ogra> kwwii, would you mind joining -meeting for a moment ? 
<alex-weej> if i post my new spec to ubuntu-devel, will it be accepted?
<alex-weej> (the message, that is)
<cjwatson> alex-weej: maybe; see https://wiki.ubuntu.com/UbuntuDevelModeration
<cjwatson> so if it's "ideas and suggestions", it should be devel-discuss
<cjwatson> if it's something you're *actually going to do* it can be devel
<alex-weej> i don't know if /i/ can do it
<alex-weej> it's this https://wiki.ubuntu.com/StandardisedHardwareSupport
<cjwatson> then it should probably be on devel-discuss
<cjwatson> how is that spec not already satisfied by modaliases?
<cjwatson> oh, I see, you're talking about package installation
<cjwatson> it rather conflicts with the goal of being able to shift a hard disk between computers and have it continue to just work
<cjwatson> which is something we've actively pursued
<alex-weej> cjwatson: actually that can be address
<alex-weej> ed
<cjwatson> in any case, it should be on devel-discuss unless you have active clear development intentions for it
<alex-weej> if we adopt something like debfoster / gentoo's "world file"
<cjwatson> ubuntu-devel@ isn't a channel for wishlists
<alex-weej> i just need someone with a clue to help me out with the spec
<alex-weej> cjwatson: the only way hard disk transplanting would always "work" is if all hardware support for every device is always built in to the OS
<cjwatson> that is indeed the intention
<alex-weej> do you think that is realistic?
<cjwatson> and if you look at the kernel we're damn close
<cjwatson> yes, I do
<cjwatson> aside from different architectures obviously
<cjwatson> but that doesn't bother me
<alex-weej> proprietary drivers?
<alex-weej> that's already an issue which this would solve
<alex-weej> (which r-m is kind of solving)
<alex-weej> and also, this isn't just drivers, this is all of the tools including specialised volume mixers for high-end audio cards, video driver capplets, palm pilot sync, HPLIP Toolbox
<alex-weej> imagine having tools for every device under the sun all installed on your computer when you only use 1% of them :(
<cjwatson> there just aren't that many in userspace
<cjwatson> compared to the vast swathe provided by the kernel packages
<cjwatson> once x.org does autodetection that will fix some more issues like this
<alex-weej> right, but you can't expect one-size-fits-all abstracted userspace tools to efficiently do the job for 50 different mutations of the same device class
<alex-weej> it's the same reason windows graphics drivers have their own control panels
<mjg59> We can
<mjg59> In Windows it's hard for vendors to drive towards any sort of standardisation
<cjwatson> in any case, this is still a devel-discuss matter
<alex-weej> i think the first thing we need to concentrate on is hardware support in the first place
<alex-weej> let alone telling them that it needs to fit this specific mould
<cjwatson> anything where you aren't sure if you can do it counts as "ideas or suggestions" :-)
<alex-weej> ok cjwatson i read the wiki page, thanks
<cjwatson> funnily enough, we are concentrating on hardware support and continue to do so ...
<cjwatson> it's kind of important :)
<alex-weej> cjwatson: well basically, hard disk gutting isn't going to be affected by lack of my mobile phone support on the recipient system
<mjg59> We aim for almost all hardware to be supported by the default install
<alex-weej> right
<alex-weej> so that's a select range of hardware support packages installed by default
<alex-weej> but i don't have a Palm device, nor a HP printer
<alex-weej> and most computer users don't, either
<mjg59> The fact that these things are exposed as vendor specific is a bug
<mjg59> The additional cost of having them on your system is tiny
<StevenK> seb128: Are you happy for me to upload zenity?
<alex-weej> and with good hardware detection, it would be trivial to install the HSPs automatically
<seb128> StevenK: yep
<StevenK> seb128: Okay, thanks!
<seb128> np, thank you for the work ;)
<alex-weej> mjg59: tiny, but still an inconvenience - control centre is messy enough as it is
<alex-weej> even if HPLIP Toolbox was abstracted away and put into generic printer stuff that is useful to all printer users, i still don't have a printer!
<alex-weej> so i don't care!
<elmo> so, who here cares about ubuntu-bugs@lists.ubuntu.com and desktop-bugs@lists.ubuntu.com?
<Hobbsee> elmo: what about them?
<elmo> I want to know why we're archiving them, i.e. what the uses cases are
<cjwatson> alex-weej: good luck automatically detecting a printer that's switched off during installation and that's at the other end of a parallel cable
<Hobbsee> elmo: if the info's all on LP anyway, i've got no idea.
<alex-weej> cjwatson: Add/Remove Hardware?
<StevenK> elmo: seb128 may be able to answer for desktop-bugs@lists.u.c
<cjwatson> a lot of the time we install support for stuff because we *can't* automatically detect it in a reasonable way, and "install it when you find out you need it" is a pain in the arse if "when you need it" is when you're not on the network.
<cjwatson> add/remove hardware> ugh windows nightmare
<alex-weej> i've never had any nightmares with it, because i've only EVER had to use it to install an old MIDI joystick and a parallel printer
<seb128> elmo: no archiving need for desktop-bugs afaik, it's just useful for desktop team member to get bug mails
<pitti> arrgh @ continuing chroot problems
<alex-weej> cjwatson: i'm the last person you'll find singing Windows' praises, honestly :P
<ogra> pitti, ?
<ogra> i just successfully built a thin client chroot here
<ogra> no probs at all
<StevenK> pitti: Keybuk uploaded devmapper ubuntu10, when it builds, it should fine to requeue stuff
<pitti> ogra: I got 6 'chroot problem' buildd emails in the last 30 minutes
<ogra> oh, buildd
<pitti> StevenK: ah, fine; thanks
<ogra> i thought you complain about yesterdays debootstrap breakage
<StevenK> Oh grah, devmapper ubuntu10 has chroot problem
<StevenK> Hrm. Does this mean the buildd chroots need to be fixed manually?
<Hobbsee> StevenK: yes.  it's already been fixed
<pitti> Hobbsee: no, I don't think so
<pitti> StevenK: seems so
<seb128> StevenK: BTW for zenity, it's easier to use a zenity.links than using debian/rules hack
<Hobbsee> pitti: Mithrandir got infinity to fix it a couple of hours ago
<StevenK> seb128: Oh drat.
<ogra> seb128, is this ubuntulooks fix something i should have in the edubuntu themes as well ?
<pitti> Hobbsee: right, but I think this is a new problem
* StevenK wonders if he cares enough to upload
<Hobbsee> pitti: ahh
<seb128> ogra: dunno, what icon size do you use?
<StevenK> Hobbsee: Two seperate problems, same source package. Fun.
<ogra> seb128, i never set one ... 
<seb128> ogra: well, your icon theme ..
<ogra> so whatever was the default in the human gtkrc when i splitted off edubuntu themes
<seb128> ogra: does it use 22x22 like tango or 24x24 like human?
<seb128> what matters is the icon theme
<ogra> i think 22
<seb128> not the GTK one
<seb128> ok, so no
<ogra> ah, good
<seb128> gnome-panel expects 22x22
<kwwii> ogra: look at the menu and see if the icons look blurry
<seb128> and Human is 24x24
<seb128> so that's a hack to tell it to use the right size
<kwwii> ogra: and if it is, add seb128's change
<alex-weej> cjwatson: so should i just sit and wait for someone to approve/disapprove of my spec?
<ogra> gartoon seems to use 22, at least they dont look blurry
<Mithrandir> pitti: what's broken this time around?
<pitti> Setting up libdevmapper1.02 (1.02.08-1ubuntu9) ...
<pitti> mkdir: cannot create directory `/dev/mapper': File exists
<alex-weej> ah, is that why the panel icons are all blurry?
<Mithrandir> pitti: ugh.  Is this on all builds or just some?
<pitti> Mithrandir: apparently on all
<pitti> Mithrandir: Keybuk uploaded a devmapper -10 which will hopefully fix it, but it doesn't build due to that chroot problem. Yay chicken-egg
<pitti> Mithrandir: (http://librarian.launchpad.net/7140921/devmapper_1.02.08-1ubuntu10_source.changes)
<Mithrandir> pitti: ok, I'll get that fixed.
* pitti hugs Mithrandir 
<pitti> hi BenC 
<BenC> pitti: hey
<pitti> BenC: will you apply the patch in bug 93209 for feisty? if not, I'll need to create a per-arch solution in r-m, but that will take a while; that's why I need to know it soon
<ubotu> Malone bug 93209 in linux-restricted-modules-2.6.20 "Please ship proper modaliases for nvidia, fglrx & co" [High,In progress]  https://launchpad.net/bugs/93209
<BenC> pitti: Yep, that's what I'm working on now before I upload the lrm to accompany the -14 kernel
<pitti> BenC: ah, great; thanks
<iwj> seb128: I seem to be talking past garnacho in #gst.
<iwj> Perhaps you can help ?
<pitti> iwj: you scared him :)
<iwj> Evidently :-).
<iwj> seb128: Hi again.  Is your irc client working now ?
<seb128> iwj: yes, network working again
<iwj> Good.
<iwj> 14:10 <iwj> seb128: I seem to be talking past garnacho in #gst.
<iwj> 14:11 <iwj> Perhaps you can help ?
<seb128> (the 8029 network driver crashes every now and then)
<iwj> Nice.
<seb128> let me read the #gst backlog
<iwj> Thanks.  Sorry to drag you back into this ...
<seb128> np
<dholbach> Keybuk: thanks
<dholbach> kwwii: uploaded
<seb128> iwj: looks like the g-s-t architecture will not make that easy, the easier way might be to add a settings on the options tab
<dholbach> elmo: if it helps you can stop archiving universe-bugs too
<iwj> seb128: `tick this to make it work'
<iwj> I'm tempted just to rever the change to /etc/ppp/options.
<iwj> Anyway, lunch really before I die ...
<alex-weej> wiki updates are /damn slow/ :(
<alex-weej> seb128: you have marked a number of my bug reports as being due to a memory corruption - why would that happen? i ran memtest for a few passes and had no reported faults
<seb128> alex-weej: not a physical memory corruption, a program incorrect free() use or something like that
<alex-weej> oh, does that render the stack traces useless then?
<seb128> yes
<alex-weej> panties
<alex-weej> that's a darn shame
<alex-weej> i have so many unreproducable crashes
<seb128> use valgrind
<seb128> it lists incorrect memory uses
<alex-weej> i can't run valgrind on my entire desktop
<alex-weej> or can i? :P
<seb128> you can run app which are crashing with valgrind time to get a debug log
<seb128> it slow down things though :*/
<seb128> :/
<alex-weej> right, i see
<alex-weej> problem is, i can't always predict the future
<seb128> right
<alex-weej> it's a shame that unreproducable bugs are kind of second-class citizens in the bugzilla world
<seb128> they are not
<seb128> we can't work on something without datas on what happened though
<alex-weej> i understand this i'm not having a go
<seb128> I do use valgrind often
<alex-weej> sometimes when an app is misbehaving
<seb128> and we do get quite some logs with it
<alex-weej> it would be nice if i could take a memory dump, stick it on bugz and have someone probe into it to figure out why it's broken
<seb128> right
<seb128> that's sort of what apport is doing with standard crashes
<alex-weej> because for every crasher there is, there are just as many hangs/broken states
<alex-weej> yeah
<alex-weej> would it be possible to do that with current tools?
<seb128> let's already work on all the crasher we have datas on
<seb128> there is enough to be busy there :p
<alex-weej> and would it be beneficial if a developer could say "the next time it does this, run this tool and send me the dump"
<seb128> no, we don't
<alex-weej> as in even while the program is still running
<seb128> what we have is "run that app with valgrind, trigger the bug, send the log"
<alex-weej> i'm not just talking about memory corruption here btw
<alex-weej> i mean anything that might make an application "break" but not crash
<seb128> there is no magical way no
<seb128> anyway, I'm away for some time, later
<alex-weej> but a post-mortem coredump is just the same as any other coredump isn't it?
<alex-weej> as in you can delve inside and poke around
<alex-weej> ok, cya
<heno> pitti: apport is still switched on for the Live CD right?
<pitti> re
<pitti> heno: right, it's still fully enabled; I'm going to work on u-n to provide a gconf key for disabling it
<heno> pitti: could you join #ubuntu-accessibility for a sec?
<pitti> done
<iwj> Yes, having thought about it over lunch I'm going to change /etc/ppp/options instead of trying to deal with g-s-t :-/.
* kwwii would hug dholbach again but people are going to start thinking strange things :p
* dholbach hugs kwwii back ;-)
<TheMuso> pitti: bug 102909
<ubotu> Malone bug 102909 in apport "Apport on live CD is attempting to look in /rofs" [Undecided,Unconfirmed]  https://launchpad.net/bugs/102909
<pitti> TheMuso: thanks
<TheMuso> np
<Mithrandir> that's arguably a kernel bug, but it's easier to filter it in all the affected apps.
<Adri2000> Mithrandir: are you aware of the latest problem with devmapper? Keybuk fixed it but I think now it needs you: https://launchpad.net/ubuntu/+source/devmapper/2:1.02.08-1ubuntu10
<keescook> mornin' folks
<_ion> Hi
<seb128> Mithrandir: do we need your approval for GNOME 2.18.1 update next week or can I accept them?
<superm1> BenC, ping
* desrt adds some code to gnome-random 2.18.1 to make you cry if your username is "seb128"
<seb128> desrt: :-P
<dpm> hi, could anyone point me out to the ubuntu webpage where all dates for the several freezes and releases are listed?
<dholbach> dpm: http://wiki.ubuntu.com/FeistyReleaseSchedule
<dpm> dholbach: thank you very much
<dholbach> dpm: anytime
<desrt> april 19.  handy.
<desrt> that's exactly how much time i need to decide if i can live with 64bit or not :)
<geser> are the problems with dmsetup fixed now?
<Adri2000> no
<c5jr> april 19??!?!
<geser> Adri2000: do you know by coincidence if the failed builds because of dmsetup will be automatically retried of if the build admins need to be poked?
<Adri2000> geser: dunno, after the first dmsetup problem was fixed my builds have been retried but I don't know if it was automatic or not
<geser> Adri2000: nice, the fixed dmsetup doesn't build because of the broken dmsetup :)
<BenC> superm1: pong
<Adri2000> geser: yep, that's why we need Mithrandir!
<cjwatson> geser: not entirely automatically, but it's likely that there'll just be a mass give-back, which amounts to the same thing
<cjwatson> will everyone please stop panicking about buildds. this has been a public service announcement. :-)
<superm1> BenC, I didn't hear back from you last week regarding if lirc kernel patch could be applied
<superm1> BenC, is there a chance in it happening prior to kernelfreeze tomorrow still?
<BenC> superm1: Do I have that patch?
<BenC> I was pretty sure I cleared my patch queue
<superm1> BenC, i opened a bug on it 
<superm1> BenC, let me find it really quick
<superm1> BenC, bug 69534
<ubotu> Malone bug 69534 in linux-source-2.6.20 "Add lirc to linux-source build tree" [Undecided,In progress]  https://launchpad.net/bugs/69534
<geser> cjwatson: thanks, all I wanted to know if I have self to ask for give-backs or if someone does it once it's fixed
<BenC> superm1: I'll review it today, thanks
<superm1> BenC, thanks
<superm1> BenC, i'll be back on in about 30 or 40 min and then on the rest of the day, so just ping me if you have any questions then
<geser> seb128: do you know if the open sync request will be proceed in the next days?
<seb128> geser: I'll do them today, it's my archive day
<Burgwork> jono: pong
<BenC> Keybuk, iwj: ping, what handles the mapping codes in hotkey-setup? Like if there's a KEY_STOPCD, how does that get to say rhythmbox?
<Mithrandir> Adri2000: yes, I'm aware of it.
<Mithrandir> seb128: GNOME 2.18.1> standing approval.  If you have changes you want reviewed, please ask.
<seb128> Mithrandir: ok
<seb128> Mithrandir: so I can process the queue to accept the GNOME 2.18.1 updates? just to be sure we are clear ;)
<Mithrandir> seb128: generally, I prefer people to not accept their own packages, but feel free to nag me about it?
<mdke> pitti / seb128: around?
<pitti> mdke: yes
<mdke> pitti: hiya. We have a bit of a problem with language-packs/yelp
<mdke> apparently the translations of the front page are not showing up.
<mdke> seems that the relevant translations are in the language-packs, but yelp isn't using them because it isn't pulling the translations from the mo files into the relevant yelp infrastructure, which is /usr/share/yelp/toc.xml
<pitti> mdke: hm, does yelp use the normal .mo files?
<mdke> apparently not
<mdke> I mailed the yelp maintainer about it, I'll paste his response somewhere
<mdke> http://pastebin.ca/424318
<mdke> pitti: if you're able to shed any more light on that, it would be much appreciated. 
<pitti> mdke: right, so far I think it just helps to rebuild the source with the updated .po files
<pitti> mdke: danilos has a long-term plan how to fix this, but it's nothing for feisty
<mdke> I think yelp had a build recently though, is there something more that needs doing to ensure the po files are there?
<pitti> mdke: they have to be pulled manually from rosetta or the langpack and put into the source, I guess
<mdke> pitti: ah. Is that something that seb128 will know how to do / is accustomed to doing for other packages?
<pitti> I think so, yes
<mdke> I'll mail him and ask
<keescook> bleh.  my feisty builds are all stuck on the libdevmapper issue too.  *sigh*  Is there an easy work-around?
<mdke> pitti: unless you think there is a better way to proceed?
<pitti> mdke: I'm afraid not for Feisty
<pitti> keescook: we all suffer from that :/
<mdke> pitti: that's fine. I'll ask Seb then
<keescook> pitti: yeah, I read through the backlog
<keescook> I'm assuming all the chroot failures will auto-rebuild later?  I uploaded a mess of stuff yesterday that failed due to dmsetup...
<pitti> keescook: yes, we already had a mass-give-back today, we'll get another one
<Mithrandir> keescook: wait for Adam to wake up; If he's not done it before I go to bed I might consider fixing it myself, but it's stuff I've never touched before, so I would rather.
<Mithrandir> keescook: we will get a mass-give-back, yes.
<keescook> Mithrandir: okay, thanks.  Just wanted to be sure I didn't need to go dig through my reject email.  :)
<mdke> Mithrandir: btw, the ubuntu-docs translations went in today so you can see the size difference
<keescook> I think I can step around this on my own chroots by just dropping the /dev/mapper directory.  ;)
<Mithrandir> mdke: cheers.
<mdke> Mithrandir: 8.6MB as opposed to 447K (binaries) :(
<Mithrandir> mdke: .deb size?
<mdke> right
<Mithrandir> ugh
<mdke> yeah. It's all text... double the size of the edgy equivalent
<keescook> Riddell: do packages built against qt 3.3.8 need to get rebuilt against 3.3.8really3.3.7 ?
<_ion> How about compessing the docs with bzip2?
<Mithrandir> _ion: we could try that
<mdke> ok!
<seb128> mdke: hi
<mdke> seb128: hiya! Just mailed you
<seb128> mdke: updating yelp translations?
<seb128> I do that every cycle yes
<seb128> the .xml are generated at build time
<mdke> oh right, great to hear that.
<seb128> they don't use language pack
<mdke> seb128: hopefully it will work for the new frontpage stuff too
<seb128> mdke: I'll do an update now
* mdke hugs seb128 
* seb128 hugs mdke
<EtienneG> hey folks
<pitti> hi EtienneG 
<EtienneG> I'm working on bug #92432
<ubotu> Malone bug 92432 in bzr "index.html contains mainly broken links" [Undecided,Confirmed]  https://launchpad.net/bugs/92432
<EtienneG> there's two way to fix it
<EtienneG> one involve just the packaging
<EtienneG> the other, patching the upstream source
<EtienneG> fixing the packaging is the obvious solution, but that mean that we will end up with HTML documentation that end with a .htm suffix
<pitti> EtienneG: how come?
<EtienneG> it's not so bad ... just very ... windowish
<pitti> EtienneG: why are the links broken in the first place? due to the packaging?
<EtienneG> pitti, upstream decided that the html doc would end with .htm
<EtienneG> pitti, yes, the packaging made the link broken
<EtienneG> they work OOB
<EtienneG> in upstream
<EtienneG> I tend toward fixing the packaging and living with doc file that end in .htm suffix, but I am looking for the opinion of wiser people
<EtienneG> trivial, I know, sorry about the insecurity
<pitti> EtienneG: I agree, fixing all the links manually to .html sounds painful
<EtienneG> pitti, it would be a very small patch to upstream, but i would rather stick as close as possible to what they provide
<pitti> EtienneG: oh, something like 'sed -i s/htm/html' debian/bzr/usr/share/doc/bzr/*.html? :)
<EtienneG> pitti, no, the doc is in RST (yuck), we would just need to fix file names in a single file, index.txt
<EtienneG> the html are generated from this rst index.txt
<pitti> $ locate .htm|grep --count '^/usr.*htm$'
<pitti> 615
<EtienneG> goo dpoint
<pitti> EtienneG: you would be in good company, so I wouldn't worry too much :)
<EtienneG> hey !
<pitti> $ locate .html|grep --count '^/usr.*html$'
<pitti> 4362
<pitti> for comparison
<EtienneG> so, something like 15% of HTML doc are suffixed with .htm 
<EtienneG> I usually ask these trivial packaging question to Jeff in a watercooler talk ... but this have been impossible for the past month
<EtienneG> he's back next Monday, I can't wait !
<pitti> EtienneG: I'd say, keep it simple and safe and stick to .htm
<EtienneG> yep, my opinion too
<bluefoxicy> pitti:  I just sent an automagic crash report about xorg
<bluefoxicy> now what?
<pitti> bluefoxicy: well, wait for someone to care about it :)
<bluefoxicy> I was using the via unichrome driver suggested in https://bugs.launchpad.net/bugs/72630 and xorg crashed when I tried to activate desktop effects on Feisty; but it didn't ask me to fill any of that in and didn't give me a bug report #
<ubotu> Malone bug 72630 in xserver-xorg-video-via "Xorg Via driver DRI OOPS" [Undecided,Needs info]  
<bluefoxicy> probably a lot easier to debug if you knew wtf I was doing at the time :)
<pitti> bluefoxicy: filing the crash bug should direct you to the bug page in the browser
<bluefoxicy> it didn't open a browser and I didn't have one open.
<pitti> bluefoxicy: hm, sounds like one instance of the two or three 'firefox does not open' apport bugs
<EtienneG> I would need a sponsor for an upload of bzr
<EtienneG> fix #92432, approved by Mithrandir
<EtienneG> package is at http://people.ubuntu.com/~etienne/bzr/
<mvo> EtienneG!
<EtienneG> mvo !
<ajmitch> morning
<LaserJock> hi ajmitch 
<ajmitch> hey LaserJock 
<EtienneG> I reiterate my sponsor request for a bzr upload ... it's for a milestone, and I presume it need to get in ASAP 
<mvo> EtienneG: I can do it in 5 minutes if you don't have someone else
<EtienneG> mvo, thanks, I did not want to ask you specifically since I know how busy you are ...
<mvo> EtienneG: no worries
<mvo> ogra: ping
<mvo> ogra_: ping
<mvo> ogra, ogra_: please check my comment in #94712 when you have some time
<EtienneG> mvo, you're my man !    The package is at http://people.ubuntu.com/~etienne/bzr/, and it close bug #92432
<ubotu> Malone bug 92432 in bzr "index.html contains mainly broken links" [Undecided,Confirmed]  https://launchpad.net/bugs/92432
<mvo> EtienneG: doing that now
<EtienneG> thanks a lot
<EtienneG> it's getting chilly, I can already feel the freeze !
<james_w> Could anybody suggest the best way of getting in touch with mdz? Is email a good choice, he doesn't seem to be in here?
<mvo> james_w: email is a good choice
<james_w> thanks mvo 
<mvo> EtienneG: looks good, I take it that you tested it?
<EtienneG> mvo, yes
* mvo pats "gdebi debian/control"
<ajmitch> EtienneG: going to put your application in for MOTU to the MC sometime?
<EtienneG> mvo, if you debdiff, you can see it's really just the html doc stuff that got changed
<mvo> EtienneG: yes, I noticed :)
<EtienneG> ajmitch, yes ... I keep thinking about that ....
<mvo> EtienneG: I will give it a quick testbuild/test, but I don't expect any trouble
<EtienneG> ajmitch, my upload monkey (jbailey) really want me to get it, but I am somewhat insecure
<EtienneG> mvo, sure, and enjoy working HTML doc 
* mvo enjoys
<EtienneG> :)
<mvo> EtienneG: uploaded, bzr is the love
<EtienneG> mvo, thanks !
#ubuntu-devel 2007-04-05
<Riddell> keescook: no, except qt widget themes
<keescook> Riddell: okay, thanks.  mythtv is seeing a lot of crashes in qt libs :(  I was hoping for an easy fix.  :)
<geser> keescook: I'll try tomorrow to file an uvf exception for wordpress 2.1.3
<keescook> geser: cool
<Fujitsu> keescook: I attached an Edgy debdiff to bug #94238 two weeks ago, can you take a look?
<ubotu> Malone bug 94238 in mpd "MPD Critical bug, please update to 0.12.2" [Undecided,In progress]  https://launchpad.net/bugs/94238
<keescook> Fujitsu: sure, checking now
<Fujitsu> Are we meant to poke you once we've got a debdiff?
<keescook> Fujitsu: yeah, or rather, after you have a debdiff and have tested that the resulting package works and fixes the problem.  :)
<keescook> did you test the Edgy build?
<Fujitsu> I think so.
<keescook> heh
* Fujitsu checks in ~/pbuilder/results
<keescook> I should subscribe myself to motu-swat, it seems that just marking a bug as "security" doesn't subscribe ubuntu-security any more.  :(
<Fujitsu> I would have thought that it would have been a pretty fundamental thing for the security flag to do that...
<keescook> Fujitsu: it _used_ to, but it seems some changes recently undid that.  I have a bug open about it.
<keescook> Fujitsu: anyway, if it's been tested in Edgy, I'll happily publish it.
<Fujitsu> I'm testing it again now, but AFAICR it's fine.
<keescook> Fujitsu: okay, cool.  Thanks!
<Fujitsu> Thanks, it works fine.
<keescook> Fujitsu: oh, btw, that package uses "quilt" for patching.  :)
<Fujitsu> Hm, true. I should probably have checked that.
* Fujitsu rewrites the debdiff.
<keescook> Fujitsu: I've moved the patch around; I'll get it uploaded in a few minutes...
<Fujitsu> keescook: Thanks. I'm still trying to work out how I am meant to use quilt. Never seen it before.
<keescook> It's some crazy stuff.
<Fujitsu> It looks like it.
<Fujitsu> I can see why I didn't notice it had a patch system: I normally just look for a debian/patches.
<pochu> Hey everybody! Little question: Does the frozen also affects the Universe?
<_ion> It's usually nice to put the quilt stuff to debian/patches, though.
<_ion> That's also the canonical cdbs' patchsystem-quilt way.
<Fujitsu> _ion: In this case, it had quilt included in debian/rules, but didn't actually have any patches, so the only way to notice that it had a patch system was by looking in rules.
<Fujitsu> pochu: We'
<Fujitsu> *pochu: We're not in deep freeze for another week.
<pochu> oh, cool :)
<pochu> I thought we start today
<pochu> Oh, Main is frozen since today, but not Universe, right? :)
<Fujitsu> Yep.
<Fujitsu> Thanks keescook.
<keescook> Fujitsu: no problemo!  :)
<keescook> sorry I missed it for so long.  I need to find a better way to get notified about pending debdiffs.  :)
<sbalneav> Any of the K developers in here?
<sbalneav> Riddell: pingity?
<sbalneav> Hobbsee: Are you involved with the KDE side of things?
<Hobbsee> sbalneav: yes
<sbalneav> Ah, perfect.  You wouldn't happen to know anyone who manages the kde-games package, would you?
<sbalneav> We've got someone who just pointed out that ktuberling (potato guy) can have a cigar put on him.  He's working on a native reserve, and they try to stay away from showing the kids any kind of addicting behavior, and he asked if it could be substituded for something else.
<sbalneav> I'm thinking "carrot".
<Hobbsee> sbalneav: upstream people.
<Hobbsee> sounds good to me
<sbalneav> ok, I'll talk to upstream.
<sbalneav> thx
<Hobbsee> sbalneav: they're involved in kde4 - so i'm not sure if they'll change kde3 stuff
<Hobbsee> sbalneav: i dont know anyone within kubuntu/debian who actually modifies it, beyond packaging
<sbalneav> I'm grabbing the source right now.  May be able to apply a patch if I'm fast enough. :)
<Hobbsee> :)
<andrei> If I wanted to ask about my SoC application who would I ask?
<glick> hi
<glick> hey why doesnt ubuntu give the option of reiserfs on a fresh install?
<mdke> does anyone know how I can test yelp from a terminal and pass it a different locale to my system one without actually logging in with a different language?
<geser> mdke: doesn't the usual "LANG=another_locale yelp" work?
<mdke> doesn't seem to
<mdke> maybe I'm using the wrong "another_locale"
<mdke> I've tried it and it_IT
<mdke> and it_IT.UTF-8
<minghua> mdke: try LC_ALL=xxx yelp?
<minghua> (although if LC_ALL works but LANG doesn't, there's something strange in your locale setting)
<mdke> minghua: no, that doesn't work either.
<mdke> I'll install language support and login with something else
<minghua> mdke: is "it_IT.UTF-8" in your "locale -a" output?
<mdke> it is now, I suspect it wasn't before
<mdke> anyway, works
<pitti> Good morning
<Burgundavia> morning pitti
<pitti> Hey Burgundavia!
<ogra> mvo, hey
<mvo> hey ogra
<mvo> hey glatzor
<glatzor> morning mvo!
<glatzor> mvo: damn, have you seen the build error?
<mvo> glatzor: yes, its a problem wit hthe buildds
<ogra> mvo, http://cdimage.ubuntu.com/edubuntu/daily/20070405/feisty-serveraddon-i386.list lists qcad and rasmol (just rsyncing to see if the list isnt lying)
<glatzor> mvo: so but the changes found it's way to feisty?
<mvo> ogra: ok, I check here now as well again with the current image
<mvo> glatzor: yes
<glatzor> mvo: sorry but I have to leave again,
<glatzor> fine that saved my day :)
<mvo> glatzor: also not build ye
* glatzor hugs mvo
<mvo> glatzor: :)
* mvo hugs glatzor
<mvo> glatzor: have fuN!
<ogra> i'm sure they were there during beta ... i wouldnt know any reason why they should vanish
<glatzor> mvo: work is always fun ... :/
<ogra> mvo, ogra@edubuntu:/media/disk/isos/edubuntu$ sudo mount -o loop feisty-serveraddon-i386.iso /cdrom
<ogra> ogra@edubuntu:/media/disk/isos/edubuntu$ ls /cdrom/pool/main/q/qcad/
<ogra> qcad_2.0.5.0-1-2_i386.deb
<mvo> ogra: can you please search for _usr_share_pixmaps_qcad.xpm and rasmol.xpm on the CD? is it there?
<ogra> yes
<ogra> in the icons dir
<mvo> ogra: I'm rsynincing the current image now and can debug it further
<ogra> it was there in beta as well
<mvo> ogra: ok, but it does not show? 
<ogra> right
<mvo> grumpf
<mvo> ok, I will wait until the CD is here
<ogra> i just see kturtle uses xpm as well, lets see if kturtle shows up
<ogra> (burning iso atm)
<pitti> how on earth did the desktop CDs grow by 8 MB in one night?
<ogra> pitti, ah, its not only edubuntu then, phew 
<mvo> too much collate
<mvo> cocklate
* ogra didnt look deeper yet but noticed as well
<pitti> chocolate?
<mvo> schokolade (/me hasn't had his first tea yet)
<ogra> chuckle late ?
* pitti jigdos and compares
<pitti> hey dholbach 
<dholbach> good morning
<pitti> dholbach: I just got your HUG day announcement from March 29
<pitti> yay ML delay
<mvo> hey dholbach!
<ogra> mvo, close the bug ... all there :D
<mvo> ogra: booth icons show here (in ubuntu) - is this edubuntu specific maybe?
<mvo> ogra: I close it happily :) what was the issue? or did it just resolved itself over time?
<ogra> even though i dont understand why they werent there in beta
<ogra> i must admit i havent checked the addon CD since beta ...
<mvo> ogra: no problem, it may well be that the icons weren't extracted in beta for some reason etc. good that its fixed now
<ogra> yeah
<ogra> :)
<pitti> ogra: ah, got it
* pitti blames seb128
<pitti> old CD:
<pitti> 449K    ubuntu-docs
<pitti> new CD:
<pitti> 8,6M    ubuntu-docs
<pitti> WTF??
<ogra> heh
<ogra> screenshots added ?
<Treenaks> translations?
<kwwii> hi dholbach
<kwwii> dholbach: can you think of anything that I have missed or that we still need to do?
<seb128> pitti: nothing to do with me
<seb128> pitti: ubuntu-docs has been translated
<dholbach> kwwii: apart from the list of bugs... dunno
* pitti cannot believe that it contains some 50 MB of translations now
<seb128> pitti: it was not translated before ....
<seb128> pitti: you can expect a translated xml taking as much as the english one, so you get english * number_of_translation
<kwwii> dholbach: cool, thanks :-) (just thought I should check with you)
<saispo> hi seb128 
<seb128> lu saispo
<dholbach> kwwii: if I come across anything, I'll let you know
<saispo> fine ?
<pitti> seb128: aah, I see -- it just has 50 copies of identical files
<seb128> pitti: not "identical" but yeah
<seb128> saispo: yes, I'm great, how are you?
<pitti> seb128: most of them seem to be identical to the C version (the untranslated ones)
<pitti> seb128: mind if I take a look at it and add some symlinking magic?
<saispo> seb128: yes fine, just a big freeze with latest feisty update and i don't understand why...
<saispo> i suspect X...
<seb128> pitti: I don't work on that package, you want to speak to mdke
<kwwii> seb128: did you see bug #84931? once quick and dirty solution would be to make GAIM use the simple text-mimetype
<ubotu> Malone bug 84931 in human-icon-theme "Various icons don't have a 16x16 icon size" [Low,Unconfirmed]  https://launchpad.net/bugs/84931
<seb128> pitti: I'm fine with it, the things is they can have 1 string translated
<kwwii> s/once/one
<pitti> mdke: can we talk about shrinking ubuntu-docs?
<seb128> saispo: while the update or happening all the time?
<seb128> kwwii: looking
<saispo> seb128: happening all the time since yesterday
<saispo> after near 10 or 15 minutes up under X, pc freeze
<saispo> i let the pc running all the night in console mode, no freeze...
<saispo> i have nothing in the log :/
<saispo> maybe nvidia driver...
<YokoZar> How long does it take an ubuntu-devel email to get moderator approval?
<seb128> saispo: what did you update yesterday? do you have anything to /var/log/{messages, syslog, Xorg.0.log}?
<seb128> kwwii: the bug is not limited to gaim though
<kwwii> seb128: right, but that seems to be the app that everyone is complaining about :-)
<seb128> kwwii: I can complain about nautilus if you want ;)
<seb128> kwwii: right click on the desktop
<seb128> the create directory option
<kwwii> lol
<seb128> what? ;)
<seb128> kwwii: would it be hard for you to do a 16x16 variant for that gaim icon?
<kwwii> seb128: about complaining about nautilus :-)
<kwwii> seb128: yeah, I'll look into that (and lapo is/was working on the small folders)
<seb128> ok, cool
<pitti> seb128: with symlinking duplicate files and using bzip2 I got it down from 9 to 2 MB already :)
<seb128> pitti: is there that many dup file?
<pitti> seb128: also, I would like to discard translations which are less than 20% complete
<seb128> pitti: that's weird that translations team have 0 strings translated
<pitti> seb128: only 6 MB of dups, not that much
<imbrandon> hey what does humboldt ( the ubuntu server ) do ?
<imbrandon> i have a ton of access from it in my logs
<seb128> pitti: I think dropping too much incomplete translations is ok
<saispo> seb128: i lost the ssh to my home... will see at 12:00
<seb128> saispo: ok
<Enola_Gay> hi all
<Enola_Gay> Does anyone know if Herd 6 will be released today?
<pitti> Enola_Gay: there won't be a herd-6, as Mithrandir announced on u-devel-announce
<Enola_Gay> So the next CD will be the release candidate?
<highvoltage> Enola_Gay: https://lists.ubuntu.com/archives/ubuntu-devel-announce/2007-April/000272.html
<Enola_Gay> Released on April the 12th?
<Enola_Gay> pitti: highvoltage: thx.
<Keybuk> seb128: around?
<seb128> Keybuk: yes
<Keybuk> Mark's laptop has an odd problem
<Keybuk> every time he logs in, something changes his current window manager gconf key to ~/.gnome-compiz-manager/openbox -- which doesn't exist
<Keybuk> I cannot find what's doing that
<Keybuk> this causes him to have no WM on startup, and I think is also causing gnome-session to hang on login
<seb128> does he has gnome-compiz-manager installed? does it happen without it?
<Keybuk> no, I purged that
<Keybuk> it still happens
<Keybuk> I changed the gconf key to just metacity, and when he logs in, it becomes gnome-compiz-manager again
<Amaranth> i recently noticed desktop-effects doing something that makes gnome-session hang for about 60 seconds after it loads compiz
<Amaranth> so, maybe that's it?
<seb128> Keybuk: gconftool-2 -g /desktop/gnome/applications/window_manager/default  ?
<sabdfl> peregrine% gconftool-2 -g /desktop/gnome/applications/window_manager/default  ~
<sabdfl> /usr/bin/metacity
<seb128> sabdfl: cat .gnomerc?
<sabdfl> export WINDOW_MANAGER=~/.gnome-compiz-manager/openbox
<seb128> that's it
<seb128> gnome-compiz-manager did that
<sabdfl> just delete it?
<seb128> yes
<seb128> I'll have a look at gnome-compiz-manager and get that fixed, thank you for the bug report ;)
<sabdfl> np :-) want it in LP?
<sabdfl> seb128: it may have been an older version that did it
<seb128> sabdfl: yes please
<seb128> sabdfl: current code seems to still do it
<seb128> Amaranth: what is desktop-effects doing?
<Amaranth> seb128: when it sets the gconf keys to make gnome-session start compiz
<Amaranth> on next login it loads compiz then 60 seconds later i get nm-applet and gnome-power-manager
<Amaranth> i remember seeing this once before then it went away
<Amaranth> seems to be back now
<Amaranth> dunno how i made it go away last time either
<seb128> weird
<ogra> Keybuk, on my thin clients i see a /dev/.static/dev mount "type nfs" what mounts that ?
<Keybuk> it's a bind mount of your old /dev
<ogra> i know
<Keybuk> so it's the same options/filesystem as your /
<ogra> but why is it type nfs
<Keybuk> because your root is nfs?
<Amaranth> seb128: i've gone almost 6 months without reinstalling, probably about time to do so :)
<ogra> well it shows up in mtab as separate nfs mount 
<Amaranth> i'm terribly hard on my installs :)
<Keybuk> ogra: the device part will be the same
<seb128> Amaranth: why would you need to reinstall, that's not windows ;)
<ogra> Keybuk, indeed, i'm just wondering if i could get rid of it ... to speed up ...
<Keybuk> (it shouldn't show up in mtab at all, perhaps you're looking at /proc/mounts ?)
<Keybuk> ogra: how would it speed anything up?
<ogra> right, mtab is a link on thin clients
<Amaranth> seb128: well, unless the system still works when i wipe /etc (or all of /etc can be regenerated) that's the only way i know to fix things
<Amaranth> oh, and to clean out my manual installs of things and to remove changes to grub and etc
<ogra> Keybuk, well, i assume there must be a mount process to mount it ?
<Keybuk> ogra: yeah, a call to mount --bind
<Keybuk> nothing more elaborate than that
<ogra> ah
<Keybuk> it's done in initramfs normally
<ogra> ok, thanks
<Keybuk> and postinst/devmapper/etc. will break without it
<ogra> ok, i wont touch it 
<ogra> i'm just searching for possible speedup areas
<sabdfl> seb128: https://bugs.launchpad.net/bugs/103246
<ubotu> Malone bug 103246 in gnome-compiz-manager "Gnome-compiz-manager thrusts itself into .gnomerc" [Undecided,Unconfirmed]  
<Keybuk> ogra: could you show me a bootchart
<Keybuk> I may be able to make some useful suggestions
<seb128> sabdfl: thank you!
<ogra> Keybuk, i probably could, but on that HW it will take an hour to boot then :)
<ogra> i'll try one ...
<ogra> wow, bringing up X takes ~20secs with bootchart running in the background
<cjwatson_> glick: the manual partitioner supports reiserfs just fine
<glick> oh
* ogra twiddles thumbs while waiting for stop-bootchart to finish
<cjwatson> glick: perhaps you were using Kubuntu 6.06 or 6.10 with the graphical installer, whose manual partitioner didn't support reiserfs?
<glick> so the ubuntu cd supports it
<cjwatson> sure
<cjwatson> as does Kubuntu now, in feisty
<glick> heh im still runnin dapper
<ogra> *twiddle* *twiddle*
<ogra> Keybuk, that thing should get a low spec HW mode
<ogra> oh, nice it just killed X ....
<ogra> "... out of memory error..." :)
<ogra> Keybuk, http://people.ubuntu.com/~ogra/feisty-20070405-1.png
<mjg59> 15 seconds from start to libata being loaded?
<mjg59> I think your problem here is that this machine is slow...
<ogra> mjg59, its a network boot ...
<kwwii> seb128: in every case I find of the missing 16x16 icons it is a matter of the app (or gtk or whatever) looking for files it should not be looking for
<ogra> the same machine boots on ltsp 4.2 in 20 secs
<ogra> (stopwatched including POST)
<seb128> kwwii: I doubt of it
<mjg59> ogra: That's still in the initramfs
<ogra> while ltsp 5 takes 68secs with the same measurement method
<seb128> kwwii: what do you expect? the app to resize a 48x48 icon to 16x16?
<mjg59> It's spending 15 seconds loading modules
<ogra> right
<kwwii> seb128: no, I expect it to use the correct action icons
<mjg59> Which can have nothing to do with the fact that it's on nfs
<seb128> kwwii: do you have an example with an icon name?
<ogra> and i suspect something is slow with our nfs implementation ... on a debian chroot (same ltsp code, different kernel) it takes 20 sec less
<mjg59> Oh, wait, sorry, I'm being really stupid
<mjg59> Of course that's off the rootfs
<ogra> right
<kwwii> seb128: one second, let me make sure I am not talking crap first :-)
<seb128> kwwii: ok
<mjg59> Well, it's easy for you to benchmark nfs performance between kernels
<ogra> i wonder why our nfs uses rsize and wsize values like 131072 ... 
<ogra> that seems pretty high
<Keybuk> ogra: nothing immediately obvious; almost all your boot is spend in modprobe!
<ogra> Keybuk, yes, we'll start to go for a -ltsp kernel in feisty+1 to solve that one 
<ogra> there is a lot in our kernel packages we dont need on a thin client ...
<Keybuk> tbh, I'm surprised you do it all this way
<Keybuk> I would make a small read-only image containing the filesystem and a kernel per unit
<Keybuk> boot the machine, it copies the image onto its disk over the network if it has changed, and mounts it, booting from it
<ogra> a kernel per unit ? 
<Keybuk> the image almost immediately starts X
<ogra> there is no disk
<pitti> seb128: bah, I don't really understand this complex ubuntu-docs thingy; I have to defer to mdke, I'm afraid
<ogra> and we iusually have no more than 64-128MB mem
<Keybuk> then just nfs mount it, but that will be quite slow
<seb128> pitti: what are you trying to understand?
<ogra> Keybuk, well, the thing is that the ltsp 4.2 kernel runs all this in a quater of the time we need for the same setup
<pitti> seb128: where and how the translated .xml files are generated from the C sources
<ogra> 20 second boots are obviously possible
<pitti> seb128: i. e. where we have to add the check for < 20% translated
<ogra> even with nfs 
<Keybuk> ogra: does it have a module-less kernel?
<ogra> no
<ogra> same as ours
<ogra> initramfs and kernel ...
<Keybuk> then compare the two
<ogra> same bootmethod and architecture for the whole thing
<ogra> thats what i plan to do for fsity+1
<seb128> pitti: ah ok, it's likely using xml2po
<Keybuk> go down line-by-line and work out how they're different
<ogra> yep
<ogra> there is a lot memory stuff thats dfferent ... i already took a glance
<Keybuk> "memory stuff" ?
<ogra> yeah, sizes
<ogra> and defaults ... i only took a short look at the diff between the configs
<Keybuk> "sizes" ?
<pitti> seb128: that command appears in three scripts which say 'don't use that yet', and none of these scripts are used
<ogra> Keybuk, i wont look that up now ...
<seb128> pitti: ok, so ask mdke or maybe dholbach
<dholbach> seb128, pitti: I don't know much about the ubuntu-docs build system - but I can take a look at it - what's thr problem?
<ogra> Keybuk, bug 97456, both configs are attached if you want to look
<ubotu> Malone bug 97456 in ltsp "eBox 2300 boots VERY slow with Ubuntu/LTSP-5" [Undecided,In progress]  https://launchpad.net/bugs/97456
<pitti> seb128: what concerns me more is that all the translated .xml files are already present
<pitti> dholbach: the source already has translated .xml files instead of building them during package build from C xml + po files
<pitti> dholbach: and I can't quite figure out how/when this is done
<pitti> dholbach: I want to drop translations which are less than, say, 20% complete
<kwwii> seb128: ok, you are right on the ones from the Human theme :-)
<pitti> dholbach: AFAICS, mdke runs the translation scripts manually before building the source?
<seb128> kwwii: ;)
<kwwii> seb128: it is a nasty hack, but I'll simply scale them down (we really should redraw them all for that size though)
<pitti> dholbach: erk, and I see svn add commands in that source, too
<Keybuk> ogra: nothing useful there
<seb128> kwwii: ok, thank you
<Keybuk> ogra: compare the chroots
<dholbach> pitti: I need to check - the last time I changed something in the build system has been a while since
<ogra> Keybuk, thats what i'm doing atm ... i cant change kernel stuff anyway now
<pitti> dholbach: I'll just wait for him, don't worry
<dholbach> pitti: mdke and his ubuntu-doc people worked on that mostly
<dholbach> ok
* dholbach hugs pitti
<dholbach> pitti: if you want me to take a look - let me know
<ogra> Keybuk, and thats why i asked for the udev nfs mount :)
<pitti> dholbach: well, if you actually understand the package, sure; if not, don't bother
<Keybuk> ogra: if you're looking for 150s, you're not going to find it in minor details
<ogra> Keybuk, i can only look at stuff i can fix before release ... and thats only minor stuff ...
<ogra> i wont get ben to invent a new kernel flavor for me before feisty ;)
<mjg59> ogra: Have you benchmarked nfs performance?
<mjg59> If not, do that before doing anything else.
<mjg59> Also, you're doing the comparisons on the same hardware on the same network against the same server, right?
<ogra> yes, thats on my list, i was just looking at the options we use by default and stumbled over the r/wsize options with an 131072 valus
<ogra> *value
<tepsipakki> ogra: try 8192
<ogra> which looks strangely big
<ogra> tepsipakki, i know what i *should* try ... i just wonder why we use such a default
<mjg59> ogra: Before playing with options, test that there's actually a difference in performance
<tepsipakki> right :)
<ogra> i dont want to put NFSOPTS in my pxelinux config if possible ;)
<ogra> (by default at least)
<mjg59> So far you have no idea whether or not there's actually a difference in the NFS speed
<ogra> well, no proven facts, no
<mjg59> So before trying things to improve the speed of NFS, veryify that NFS is actually slower
<pitti> mdke: I uploaded a new ubuntu-docs now with bzip2 deb compression and duplicate file symlinking; that shinks the deb from 9 to < 2 MB, but doesn't help so much for the live fs; we really need to throw out poorly translated documents
<pitti> Riddell: any idea about https://bugs.launchpad.net/update-manager/+bug/84717/comments/207 ?
<ubotu> Malone bug 84717 in update-manager "SRU: updates necessary for Kubuntu Upgrade Tool in Edgy" [Undecided,Unconfirmed]  
<Riddell> pitti: oh, he's just running it in a chroot 
<pitti> ah, no X socket then
<Riddell> pitti: the KubuntuDistUpgrade page suggests that for testers who don't have edgy to hand but want to help
<pitti> Riddell: ok, that should be fine then; any other remaining bugs?
<Riddell> pitti: not that I know of
<pitti> ok, so it gets high time to push that out, I guess
<Riddell> yay
<kwwii_> dholbach: I'll have an update for h-i-t in a bit (adding 3 16x16 icons)
<dholbach> kwwii: alrighty, I'll upload it once you're done
<freeflyi1g> /NICKLIST SCREEN
<kwwii_> dholbach: commited
<anti_pop> does any developer work on this bug: https://launchpad.net/ubuntu/+source/kdebase/+bug/47455
<ubotu> Malone bug 47455 in kdebase "KDM detected memory corruption" [High,Confirmed]  
<dholbach> kwwii: you forgot to change actions/Makefile.am - doing that now
<Riddell> anti_pop: not as far as I know
<kwwii> dholbach: ouch, sorry
<dholbach> np
<thekorn> pitti, dholbach: I added a patch to fix bug 99642
<ubotu> Malone bug 99642 in bughelper "apport eats bug summaries with quotes" [Medium,Confirmed]  https://launchpad.net/bugs/99642
<dholbach> thekorn: nice - will look into it a bit later
<dholbach> thekorn: thanks a lot
<thekorn> dholbach: no problem...
<gnomefreak> was the nvidia-glx + upgrade + geforce4 cards been fixed? Ive seen alot less complaints about it?
<dholbach> kwwii: uploaded
<kwwii> dholbach: and now I have commited an update for tango-common (and remebered to edit the makefile this time too)
<kwwii> just to keep you busy :p
<dholbach> kwwii: ok
<dholbach> kwwii: will do that later - lunchtime
<kwwii> dholbach: cool, thanks :-)
<kwwii> dholbach: enjoy your lunch
<dholbach> gracias
<dholbach> thekorn: uploaded
<thekorn> yeah!
<pitti> thekorn: rock, thanks
<pitti> dholbach: is there a freeze for universe wrt. syncs?
<thekorn> pitti: I hope that works...
<ajmitch> pitti: not yet
<pitti> ajmitch: ok, so syncs can be done the usual way unless it's a new upstream version
<ajmitch> yeah, and we're still approving UVF exceptions for universe
<ajmitch> they're sometimes necessary still 
<popey> what's the process for getting a package updated in feisty? I realise it's a bit late now, just wondered if its possible and what needs to be done?
<ajmitch> depends if it's in main or universe
<ajmitch> main is very much frozen
<popey> oh dear
<ajmitch> universe is close, but not quite there
<popey> libmtp
<popey> looks like it's in main
<ajmitch> I presume you mean a new upstream version, too?
<popey> yes
<popey> upstream has 0.1.5 http://libmtp.sourceforge.net/index.php?page=download
<popey> we have 0.1.3
<ajmitch> I think you'd be pretty much out of luck right now
<popey> very few dependencies
<ajmitch> 2 weeks till release
<popey> yeah :|
<popey> it's not for me, I'm answering a support ticket, will pass that info on, thanks
<xhaker> maybe you can get it into through backports..
<popey> what's the process for that?
<popey> do that after the release?
<xhaker> if there is demand, i'm sure jdong and the backports team will do it
<cjwatson> yes, once the next release is open and that version is available there
<popey> ok
<popey> thanks guys
<pitti> seb128: there are three universe packages still depending on libgtkhtml3.8-19, which is NBS; what do you propose?
<pitti> seb128: we have to remove NBS packages from the archive before the release, otherwise we violate the GPL
<seb128> pitti: I'll fix that now
<pitti> seb128: shall I write to -motu@?
<pitti> oh
<seb128> pitti: it's only 3 packages, I can handle it ;)
* pitti hugs seb128, ok
<carlos> pitti: hi, around?
<pitti> hi carlos 
<carlos> pitti: software-properties are not part of latest language packs
<carlos> pitti: at least for the GNOME ones
<carlos> but Launchpad is exporting them
<carlos> so I wonder whether those translations ended in KDE language packs
<carlos> which is wrong as those are shared between KDE and GNOME so I guess they should be in the shared ones
<mpt> pitti, you were asking a few days ago about weeks starting on Sunday vs. Monday ... That's not really a locale-specific thing, it's a user preference
<carlos> pitti: could you check?
<mpt> It's determined by locale, religion, your parents, etc
<pitti> mpt: ah, ok; it's changed to Monday by upstream in Feisty anyway, so I didn't need to touch it
<carlos> mpt: well, but we need to set our locales to the official setting in the locale country
<Mirv> carlos: it'd look like the translations are not in KDE, either: https://bugs.launchpad.net/ubuntu/+source/software-properties/+bug/102773
<ubotu> Malone bug 102773 in software-properties "l10n broken in the KDE frontend" [Medium,Unconfirmed]  
<carlos> the bug is that we don't have a way customise it
<pitti> carlos:  indeed, it's in KDE now
* ..[topic/#ubuntu-devel:cjwatson] : Development of Ubuntu (not support, even with feisty; not application development on Ubuntu) | #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 | Main frozen for release candidate preparation
<pitti> carlos: I'll take a look and find out why
<mpt> carlos, I know, it's one of those things that should have a locale default but user configuration, and has the former but not the latter
<mpt> (in Gnome)
<carlos> pitti: that .po files are shared between KDE and GNOME, so it's not a matter of moving it to GNOME
<pitti> carlos: right, it should go into the shared ones
<carlos> mpt: indeed
<carlos> pitti: ok, thanks
<Mirv> carlos: hmm okay you're right anyway, that bug I mentioned is wrong, it is available in KDE
<carlos> Mirv: that would be that the user is not using daily lang packs
<Mirv> carlos: most probably
<carlos> latest official packages in Feisty doesn't have software-properties
<carlos> Mirv: also, I found that the KDE UI files translations are not being extracted to hte .pot file
<carlos> so maybe that's also part of the problem
<Mirv> now if only we could translate the installer properly, but alas that seems undoable for feisty as the translation deadline is I guess today and the partitioning-related strings are just not translatable
<cjwatson> some of them are, but not all.
<cjwatson> sorry, ENOTIME
<Mirv> cjwatson: yeah, I understand the situation
<Mirv> not corrupting hard drives > completely localized
<cjwatson> quite so
<saispo> seb128: i try... i think it's an hardware problem :/
<doko> cjwatson: I really want to make an OOo upload in the next hours...
<cjwatson> which bugs?
<seb128> saispo: not cool
<doko>   * openoffice.org-core: Recommend nfs-common. Ubuntu #64813.
<doko>   * Re-merge generic menu icons names. Ubuntu #99779.
<doko>   * Build using neon25. Ubuntu #92345.
<doko>   * Build using internal copy of xmlsec. Ubuntu #45801.
<doko>   * openoffice.org-common: Depend on desktop-file-utils. Ubuntu #70105.
<doko>   * openoffice.org-style-default: Build it as a transitional package.
<doko>     Ubuntu #102690.
<doko>   * Import Fedora fixes:
<saispo> seb128: yep :/ the hardware have one month...
<doko>     - Fix crashes in Outliner::ImplHasBullet(). Ubuntu #96622.
<doko>   * Update ubuntu template documents.
<doko>   * Update human icon theme, contributed by Gabriel Hurley.
<saispo> seb128: i think it's the motherboard... an asus mn2pv-vm
<saispo> will see if somme issue in the bug tracker, but...
<saispo> i will try to disable acpi too
<dholbach> kwwii: tango-icon-theme-common uploaded
<asac> i have a list of baseline libs that upstream mozilla wants to develop against in future. Anything we want to add?
<asac> http://pastebin.mozilla.org/5897
<cjwatson> doko: that's fine, thanks, go ahead and upload that
<doko> cjwatson: ok, after the test build finishes.
<dholbach> asac: it looks ok to me
<dholbach> Mithrandir: could it be that bzr-gtk 0.15.2-0ubuntu1 got lost somewhere along the way?
<asac> fine ... then i will give green light.
<EtienneG> good <time of day> everybody
<EtienneG> I would need the help of an archive admin
<cjwatson> EtienneG: hello
<EtienneG> cjwatson, hey !
* cjwatson <- archive admin
<EtienneG> I had an upload of bzr-gtk done by a MOTU (crimsun) yesterday 
<asac> bdmurray: ping
<EtienneG> related to #102548
<EtienneG> it was about 18 hours ago
<cjwatson> version number?
<EtienneG> 0.15.2-0ubuntu1
<EtienneG> the upload is not showing up anywhere on LP ... I was kind of worried
<cjwatson> EtienneG: your uploader forgot to use the -sa switch to dpkg-buildpackage / debuild
<cjwatson> they should have got a reject message
<cjwatson> 13:30:13 DEBUG   Rejected:
<cjwatson> 13:30:13 DEBUG   Unable to find bzr-gtk_0.15.2.orig.tar.gz in the distribution.
<EtienneG> ha HA !
<EtienneG> I'll catch him later then
<EtienneG> thanks cjwatson 
<dholbach> EtienneG: if you pass me the source package, I can upload it for you
<EtienneG> dholbach, http://people.ubuntu.com/~etienne/bzr-gtk/
<dholbach> alright
<EtienneG> dholbach, thanks !
<dholbach> EtienneG: done
<EtienneG> dholbach, that was fast !
<dholbach> :)
* dholbach hugs EtienneG
<cjwatson> and accepted
* EtienneG hug dholbach and spread my awful germs to Germany
<EtienneG> cjwatson, generally, how long should we wait for an upload to show up before we go looking for help when such a case happen ?
<EtienneG> 12 hours ?  2 days ?  more ... ?
<cjwatson> the source should show up within 2 hours of upload at most
<cjwatson> (normally less)
<EtienneG> ok, that make sense
<cjwatson> at present the archive is frozen (see ubuntu-devel-announce) so source uploads require manual attention; that only changed today
<EtienneG> cjwatson, I was aware of that ... fortunately, all my packages have been taken care of in time
<StevenK> cjwatson: Just curious at this point, when does Mithrandir return?
<cjwatson> StevenK: Tuesday
<doko> cjwatson: (sorry, wrong channel) would like to update python2.5 to the 2.5.1 release candidate 1 today; see bug 103302
<ubotu> Malone bug 103302 in python2.5 "UVF exception for python 2.5.1" [Undecided,Unconfirmed]  https://launchpad.net/bugs/103302
<cjwatson> doko: ok, that's fine
<genii> Is there any tool/script to auto-generate things like Packages.gz Release and MD5 sums  etc when you are putting a new  package into a mirror you run?
<zul> apt-archive I think
<Treenaks> or falcon?
* Treenaks points at Seveas 
<genii> Thanks. I had to repackage the modem-hsfpci for a new brand of these winmodems. and i a have a Dapper mirror which I netboot from, wanting to put a dapper-freenet suite for this and have it install this package from a preseed. Being a headache
<StevenK> jdub
<StevenK> Oops
<pitti> cjwatson: hmm, I thought BenC was working on l-r-m for -14 with some more fixes?
<StevenK> Riddell, mvo: I've marked 90642 as a dupe of 90644. (file overwrite problem for qobex and qobex-dev)
<cjwatson> pitti: he's welcome to upload it. I need to get the CDs consistent though
<cjwatson> BenC: ^--
* genii pokes Seveas
<pitti> Mithrandir: could you please give-back notification-daemon on sparc?
<Riddell> StevenK: thanks
<Riddell> added to TODO
<genii> Treenaks Is falcon what they use already to package the main *buntu repos?
<Treenaks> genii: no
<StevenK> Riddell: It's already fixed, sorry I didn't mention.
<genii> Treenaks: Sorry not to "package the repo" But rather to organise and somewhat automate the indexing and generation of the Release Package,Package.gz , gpg keys and so on
* Hobbsee waves
<pitti> Keybuk: could you please give-back notification-daemon on sparc?
<cjwatson> genii: still no; that's done by Launchpad
<Riddell> StevenK: oh, great
<genii> cjwatson Thanks. 
<genii> Interesting. Is Launchpad itself open-source? I can find no information on the engine anyplace like Sourceforge for instance
<Hobbsee> genii: it's not
<genii> ironic
<doko> what's scim-thai? I only know Gin-Tai
<shawarma> genii: https://launchpad.net/faq <--- Search for "open source"
<gnomefreak> genii: LP is closed source atm
<gnomefreak> there was talk of making it open iirc
<genii> shawarma: Thanks.
<genii> gnomefreak Guess I'm stuck with writing some scripts to semi-automate then :)
<genii> Treenaks: Reading up on Falcon. Looks pretty good and luckily there is also a seveas repo for dapper, which is what the mirror is running. Thanks for the pointer
<Zorkmid25> you suck
<Zorkmid25> you suck
<Zorkmid25> you suck
<Zorkmid25> you suck
<Zorkmid25> you suck
<Zorkmid25> you suck
<Zorkmid25> you suck
<Zorkmid25> you suck
<Zorkmid25> you suck
* mode/#ubuntu-devel [+o cjwatson]  by ChanServ
* Zorkmid25 was kicked off #ubuntu-devel by cjwatson (flooding)
* mode/#ubuntu-devel [+b *!Zorkmid2@bas3-kingston08-1168066208.dsl.bell.ca]  by cjwatson
* mode/#ubuntu-devel [-o cjwatson]  by cjwatson
<sharms> cjwatson: people get kicked for giving us constructive criticism?
<kwwii> and I thought people only talked to artists that way
<\sh> pitti: where did you get the mysql 5.0.38 release?
<pitti> \sh: mysql-server-5.0 | 5.0.38-0ubuntu1 | http://de.archive.ubuntu.com feisty/main Packages
<\sh> pitti: well, yes, but where is the upstream version on mysql pages?
<StevenK> sharms: No, people get kicked for flooding, like cjwatson's kick message says?
<pitti> \sh: hm?
<\sh> pitti: 
<\sh> ompressed GNU TAR archive (tar.gz)		5.0.37	22.2M	Pick a mirror
<\sh> MD5: 26ed76facb58bdeae40c8310e337dde2 | Signature
<sharms> StevenK: Do I really need to tell you the definition of sarcasm? 
<\sh> this is from mysql download pages ;)
* mode/#ubuntu-devel [+o Hobbsee]  by ChanServ
* mode/#ubuntu-devel [+b *!*@bas3-kingston08-1168066208.dsl.bell.ca]  by Hobbsee
* mode/#ubuntu-devel [-b *!Zorkmid2@bas3-kingston08-1168066208.dsl.bell.ca]  by Hobbsee
* mode/#ubuntu-devel [-o Hobbsee]  by ChanServ
<pitti> \sh: oh
<pitti> \sh: they hid it pretty well, I added it to debian/README.Maintainers
<Hobbsee> sharms: i'm not sure that critisism could be labelled as constructive...
<pitti> \sh: ftp://ftp.mysql.com/pub/mysql/src/
* sharms notes that if he says something outlandish, and is obviously completely the opposite of reality, then it may have been meant as a joke
<Mirv> Hobbsee: sharm's comment was a joke, and he's hoping he wouldn't need to use the mighty ":)" to prove that
<\sh> pitti: ah thanks :)
* Hobbsee is just buggered.
<sharms> Mirv: thanks!
* Hobbsee was also using slight sarcasm herself..
<sharms> I think we are stuck in a vicious circle of sarcasm
* Hobbsee can just start booting people, if preffered :P
<sharms> back to bug triage
<seb128> cjwatson: I've just uploaded a totem update, 1 line change to fix the build
<shirish> Is it true that the next release name is going to be "greedy goose" ?
<Hobbsee> no
* Hobbsee wonders where people find such things
<cjwatson> shirish: when a release name is settled, it will be announced
<cjwatson> seb128: thanks
<shirish> Hobbsee: at slashdot :)
<genii> I'm partial to Temporal Tarsier
<Hobbsee> shirish: unless you find it announced on an official ubuntu devel mailing list, or ubuntu announce, it's not correct.
<cjwatson> doko: do we need openoffice.org-filter-binfilter on the CD? it's very llarge
<shirish> cjwatson: thnx
<Hobbsee> shirish: and of course, slashdot's *so* credible.
<Treenaks> goady gentoo ?
<\sh> pitti: did you see any fix for http://bug.mysql.com/bug.php?id={21322,25526,27294} ?
<shirish> Hobbsee: lol, but it would have been a fun name
<doko> cjwatson: no, AFAIK it was never on the CD. but you get strange errors trying to open documents which are only handled by the binfilters
<cjwatson> doko: it is on the CD
<doko> hmm
<cjwatson> doko: because openoffice.org depends on it, and openoffice.org-filter-binfilter is recommended by that
<cjwatson> this is new in feisty
<cjwatson> er, "because openoffice.org depends on it, and that's included in the desktop seed" I meant to say
<pitti> \sh: I didn't check
<cjwatson> doko: I'm not entirely keen on splitting up the seed into -core -base -writer etc., because those package names seem more liable to change
<doko> cjwatson: ohh, debian change. hmm, ok, removing the depends and making it a recommends
<cjwatson> doko: thanks
<\sh> pitti: well, patch is again not commited from upstream...
<doko> cjwatson: do you need that before the rc?
<cjwatson> doko: yes please, it's 10MB on the CDs
<shirish> Anybody knows when there is going to be testing xserver-xorg-video-i810-modesetting drivers in Ubuntu?
<cjwatson> doko: I haven't accepted your previous upload yet, so another quick upload would save a build cycle
<doko> cjwatson: ok
<cjwatson> thanks
<doko> cjwatson: same version number ok?
<cjwatson> could you bump it?
<\sh> pitti: when I create a patch, can you take a look at it...and think about a new upload of 5.0.38 for feisty? :)
<pitti> \sh: of course
<\sh> pitti: cool :) 
<\sh> pitti: forget it, they fixed it, without mentioning it in the changelog...
<pitti> \sh: ah, cool
<\sh> pitti: now I'm backporting it to dapper ;)
<genii> Not cool, all changes should get documented in the changelog. 
<\sh> genii: tell it to mysql
<doko> cjwatson: uploaded
<cjwatson> cheers
<\sh> hmm..I need to build a new wine...stres
<kwwii> Seveas: seen bug #102738 ?
<ubotu> Malone bug 102738 in Ubuntu "Feisty Boot Screen Error" [Undecided,Confirmed]  https://launchpad.net/bugs/102738
<genii> I'm pretty sure there are more important things to work on than fixing the progress bar LOL
<kwwii> Seveas: never mind, I think I found the problem
<kwwii> genii: really, why? I would say that the graphical presentation of Ubuntu is at almost as important as the functionality
<genii> kwwii However, relatively, it is a minor thing compared to say misconfigured base packages etc
<cjwatson> genii: I think you have a confused view of resources. Given that there exist people dedicated to Ubuntu artwork, you can't just reallocate them to development
<cjwatson> genii: so saying "people should be working on packaging bugs instead" doesn't make sense. We work on both.
<genii> cjwatson: Well, if there is already a crew for that, so much the better :) It's their dept then
<cjwatson> genii: yes, and kwwii is heavily involved in it
<genii> Anyhow my boss just got here and we need to have a mtg etc and i'm on the front computer :) So can't go on at length atm
<genii> thanks for the archive info
<Hobbsee> Keybuk: how does one go abotu starting to debug https://bugs.launchpad.net/ubuntu/+source/netbase/+bug/102675/ ?
<ubotu> Malone bug 102675 in netbase "Feisty boot hangs on "Configuring network interfaces"" [Undecided,Confirmed]  
<Hobbsee> ie, why is dhclient even looking for these on boot, if NetworkManager is being started?
<StevenK> Because NetworkManager doesn't touch interfaces that are listed in /etc/network/interfaces?
<Hobbsee> yes
<Hobbsee> doesnt seem to, anyway
<Hobbsee> (that are listed to come up automatically, at least)
<StevenK> Which makes it unrelated to the problem
<Hobbsee> true - but it does mean that the solution of commenting them out doesnt actually work, because then NM doesnt find them
<Hobbsee> argh.  it seems that NM *does* require them listed in /e/n/i
<pitti> Hobbsee: actually it shouldn't
<StevenK> I have one interface in /etc/network/interfaces on my laptop, which is lo
<Hobbsee> pitti: right.  i'm afraid that it tends to, though
<StevenK> If it does, surely it's a regression?
<Mithrandir> pitti: notification-daemon> given-back
<pitti> Mithrandir: thanks
<Hobbsee> found it.
<Hobbsee> pitti: it all works as long as you remove/comment out *both* auto $interface, and the line below
<Hobbsee> if you only comment out the auto bit, NM wont pick it up
<Hobbsee> so, anyone who removes both lines of $interface is fine - it all works.
<StevenK> Hobbsee: I thought that was documented?
<pitti> Hobbsee: right, that's how it's supposed to work
<Hobbsee> may well be.  i didnt know about it, though
<StevenK>  /usr/share/doc/network-manager/README.Debian
* Hobbsee thought it was documented a little more obviously than that
<andrei> If I wanted to ask about my SoC application who would I ask?
<StevenK> The source code?
* StevenK ducks
* Hobbsee beats StevenK 
<StevenK> Ouch! 
<pitti> andrei: preferably someone who already reviewed it?
<Mithrandir> dholbach: bzr-gtk 0.15.2-0ubuntu1 seems to be in the archive just fine?
<dholbach> Mithrandir: now - we reuploaded and cjwatson accepted
<Mithrandir> ok
<andrei> pitti, I've no clue who reviewed it
<andrei> pitti, Have not heard back from them at all
<pitti> Mithrandir: that's another point I wanted to discuss with you? new langpacks right before or right after RC?
<Mithrandir> pitti: historically, it's been just after RC.
<pitti> Mithrandir: WFM
<Mithrandir> to give the translator the maximum time available.
<pitti> and in the unlikely case that RC == final, we can still update it later, so not much harm done
<Mithrandir> well, if we update the language packs after release, RC != final.
<Mithrandir> final will be what's in the RELEASE pocket on release day, we don't allow skew as we do for milestones.
<cjwatson> Riddell: http://www.ubuntu.com/products/GetUbuntu/ReleaseNotes?os=kubuntu&ver=7.04&lang=${LANG} - newz1000 is responsible for maintaining mappings from that to the actual release notes URL
<Riddell> cjwatson: right
<mvo> Riddell: we need something like this for the release-upgrader as text 
<dholbach> Seveas, pitti: could it be you forgot to push your changes to usplash-theme-ubuntu to bzr?
<pitti> dholbach: me?
<pitti> dholbach: oh, might be, yes
<dholbach> ok - I merged it in - just wanted to be sure I missed something
* dholbach hugs pitti and Seveas and kwwii too :)
<Riddell> mvo: that would be nice, at the moment it shows Ubuntu notes in Kubuntu
<cjwatson> Riddell: fixed
<cjwatson> thanks, that was the first I'd heard of it being broken :-/
<mvo> Riddell: I know ./
<cjwatson> Riddell: Ubuntu notes> yes, you'll need to talk to newz1000 about that
<cjwatson> oh, sorry, you mean the release-upgrader
<mvo> Riddell: sorry for that, we can't hijack the html version, but having a text-version would be good
<smo> hi
<smo> i i want to try to make a simple software whats the best softs and languauge to use in the beginning i know part of bash and php now for the moment....
<smo> i tried glade yesterday...then?
<Riddell> mvo: not your fault, it's too late to fix for feisty anyway
<Riddell> smo: see topic
<mvo> Riddell: lets make sure to put in on the table for feisty+1
<Riddell> mvo: sure
<smo> so which channel can i ask? please ... sorry...
<smo> what s the feisty's release date?
<Hobbsee> smo: #ubuntu
<Hobbsee> smo: and #ubuntu+1 for that
<smo> they don t know on ubuntu...
<Hobbsee> (april 19)
<cjwatson> smo: http://wiki.ubuntu.com/FeistyReleaseSchedule
<smo> ah maybe +1 i ll try thx
<smo> thx all
<smo> thx cj
<\sh> ok, time to go home
<seb128> cjwatson: could you accept the gtk+2.0 update? it's an another attempt to fix the "gnome-panel crash on update" bug which has a lot of dups
<\sh> happy easter to you all
<cjwatson> seb128: ok, will look
<DarkSun88> Hi all
* Hobbsee waves
<mdz> pitti: I think it's the right thing on almost all desktops, too.  if someone plugs in a network cable with link, it should come up
* Mithrandir tickles Hobbsee 
* Hobbsee tickles Mithrandir back and stomps on his feet
<Riddell> pitti: what chances of being able to NEW process the rest of the kde 4 packages today?  given the high failure rate it would be nice to have them checked before everyone is away on holiday
<pitti> Riddell: I might manage to do it tonight
* seb128 is away for ~1h
<kwwii> adios amigos
<dholbach> have a good time guys
<pitti> Riddell: erk, ./obj-x86_64-linux-gnu/lib/kio_lan.so and similar in kde4network source - that looks wrong
<pitti> Riddell: I hope the entire ./obj-x86_64-linux-gnu/ can be removed from the orig.tar.gz?
<Riddell> pitti: yes it can, that's probably all my fault
<jdong> seb128: can you help me look at bug 92069? Sounds SRU-ish to me?
<ubotu> Malone bug 92069 in edgy-backports "desktop-file-utils 0.12" [Undecided,Confirmed]  https://launchpad.net/bugs/92069
<_ion> * debian/rules, debian/bzr.install, debian/bzr.doc-base : changed suffix of HTML documentation to .htm to match upstream (Ubuntu #92432)
<_ion> *puke*
<Riddell> cjwatson: guy just responded on that ubiquity drawing bug that he was installing to a virtual machine on the mac, so something wrong with qt4 on virtual machines it seems
<bddebian> Heya
<cjwatson> Riddell: do you think there might be a workaround?
<pitti> Riddell: NEW is now free of KDE4
<pitti> some rejected, some accepted
<Riddell> cjwatson: none that I know of
<Riddell> cjwatson: hard to diagnose the actual problem without being to recreate.  I've not seen many reports of it though, I wonder if it affects vmwave
<Riddell> pitti: many thanks
<pitti> tepsipakki: hmm, there's a xserver-xorg-video-intel in source NEW
<pitti> tepsipakki: but since this is basically a new upstream version of -i810, this needs UVF exception
<pitti> tepsipakki: can you please mail Tollef (CC me) and get this sorted?
<pitti> tepsipakki: or better, CC: ubuntu-archive@lists.ubuntu.com
<ogra> pitti, do you also make RM stuff ?
<Lure> pitti: any chance to get this for feisty: https://wiki.ubuntu.com/MainInclusionReportDigikamImagePlugins
<pitti> ogra: no, Tollef does
<pitti> ogra: I'm just an archive grunt worker
<ogra> looked like :)
<bddebian> hehe
<pitti> Lure: argh, we are so heavily in freeze
<Lure> pitti: it would be nice to have it on dvd, but if it is too late, then it will not be end of world...
<pitti> yay, source NEW empty
* pitti -> off now, have nice Easter holidays everyone
<zyga> hey
<janimo> gpocentek: hi
<crimsun> janimo: the libxfce4* stack needs to be rebuilt to fix the startup-notification change
<crimsun> _ion and I noticed it with the xfdesktop4 upload last week
<janimo> crimsun: I am just doing that now :)
<janimo> since thunatr FTBFS-d today
<janimo> entered just to ask a second opinion
<janimo> crimsun: so rebuilding libxfcegui4-dev will do it I suppose
<janimo> no need to do atomic uploads of all packages and nastiness like that
<seb128> jdong: not a SRU no, the .desktop changes happened during the 2.17 cycle and don't concern edgy
<seb128> jdong: it doesn't break anything on edgy
<janimo> crimsun: as libxfcegui4 is the only lib that deps on libstartup
<jdong> seb128: oh, so the edgy version of desktop-file-utils works fine with edgy?
<seb128> jdong: correct
<jdong> then what would be the rationale for wanting a backport?
* jdong is a bit confused
<seb128> jdong: people building new GNOME on edgy
<jdong> ah, ok
<jdong> works for me then. thanks seb128!
<seb128> np
<crimsun> janimo: ah, brilliant!
<zyga> mvo: hey
<zyga> mvo: no progress on data extractor so far, small progress on reported bugs
<zyga> mvo: can you please merge from http://suxx.pl/~zyga/command-not-found--ubuntu-feisty-release
<janimo> Mithrandir: can you please approve libxfcegui4, it is needed to fix FTBFSs for other Xfce apps. It's a rebuild only as seen in the changelog
<cjwatson> janimo,Mithrandir: accepted
<janimo> cjwatson: thanks
<doko> cjwatson: please consider http://people.ubuntu.com/~doko/tmp/python2.4.debdiff for an upload
<cjwatson> doko: ok for upload
<carlos> Riddell: Hi, could you take a look to https://bugs.launchpad.net/ubuntu/+source/kdelibs/+bug/103394 ?
<ubotu> Malone bug 103394 in kdelibs "broken translations in Kubuntu Feisty (daily langpack)" [Undecided,Unconfirmed]  
<janimo> cjwatson: can you move hal-cups-utils to main, it has been in anastacia.txt for a while
<carlos> Riddell: I don't see anything wrong from Launchpad side, unless those strings don't come from kdelibs... 
<janimo> thanks
<Riddell> carlos: they do, I'll look at it
<doko> cjwatson: sun-java6 man page: the license doesn't allow changes ... I know, ridiculous ...
<_ion> doko: Shouldn't the patch check whether PyMem_Realloc succeeded?
<mvo> zyga: later, I need to run
<carlos> Riddell: ok, thank you
<cjwatson> doko: can we just not install that man page then? no man page is probably actually better than one that confuses man-db
<cjwatson> or can we not change the package *at all*?
<doko> _ion: did you read the docs?
<_ion> doko: Nope.
<doko> cjwatson: we do not change it ...
<doko> I can modify the postinst not to install the slave link
<cjwatson> janimo: done
<cjwatson> doko: maybe I'll have to incorporate the man-db fix then :-/
<_ion> doko: Ah, i just realized there probably *is* a check for the success of the function. I misread the patch and thought the PyMem_Realloc line was part of it.
<cjwatson> doko: ok, never mind, I'll backport the man-db fix
<cjwatson> the man page is still broken though, so if you could forward it upstream .
<cjwatson> ..
<doko> cjwatson: yes, notified tmarble
<cjwatson> thanks
<CarlFK> cjwatson: ping - feisty net install bug - got a moment, or should I just post to LP and email you?
<elmo> mjg59: ping
<mjg59> elmo: Hi
<elmo> oh, blah, just after I finish writing you an email ;-)
<mjg59> Ha
<adas> hello
<adas> I today upgrade a feisty and now Opera browser doesn't work... I don't know why...
<adas> when i run a opera in terminal:
<tepsipakki> bug 102851
<ubotu> Malone bug 102851 in libx11 "Opera failed after update - date 04/04/07" [Undecided,Confirmed]  https://launchpad.net/bugs/102851
<adas> ERROR: ld.so: object 'libjvm.so' from LD_PRELOAD cannot be preloaded: ignored.
<adas> ok...
<adas> but where i found a libx11-6 1.1.1-1ubuntu2 ?
<tepsipakki> read the bug
<tepsipakki> there are links
<tepsipakki> just use another browser until opera has a new release
<cjwatson> CarlFK: lp and mail, please
<CarlFK> ok
<CarlFK> while I have your ear - know where I can find docs for using openssh-server-udeb  in the installer? 
<cjwatson> CarlFK: no, I'm saying the above because you don't have my ear :) it's 22:35 in the evening and tomorrow is a holiday
<CarlFK> heh -  enjoy !
#ubuntu-devel 2007-04-06
<shawn_work> Question: When is launchpad source code going to be released? will it be?
<shawarma> Nothing's planned.
<gnomefreak> shawn_work: best to ask in #launchpad (some of it is open)
<shawarma> shawn_work: https://launchpad.net/faq <--- Search for "open source"
<shawn_work> merci
<shawarma> gnomefreak: Huh? Like what?
<gnomefreak> shawarma: read the page you gave him ;)
<gnomefreak> lol
<gnomefreak> hold on ill find it
<shawn_work> I See :(
<gnomefreak>  Our goal is to release all of Launchpad as free software, though it will take some time (potentially, years) before that happens.
<gnomefreak> We are doing so in a piecemeal approach. Parts of Launchpad have already been released as free software where they would be particularly useful to other projects. 
<shawarma> gnomefreak: Yes, but which parts?
<gnomefreak> shawarma: dont know never asked
<illovae> hello
<shawarma> gnomefreak: Ah, ok.
<gnomefreak> hi
<illovae> excuse me, LaserJock are you available please ?
<LaserJock> illovae: yep, what's up?
<illovae> LaserJock: hi, first sorry for my english but it is not my native language ^^'
<illovae> well i'm Hari Seldon from https://bugs.launchpad.net/ubuntu/+source/labplot/+bug/98547
<ubotu> Malone bug 98547 in labplot "incorrect category in 'Applications' menu" [Wishlist,In progress]  
<LaserJock> oh hi
<illovae> i've discuss of this bug with Adri2000 and mr_pouit and they told me there's nothing to fix...
<illovae> i am an beginner in fixing so i don't know what can i do with this
<illovae> i am interresting by you experience for closing it in the best way :)
<illovae> your*
<LaserJock> well, it's a bit of an unfortunate bug
<illovae> ^^
<LaserJock> technically, it should probably go in Education or Graphics
<LaserJock> unfortunately early on I tried to tackle the "Science has no menu" problem
<LaserJock> but it's really up to freedesktop.org
<illovae> yes so for gnome there's no way for this bug
<illovae> you have seen the .desktop for KDE are good
<LaserJock> I infact did file a bug in Gnome about it
<illovae> ah okay thanks, i didn't think to do it ^^'
<illovae> so do i reject the bug ? if yes, how can i tell to close it ?
<illovae> s/how/what
<LaserJock> well, I guess we can reject it
<illovae> "No fixing for ubuntu > bug reported upstream in GNOME ?"
<LaserJock> I'm not happy about it
<illovae> i understand, i'm not happy too
<LaserJock> well, I think my Gnome bug was basically rejected too
<illovae> arf
<LaserJock> basically it seems to me that freedesktop.org has said that "Science" should be a submenu of "Education"
<LaserJock> I should ask freedesktop about it I guess
<LaserJock> anyway, for now, I think we should reject the bug
<illovae> yes but you're agree it is not a good submenu "Education" for a science application :/
<illovae> okay so
<illovae> we don't make a .desktop for GNOME in the sources ?
<illovae> or in the debian/ ?
<LaserJock> not if it installs one already
<illovae> a .desktop like > menu:Others ?
<illovae> ah yes
<LaserJock> no, in the .desktop we say something like Categories=Application;Science
<LaserJock> it's just that basically Science = Other in the current menu
<illovae> yes it's true
<illovae> so it's a freedesktop.org problem i understand
<LaserJock> to reject the bug you can click on the little arrow to the left of "labplot" under "Affects"
<LaserJock> illovae: and I'm not sure it's one they see as a problem
<illovae> arf :/
<illovae> so i reject the bug and saying that : "Cannot fix this bug in Ubuntu - It's a bug/problem in the menu definition in freedesktop.org" ?
<LaserJock> sure
<LaserJock> illovae: check out http://standards.freedesktop.org/menu-spec/latest/apa.html
<illovae> ah yes i saw it
<LaserJock> notice that Science is a valid Category
<illovae> yes
<LaserJock> but it isn't in the "Main Menu" section
<illovae> why there aren't a Education/Science category Education for main et Science for additional
<illovae> ?
<illovae> it would be the best ?
<LaserJock> well, that's the part that is Gnome
<LaserJock> Gnome doesn't do submenus
<illovae> oups
<illovae> yes :/
<illovae> s/oups/ /
<illovae> okay thank you for your help, just a little thing : can i quote your name in the bug reject ?
<LaserJock> sure
<illovae> okay thank you very much for your help, it was a real pleasure for me to discuss with you :)
<LaserJock> no problem
<LaserJock> anytime ;-)
<illovae> :)
<bdmurray> tepsipakki: ping
<LeeJunFan> shouldn't the low-latency kernel have the hz timer set in /proc? by default the timer interrupts are turned off "0".
<crimsun> the safe setting is preferred. You can always set it to 1.
<crimsun> (does it really matter for idle, anyhow?)
<LeeJunFan> crimsun: yeah, I just figure that most people expect the lowlatency kernel to give them low latency simply from installing it, but turning off interrupts is really turning of preempt isn't it?
<ds> the tick rate is not related to kernel preemption
<LeeJunFan> I don't think that corresponds to tick rate, it's just a 0/1 enable/disable. 0 is kernel interrupts are disabled.
<derek_> is there any reason way a framebuffer isnt compiled into ubuntu kernel so we can have a bearable virtual terminal without recompiling the kernel..?
<null__> derek_, i think it is compiled by default ?
<null__> u should be able to just pass the vga= parameter to the kerenl opetion on bootup
<derek_> what version of ubuntu
<null__> i think all of the ones that have the ubuntu splash screen should support
<derek_> vga=0F01
<derek_> thats not with a frame buffer
<null__> CONFIG_FRAMEBUFFER_CONSOLE=m
<null__> that should be set in your kernel config
<null__> check in /boot/config`uname -r`
<mjg59> Because framebuffers mess up suspend/resume support
<mjg59> If you pass a vga= argument to put the screen in a vesa mode, vesafb will be used
<mjg59> But it's not going to be the default
<null__> mjg59, really ?
<null__> hmm i dont really have a proibme here 
<null__> but i am running the 2.6.20-3 vanilla tho
<mjg59> It works on some hardware
<mjg59> But not all
<derek_> when i switched from gentoo i could no longer use the virtual terminals because how bad they are
<null__> oh oki
<mjg59> If you want to have a framebuffer, pass the boot option.
<mjg59> But, as I said, it's not going to be the default.
<null__> ahkkk
<null__> u need to have CONFIG_VGA_CONSOLE=y for the vesa buffer
<derek_> they need to get out of usplash
<mjg59> ?
<null__> out of usplash ?
<derek_> stop using it
<null__> mjg59, i believe that is the present default for ubuntu
<null__> for the vesa fb
<mjg59> Ok. I will say this one more time, and then that is the end of the conversation.
<mjg59> If you want a framebuffer, pass the vga= argument to the kernel. Then you will have vesafb, which is broadly equivalent to what gentoo uses by default. This will not be the default on a stock Ubuntu installation, as it tends to interfere with power management on a large number of systems.
<null__> derek_, yeah i have disabled the usplash
<mjg59> If you have a framebuffer, usplash will use the framebuffer.
<mjg59> Otherwise it will make vesa calls directly.
<null__> thats right
<mjg59> null__: I wrote the software, I know it's right :)
<_ion> :-)
<mbiebl> mjg59: I always wondered, why usplash can use arbitrary resolutions.
* derek_ wishes suse used the debian package manager
<null__> hehe 
<mjg59> mbiebl: Because it uses code from svgalib to make direct vesa calls
<mjg59> It can't actually do arbitrary resolutions, just ones that the vesa bios provides
<mbiebl> mjg59: why is that safer (regarding suspend/resume) then using a fb directly? Just curious
<mjg59> When you resume, you have no idea what state the video hardware is in
<mjg59> The framebuffer that vesa gave you may no longer exist
<mjg59> So writing to it isn't safe
<mjg59> On the other hand, vga memory is basically specced to be there
<mjg59> So it's not a problem to depend on it still existing
<mjg59> The worst that can happen is that you get some garbage on the screen
<mjg59> When usplash exits, it returns you to standard vga text mode (unless you're using a framebuffer, in which case it just exits)
<mbiebl> Thanks for the clarification. So splashy, which relies on libdirectfb+a framebuffer is very likely to have more problems with suspend/resume.
<mjg59> Yes
<mjg59> That's why I wrote usplash
<mjg59> libdirectfb simply doesn't provide the functionality we wanted
<mjg59> And it was easier to start from scratch than to modify splashy to avoid the libdirectfb dependence
<mbiebl> ok
<mbiebl> Have you any plans to focuss more on uswsusp in the future?
<mbiebl> So things like graphical suspend/resume work too.
<mjg59> Yup
<mjg59> The uswsusp package in our archive should Just Work
<mjg59> Though I haven't had time to test it
<mjg59> I'm trying to finish my PhD off at the moment, so I haven't had as much time as I'd have liked to work on this sort of thing lately...
<mbiebl> ;-)
<Hobbsee> morning all
<bddebian> Heya Hobbsee
<Hobbsee> hi bddebian :)
<Mez> !seen keybuk
<ubotu> Sorry, I don't know anything about seen keybuk - try searching on http://bots.ubuntulinux.nl/factoids.cgi
<Hobbsee> [12:35]  [Notice]  -SeenServ- I last saw Keybuk (n=scott@yttrium.canonical.com) 10h 25m 53s ago, quiting: ""
<Mez> I swear I saw keybuk tonight :D
<Hobbsee> Mez: /msg seenserv seen keybuk
<Mez> Hobbsee, already did that, ubotu used to do it for ou
<Mez> I swear I saw Keybuk though :D hehe
<Hobbsee> Mez: true.  hasnt done so for a long time
<Mez> Hobbsee, and i haven;t used that functionality in a long time
<Hobbsee> ahhh
<Mez> I think I danced with keybuk tonight :D
* Hobbsee doesnt want to know..
<Mez> I was at  gay bar
* bhale hides behind Hobbsee 
* _ion hides behind Mez
* LaserJock hides behind bhale
<Mez> s/at  /at a /
* StevenK just hides
* bddebian doesn't mention anyting about pointy sticks
<Hobbsee> heh
<StevenK> bddebian: Is that a pointy stick in your pocket or are you just really really pleased to see us?
* StevenK runs.
<bddebian> haha
<janimo> cjwatson: hi, when you're around please let through xubuntu-meta, thunar and libxfce4mcs (the latter two are FTBFS related). thanks
<janimo> crimsun: hi, libxfce4mcs alsoo needed .la removal
<crimsun> janimo: ok
<crimsun> that should be the last thing in the stack for xfdesktop4, then
<janimo> crimsun: indeed. the last dev package using libstartup-notification-1.la seen by grepping /usr/lib/*a
<janimo> crimsun: thunar does not use mcs so when I saw it had built I thoight it was only the gui4 lib
<fabbione> Lathiat: ping?
* mdke looks for pitti in vain
<ivoks> ok, debian will get zenoss packages
<ivoks> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=361253
<ubotu> Debian bug 361253 in wnpp "ITP: zenoss -- Zenoss is a powerful, integrated," [Wishlist,Open]  
<ivoks> (ups.. wrong channel)
<Robot101> it's a powerful integrated? I always wanted one of those :D
<bhale> its a network management portal
<bhale> it looks pretty good, but i spent the last 2 years writing my own
<ivoks> :)
<bhale> which takes some focus away from event dashboard onto automation
<mdke> whoosh! the dvdcss script has been put back
* mdke hugs keescook 
<alex__> can anyone help me with my sound card and wifi card? I'm usuing ubuntu feisty running on LG laptop
<mdke> alex__: you can try #ubuntu or #ubuntu+1, or http://www.ubuntu.com/support
<alex__> so what this channel is for?
<pochu> alex__: development, not support
<mdke> discussion of Ubuntu development
<mdke> each irc channel has a topic you can read, at the top of your screen, which explains what the channel is about
<alex__> what the disscusion is about? Ideas or help applying new things? requests?
<mdke> discussion of specific problems that the developers have
<alex__> so I still have two more questions if you don't mind
<poningru> alex__: #ubuntu+1 is for you
<poningru> dude...
<alex__> it's not a suuport isue
<alex__> ok, I get it. thanks anyway
<Hobbsee> mdke: what do you mean?  (the dvdcss script)
<Hobbsee> oh, found it.
<Riddell> Mithrandir: new adept uploaded http://kubuntu.org/~jriddell/tmp/adept_2.1.2ubuntu25.debdiff
<Lathiat> fabbione: pong?
<Riddell> Lathiat: he's on holiday (as is almost everyone else)
<StevenK> Mithrandir: New ipvsadm uploaded, debdiff is http://wedontsleep.org/~steven/ipvsadm.debdiff
* Hobbsee notes that Mithrandir is on holidays too...
<Riddell> most inconvenient really
<StevenK> Hopefully, cjwatson will notice.
<cjwatson> StevenK: accepted
<cjwatson> (I'm aware of everything else in the queue as of now, but haven't reviewed all of it yet due to aforementioned holiday)
<StevenK> cjwatson: Thanks!
<cjwatson> Riddell: accepted
<Riddell> thanks
<StevenK> Oh, you can tell when uploads are being held.
<StevenK> The buildds just *pounce* on everything.
<rouzic> Hi everybody
<rouzic> https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.20/+bug/103413
<ubotu> Malone bug 103413 in linux-source-2.6.20 "(Feisty) During boot, configuring network interface is very slow" [Undecided,Confirmed]  
<robertj> can someone please look at https://wiki.ubuntu.com/SimpleSambaIntegrationSpec and tell me if that is a viable solution to the people who are filing bugs against samba "not working" when its just that they haven't created samba users
<Lathiat> fabbione: ah wellhe pinged me a fewhours aho
<Lathiat> err
<Lathiat> Riddell: he pingedmea few hoursback
<Lathiat> typing on these olpc keyboards is abit ofan art
<shawarma> It must be if you mistype "Riddell" as "fabbione". 
<shawarma> That's really... wow.
<StevenK> Hah
* keescook hugs mdke back :)
<mdke> :)
<doko> cjwatson: please have a look at http://people.ubuntu.com/~doko/tmp/bash.debdiff
<Tonio_> Mithrandir: I just uploaded dolphin for universe
<Tonio_> Mithrandir: I put a patch so that it deals with kde ioslave, otherwise switching to it as default would break a lot of things on the desktop, including the kicker
<Tonio_> Mithrandir: hope it is okay to be approved :)
<Riddell> Tonio_: universe packages shouldn't need approved
<Tonio_> Riddell: but they do....
<Tonio_> This upload awaits approval by a distro manager
<Riddell> oh, ok
<Tonio_> I wouldn't ping here if that wasn't frozen too :)
<StevenK> This is because selected components can't be subjected to the freeze. Otherwise main and restricted would freeze leaving universe and multiverse thawed.
<geser> universe doesn't need approval like main but an archive admin must accepted them by hand
<geser> after April 12th universe needs approval too (from motu-uvf?)
<StevenK> geser: More than likely. What happened for Edgy was ubuntu-release picked a few universe people to say yay or nay
<fabbione> Lathiat: re... sorry.. still around?
<Lure_> Tonio_: universe is just on manual, not in approval-required yet
<Tonio_> Lure_: hum okay
<Tonio_> Lure_: so who will proceed ? :)
<Lure_> Tonio_: archive-admins are doing them on regular basis (probably not as much today and over WE due to holidays)
<Lure_> Tonio_: universe freeze is Apr 12, afair
<Tonio_> Lure_: yup I noticed that concerning universe
<Tonio_> Lure_: I'll just wait then :)
<rmjb> hello, I'm looking for someone from the kernel team
<Hobbsee> rmjb: it's a public holiday
<kylem> not really...
<kylem> rmjb, join #ubuntu-kernel
<mjg59> Hobbsee: In parts of the world, yeah
<Hobbsee> most of them, i thoguht
<kylem> some of us don't care about non-secular holidays.
<rmjb_> hi, sorry about that, my "reliable" isp just dropped my connection again, is there anyone from the kernel team here?
<Hobbsee> kylem: well of course - but i would have thought the "any excuse for a holiday" applies
<Hobbsee> kylem: no matter whether you agree in what it's for or not
<mjg59> Hobbsee: You haven't seen a Canonical employment contract :p
<Hobbsee> mjg59: true that.  it's about as bad as my work's, then?
<mjg59> Well, Kyle's working, so we can make assumptions :)
<sharms> Its not a holiday in the US thats for sure
<Hobbsee> sharms: weird!  i thought it was.
<kylem> Hobbsee, feh.
* kylem celebrates the Feast of Maximum Occupancy.
<Hobbsee> hehe
* Hobbsee now suspects a clause in there that says "thou shalt work all weekends, and thou shall not take holidays.  especially ones that most others take off"
<sharms> ha
<kylem> Hobbsee, no, almost everyone is off today.
<Hobbsee> kylem: right.
<Riddell> they're all skiving
* _ion looks for pitti in vain
<Riddell> he's skiving :)
* Hobbsee blames slomo 
<sharms> What holiday are we talking about? I am 90% sure there isnt once in US
<Hobbsee> sharms: it's easter in a whole lot of countries.
<sharms> ah that is sunday here?
<Hobbsee> no idea
<sharms> that is the day we lay easter eggs and go out in the yard and retrieve them
<mjg59> It's Good Friday today
<sharms> although for some reason since I stopped living at my parents, the easter bunny stopped coming
<mjg59> More of a "Jesus being nailed to a cross" thing than an easter bunny one
<sharms> I think that is discrediting the bunny
<kylem> mjg59, is that the guy who founded your college? :)
<mjg59> That lad, yeah
<sharms> hey since we have a crowd today, does anyone know if gcc 4.2 is for sure going to be in feisty + 1?
<Mirv> does anyone have an idea why the "Install" icon on the desktop does not show its translations? all the translations are there in the ubiquity-gtkui.desktop, so it might be possibly to fix this for feisty?
<Mirv> hmm, it's translated under System/Administration menu, but if it's again added/copied to the desktop from there, it's shown as untranslated
<Mirv> hmm hmm, it happens only on the live-cd, and for each item that is on the desktop. but it does not happen on an installed system. the translation are there in the menus. would someone have an idea in what part of the system the problem could be? I could try to find some relevant bug.
<Mirv> there shouldn't be too many differences between a live system and an installed system, I gather
<Mirv> well, I added the information to bug 45741 , and added nautilus to it (purely guessing)
<ubotu> Malone bug 45741 in ubiquity "Ubiquity desktop icon "Install" is not translated" [High,Confirmed]  https://launchpad.net/bugs/45741
<cjwatson> doko: I'm curious about why we're bothering to apply patches that claim not to even affect our system
<doko> cjwatson: counts the patch counter up; I can leave it out, but then I have to modify the patch
<cjwatson> doko: what's the release-critical bug you're trying to fix here? I've only skimmed the patch
<cjwatson> doko: similarly for python 2.5.1rc1 - would like to know what release-critical bugs it's fixing
<doko> cjwatson: bash? 
<cjwatson> both
<doko> cjwatson: ? yesterday you agreed to an UVF exception for python 2.5.1 ...
<cjwatson> I did? it's been a busy couple of days ...
<cjwatson> remind me what the reason you gave was
<cjwatson> I think I may have been under the impression that you were updating from 2.5.1rc1 to 2.5.1, which would have been a different matter
<cjwatson> (the more actual releases and the fewer release candidates, the better)
<doko> wait, extracting the diffs for python2.5
<doko> cjwatson: bash32-013 is one crash fix, that the same for readline5
<doko> cjwatson: http://people.ubuntu.com/~doko/tmp/python2.5-changes , the locale.strxfrm fix already is in python2.4
<sharms> Anyone want to help me get some action going on: https://wiki.ubuntu.com/Spec/EnhancedBash
<cjwatson> doko: bash up to 013 is fine; 014 scares me as it changes parsing (possibly for the better, but I don't really want to risk it), and 015 doesn't apply to us as we have /dev/fd
<cjwatson> doko: the python2.5 diff is huge; can we just have a targeted patch for the locale.strxfrm bug?
<cjwatson> when I looked at the diff, it changed a lot more than what that release notes diff indicated
<doko> wait, sending a diff of the two trees
<doko> <doko> cjwatson: (sorry, wrong channel) would like to update python2.5 to the 2.5.1 release candidate 1 today; see bug 103302
<doko> <ubotu> Malone bug 103302 in python2.5 "UVF exception for python 2.5.1" [Undecided,Unconfirmed]  https://launchpad.net/bugs/103302
<doko> * illovae_ ist jetzt bekannt als illovae
<doko> <cjwatson> doko: ok, that's fine
<ubotu> Malone bug 103302 in python2.5 "UVF exception for python 2.5.1" [Undecided,Confirmed]  https://launchpad.net/bugs/103302
<cjwatson> doko: ok, sorry, I was obviously frazzled and misunderstood, plus the release notes diff you sent at that point was a lot less scary than the actual diff
<cjwatson> score -1 for release notes
<illovae> ?
<cjwatson> illovae: ignore it, it's just a paste of an IRC log fragment
<illovae> arf okay ^^ thanks
<doko> cjwatson: http://people.ubuntu.com/~doko/tmp/python2.5.diff ; removed the PC build changes and the changes where just revision Ids are changed.
<cjwatson> doko: I would prefer a fix for just the locale.strxfrm bug, if you don't mind
<Lathiat> fabbione: am now
<Lathiat> fabbione: 3 hours later again ;)
<Lathiat> fabbione: feel free to just ask or email lathiat@bur.st
<doko> cjwatson: I would really prefer the update to the rc1. mvo did have enough problems with pickling changes in 2.5
<doko> s/changes/bugs/
<cjwatson> are there bug numbers?
<cjwatson> it would really help if you told me all the reasons at once :-)
<cjwatson> rather than bringing up a new reason each time I have an objection
<cjwatson> I don't have much time here
<cjwatson> and I guarantee that mdz will be asking me why I accepted this
<doko> cjwatson: the upstream bug numbers are mentioned in the NEWS file; the locale.strxfrm bug is debian #416931. we should know python upstream very well, that they don't introduce new stuff in point releases, plus in the past we always shipped with the current release or releae candidate
<ubotu> Debian bug 416931 in python2.4 "python2.4: off-by-one bug in strxfrm() (causes information leak)" [Important,Closed]  http://bugs.debian.org/416931
<cjwatson> doko: what's that timemodule change?
<doko> 30% of the patch are documentation fixes
<cjwatson> for the record, arguments that go "but upstream are really good" don't tend to go over very well with me :)
<cjwatson> I knew about the locale.strxfrm bug. That's one line
<cjwatson> ah, the timemodule change is Windows-only
<doko> cjwatson: ifdef windows
<doko> cjwatson: remove the IN.py diff; that's my mistake
<cjwatson> see, the thing you uploaded is a 160929-line diff
<cjwatson> the thing you're showing me now is 876 lines
<cjwatson> which is it? :)
<doko> Colin, ...
<cjwatson> no, really, this is something I will be called on
<cjwatson> you need to help me justify it
<doko> cjwatson: the diff are the regenerated docs (debian/patches/docs.uue)
<doko> - the removed debian/patches/svn-updates.diff
<doko> I don't hide any diffs, the diff was meant to have a clear look at the changes
<doko> there are about 200 diff lines doc changes
<cjwatson> I'm not accusing you of anything, I'm just finding it hard to reconcile
<cjwatson> copying the diff down now to try to get a better look locally
<cjwatson> dinnertime, will continue to look later on
<jabra> I have a debian package I would like to get updated in feisty if possible
<jabra> the recent update is in debian unstable
<robertj> ajmitch: can you look at https://wiki.ubuntu.com/SimpleSambaIntegrationSpec for 60 seconds and give me an initial good-idea bad-idea impression?
<Adri2000> jabra: which component ? main, universe? is it a new upstream release or just an update of the package?
<jabra> update to fix a bug
<jabra> it is in universe
<jabra> package is called pbnj
<Adri2000> jabra: ok, then it's possible to request a sync
<jabra> k
<jabra> so should I just submit a bug for the request to sync
<Adri2000> jabra: yes: https://wiki.ubuntu.com/SyncRequestProcess
<jabra> cool thanks
<jabra> will it be able to get into feisty ?
<Adri2000> yes, if you do it now and if you get a developer to ack your sync request quickly
<Adri2000> this is done by subscribing ubuntu-universe-sponsors to the bug, and/or asking in #ubuntu-motu
<jabra> k
<gnomefreak> bdmurray: good luck in -bugs. she will never leave you alone now :(
<bdmurray> gnomefreak: thanks for the warning
<gnomefreak> yw
<bdmurray> maybe if I just don't respond now
<cjwatson> doko: ok, I think I have resolved some of my confusion by realising that many of the changes were already present in debian/patches/svn-updates.diff
<cjwatson> doko: it would REALLY have helped if you had just said that up-front, instead of making me try to guess
<gnomefreak> good luck
<cjwatson> doko: everyone on the release team is under a lot of pressure to make exactly the right decision at the moment
<doko> cjwatson: I don't deny that; anyway, I'll have to leave now, trying to get internet access tomorrow or on Sunday. the readline5 patch is the same as the bash32-013 patch; is that one approved as well?
<doko> I updated the python2.5 package on chinstrap:~doko/for-feisty
<mdke> cjwatson: around?
<mdke> or elmo, mako, sabdfl?
<unfo> hi all, how do i forward a bug to an upstream devel mailing list so that list members can click "Reply to All" and replies will get into launchpad?
<LaserJock> hmm, like for a specific bug?
<unfo> LaserJock: yes, a bug in emacs-snapshot
<LaserJock> I'm not exactly sure if that's possible
<LaserJock> I think you can use <bug number>@bugs.launchpad.net
<LaserJock> but I'm not sure if that's suitable for that kind of thing
<unfo> if I email the bug report text to the list and CC <bug number>@bugs.launchpad.net, then when people Reply to All, will it get into lp?
<unfo> or will that fail because they're not registered lp users?
<LaserJock> I'm really not sure
<LaserJock> you might have to ask the Launchpad people
<unfo> ok, i'll ask on channel #launchpad.
<Burgwork> unfo: it will fail, because LP only accepts signed mail
<Burgwork> LaserJock: ^
<unfo> Burgwork: oh. :(
<Burgwork> and it needs the users key already, so they need an LP account
<LaserJock> Burgwork: darn, figures
<unfo> Burgwork: it seems from my experimentation that it silently ignores unsigned mail from both registered and not-registered users?
<unfo> Burgwork: is that true?
<Burgwork> likely
<unfo> Burgwork: :( i should file a bug.  It sucks for it to silently drop mail.  It should always provide *some* response.  I wish Launchpad was fully open-source.
<Burgwork> unfo: yes, yes, and yes
<Burgwork> :)
<unfo> Will all of launchpad really eventually be open-sourced, so I could, say, run a private copy of launchpad on my personal web server including malone, answers, and everything?
<mdke> unfo: it used to send responses when mail was dropped, so you should file a bug
<unfo> I've read the FAQ but I still don't understand if it will.
<mdke> #launchpad is the better channel for launchpad discussion, though
<mdke> I suspect the answer to your last question is that we don't know. Certainly it isn't ready to be run on various people's private servers at the moment
<mdke> the intention, as you saw from the faq, is to make it open source
<unfo> mdke: ah.
<unfo> mdke: Burgwork: it seems it accepts unsigned comments by email from registered LP users, but it silently drops comment and new-bug emails from others.  I'll file a bug.
<Burgwork> mdke: intention to make open source != actual timeline
<mdke> Burgwork: I hope that I didn't suggest there was an actual timeline. it would surprise me if the devs have any idea about how to make it happen at the moment. Maybe they do though
<Burgwork> mdke: I hope they do
<mdke> I suspect they have been focused on 1.0 for a while now
<mdke> without worrying about how to scale the concept to make it open-sourceable
<mdke> but I think we should move channels
<unfo> mdke: ok, moving to #launchpad.
#ubuntu-devel 2007-04-07
<sharms> is there any reason why gnome-terminal sets the TERM type as xterm, and not xterm-color
<ds> xterm is in color
<sharms> oooh look a new hot spec: https://wiki.ubuntu.com/Spec/EnhancedBash
<romuloubuntu> I would like to know how can I help on ubuntu development
<romuloubuntu> I can code in C C++ and Java
<romuloubuntu> and have a limited knowloedge about linux and ubuntu
<romuloubuntu> i dont know much, but want to help
<sharms> romuloubuntu: https://wiki.ubuntu.com/UbuntuDevelopers
<dstanek> is there a good official set of instructions for upgrading to feisty? all i can find is forum posts with bits and pieces of information
<LaserJock> dstanek: #ubuntu+1 is probably a better channel to ask, are you wanting to upgrade now?
<Burgundavia> dstanek: there will be soon, via a set of release notes
<dstanek> LaserJock: yep - i saw some interesting bugs that i would like to take a look at
<ra21vi> hi
<ra21vi> is there any performance enhancements in Feisty
<ra21vi> everybuddy must be sleeping :)
<ra21vi> exit
<janimo> cjwatson: please let  thunar-volman-plugin through when you're around. thank you
<cjwatson> janimo: grrr stop disappearing when I want to talk to you
* cjwatson mails
<cjwatson> hate drive-by IRC though
<poningru> lol
<elkbuntu> hmm... is it normal for mailing lists to have 170 people unsubscribe at precisely the same moment?
<poningru> eek
<mdke> I've had something similar on ubuntu-it
<poningru> nothing on marketing like that
<elkbuntu> mdke, -users had 170 an hour and a half ago
<mdke> occasionally we have mass unsubscriptions caused by excessive bounces from one particular provider
<mdke> same provider?
<elkbuntu> multiple providers
<mdke> maybe related to these problems we've been having with the list recently
<elkbuntu> hmm.. maybe not
<elkbuntu> apologies, all gmail
<mdke> excessive bounces?
<mdke> maybe gmail had some downtime
<elkbuntu> no indication of bounces, no
<mdke> given the traffic on -users, it probably doesn't take much downtime to get a lot of undelivered mail
<mdke> what's the reason given for the unsubscription?
<elkbuntu> im not admin, only mod, i dont get the reason
<mdke> oh, right
<elkbuntu> "#####@gmail.com has been removed from ubuntu-users."
<elkbuntu> is all i see
<mdke> best grab an admin, I guess
<mdke> talking of bounces, I've had 800 so far from that wiki licensing email I just sent out... did anyone actually get it?
<mdke> let's hope my provider isn't spam blocked or something
<elkbuntu> i got it
<mdke> okay
<elkbuntu> some people do change email addresses like underwear though
<cjwatson> I got it
<elkbuntu> cjwatson, who's around i can poke to investigate this mass unsub?
<mdke> a lot of these bounces seem to be related to me being blocked... oh well. Hopefully the majority are getting it
<elkbuntu> mdke, i'm sure it will be blogged about, reposted, etc. the message will get out
<mdke> yes, I've blogged it now and I'll use a few mailing lists too
<mdke> looks like I was on spamhaus pbl, damn
<mc44> mdke: i didnt get it at gmail
<mdke> what's your address?
<mc44> mdke: markc.lists etc
<mdke> you're not in my list :)
<mc44> oh i thought it was to a mailing list :)
<mc44> sorry
<mdke> should be anyone who has edited documentation on an ubuntu wiki, more or less
* mdke goes for a shower
<sacater> who controls the nvidia-glx development?
<Fujitsu> sacater: NVIDIA, perhaps?
<sacater> but who adds nivida-glx to universe?
<Fujitsu> It's in restricted, and I'm not sure who.
<poningru> I thought it was in multiverse
<sacater> poningru: Fujitsu any way i can find out?
<Fujitsu> No, restricted.
<Fujitsu> sacater: It'll be the kernel team.
<poningru> Ubuntu Kernel Team
<poningru> yeah
<poningru> Maintainer: Ubuntu Kernel Team <kernel-team@lists.ubuntu.com>
<sacater> ok
<sacater> thanks
<rouzic> stgraber: https://bugs.launchpad.net/ubuntu/+source/xorg/+bug/94055
<ubotu> Malone bug 94055 in xorg "MacBook Pro touchpad too sensitive in Feisty - kernel-2.6.20-12" [Undecided,Confirmed]  
<rouzic> please, disabled the touchpad in the macbook :(
<gerv> Any boot process hackers about?
<mako> mdke: did you get your issue handled?
<elkbuntu> hi mako
<mako> elkbuntu: hola
<elkbuntu> mako, PM ok?
<mako> yes
<mdke> mako: yes thanks
<mako> awesome, thanks
* poningru waves at gerv 
* gerv waves back, belatedly
* gerv 's laptop is still hosed
<poningru> gerv: whats wrong?
<gerv> I installed the Feisty beta.
<gerv> It decided that my single-disk laptop needed mdadm
<poningru> -> #ubuntu+1 ?
<gerv> (which is a RAID thing)
<cjwatson_> mdadm ?!
<gerv> I tried in there.
<cjwatson_> gerv: which installer?
<gerv> I had some cluebie telling me to reformat my hard disk.
<poningru> hmm thats weird
<gerv> Later on, it emerged that he didn't even run Ubuntu.
<cjwatson> gerv: (LTNS)
<gerv> mdadm doesn't work, and my laptop won't boot.
<poningru> buh
<gerv> cjwatson: Not sure how to answer your installer question.
<cjwatson> gerv: live CD-type installer, or text mode?
<gerv> I did an apt-get dist-upgrade.
<cjwatson> oh, I see
<poningru> eek
<cjwatson> gerv: originally installed pre-dapper?
<gerv> I'm happy to take this elsewhere; I just came in here to try and find someone with a clue.
<cjwatson> sorry, dapper or earlier, I mean
<gerv> Originally installed with dapper, yes.
<cjwatson> right, dapper installed mdadm regardless
<gerv> (I think.)
<cjwatson> we took it out in edgy
<gerv> I can boot the laptop with a liveCD.
<cjwatson> you should just be able to boot a live CD, mount your normal filesystem, chroot in, apt-get --purge remove mdadm, and eboot
<gerv> Using that, I updated to the latest version of lots of stuff, as SJR asked me to do in the bug I filed.
<cjwatson> reboot
<gerv> I removed mdadm, but it still won't boot.
<cjwatson> ok, so we can skip mdadm as the cause then
<gerv> Well, it was an mdadm error which was the last thing the console printed.
* gerv shrugs
<gerv> But you are right, perhaps it's not that.
<cjwatson> what does it do, drop you to an initramfs prompt?
<gerv> I have a bug filed:
<gerv> https://bugs.launchpad.net/ubuntu/+source/mdadm/+bug/102148
<ubotu> Malone bug 102148 in mdadm "Machine won't boot; mdadm says "no device listed..."" [Undecided,Confirmed]  
<gerv> Yes, it eventually times out to an initramfs prompt.
<gerv> Or, I can get one quicker using the boot option break=mount
* gerv is booting his Live CD again
<gerv> (it takes about five minutes)
<cjwatson> I think Scott missed the bit where you said you didn't actually have a RAID array
<gerv> Ah :-)
<gerv> I suspected that might be the case.
<gerv> I did also say I had a laptop...
<gerv> How many laptops have RAID arrays?
<cjwatson> there are some freaks, but anyway
<gerv> (Not including yours.)
<cjwatson> mine doesn't. :-)
<gerv> Oops.
<gerv> Those two messages were typed at the same time!
<gerv> Honest!
<poningru> lol
<cjwatson> have a look in /sys/block from the initramfs prompt to see if your hard disk is there
<gerv> OK.
<gerv> One second.
<cjwatson> /sys/block/hda or /sys/block/sda or whateveer
<gerv> What should it say?
<gerv> Aha.
<gerv> Can I use break=mount or must I wait for timeout?
<cjwatson> if it's not there (as I suspect), then the kernel isn't detecting your disk
<cjwatson> break=mount is fine
<gerv> One sec...
<gerv>  /sys/block/sda is present.
<cjwatson> the other possibility with a reasonably good probability attached to it is that your bootloader is pointing to the wrong root filesystem; there's a particularly good chance of this if you're using lilo
<gerv> (My disk, for some reason, shows up as SCSI when I'm pretty sure it's IDE.
<gerv> I'm using GRUB.
<cjwatson> most disks are sd* now, due to libata
<gerv> OK.
<gerv> so sda is there.
<cjwatson> ok, is /dev/sda* there?
<gerv> Yes.
<gerv> I try:
<gerv> mkdir /tmp/hd
<gerv> mount /dev/sda1 /tmp/hd
<gerv> and it says:
<gerv> "Mounting /dev/sda1 on /tmp/hd failed: Invalid argument"
<gerv> (Helpful, huh?)
<cjwatson> so that's the kernel saying EINVAL
<cjwatson> if you're lucky, dmesg might have more information
<gerv> I have /dev/sda, /dev/sda1, /dev/sda2 and /dev/sda5.
<gerv> Which I believe is correct.
<gerv> dmesg: Not found.
<cjwatson> argh silly busybox-initramfs
<gerv> Neither is there a /var/log
<poningru> gerv: can you try sda2?
<cjwatson> try 'mount -t FSTYPE /dev/sdaWHATEVER'
<gerv> poningru: Same problem.
<gerv> And with 5.
<cjwatson> er ... /tmp/hd
<gerv> And with just /dev/sda.
<gerv> OK.
<gerv> Is it "-t ext" for ext3?
<cjwatson> -t ext3
<gerv> Aha!
<gerv> That works.
<cjwatson> ok, now, sounds like your grub configuration is wrong
<gerv> I can see my root filesystem.
<cjwatson> check /boot/grub/menu.lst in the root fs to see what root= says
<gerv> One practical problem.
<gerv> How do I view it?
<poningru> cat
<gerv> busybox has no editor, and no "more".
<cjwatson> chroot, editor-of-choice
<gerv> It scrolls off the screen.
<cjwatson> 'chroot /tmp/hd' will work now ...
<gerv> Aha.
<gerv> One second, then.
<StevenK> cjwatson: Do you have a moment to discuss a bug?
<poningru> cjwatson: I can take over here if you want
<gerv> OK.
<cjwatson> StevenK: sure
<cjwatson> poningru: *shrug*, I'm here for a little while
<gerv> There are loads of stanzas.
<poningru> cool
<gerv> The first one has:
<gerv> root     (hd0,0)
<gerv> In fact, that all do.
<poningru> wait thats it?
<poningru> there isnt anything more?
<cjwatson> no, he means that all the stanzas have that
<gerv> No, there's lots.
<poningru> oh...
<gerv> default    0
<StevenK> cjwatson: bug 96464 has had the 7.04 milestone added to it - my opinion is that it's a user error, a hard problem to solve and we should ignore it until Feisty+1. I just wanted to see if you (or someone else from -release) concurs.
<ubotu> Malone bug 96464 in twiki "Twiki package: /usr/sbin/apachectl is not executable, exiting... " [High,Confirmed]  https://launchpad.net/bugs/96464
<cjwatson> this is not surprising, I'm looking for the root= on the kernel line
<gerv> Ah!
<gerv> root=/dev/evms/hda1
<cjwatson> bingo
<gerv> Which is also true for all of them,
<gerv> even the Edgy kernels.
<StevenK> gerv: There's a groot option
<cjwatson> kick evms in the nuts, change that to /dev/sda1 throughout, probably purge evms from your system, and reboot
* gerv readies his boot
<gerv> !trout evms
<ubotu> Sorry, I don't know anything about trout evms - try searching on http://bots.ubuntulinux.nl/factoids.cgi
<StevenK> kopt, that is
<poningru> lol
<cjwatson> evms is another of the things we kicked out of standard post-dapper
* gerv thinks you need a better class of bot
<StevenK> kopt=root=/dev/mapper/system-root ro
<poningru> gerv: hey its better than firebot trust me
<StevenK> And then run update-grub
<gerv> cjwatson: Are you able to update the bug with a proper description of the problem?
<StevenK> (Change your line to suit)
<poningru> StevenK: he isnt on grub prompt
<gerv> I would hate to think of lots of people upgrading from dapper having this issue.
<StevenK> poningru: That's in menu.lst
<gerv> cjwatson: How do I purge evms?
<gerv> As in, dpkg --purge remove evms?
<cjwatson> StevenK: can't we just check whether /usr/sbin/apachectl etc. exist? Checking for conffiles is well-known to be wrong.
<cjwatson> gerv: apt-get --purge remove evms
<cjwatson> gerv: sure, I'll update it. Did you upgrade straight to feisty from dapper, or via edgy?
<gerv> Via edgy.
<cjwatson> ok
<gerv> For quite a while, I ran edgy.
<poningru> StevenK: oh did not know that
<StevenK> cjwatson: That error (which I find I can't reproduce to blow up) is from invoke-rc.d apache.
<gerv> Am I supposed to ignore StevenK? That's another problem, right? :-)
<cjwatson> StevenK: sure, but you can [ -x /usr/sbin/apachectl ]  or whatever independently
<cjwatson> I don't think "package removed but not purged" counts as user error
<gerv> I can't purge evms - dpkg complains about not being able to find install-info and update-rc.d.
<cjwatson> though I'm also not entirely convinced it's release-critical
<gerv> Is it compulsory, or can I do it once I've booted.
<gerv> ?
<cjwatson> gerv: ok, don't worry about purging it just yet
<gerv> OK.
* gerv changes root= lines and reboots
<gerv> cjwatson: You can say in the bug that I'm available to help with any further debugging I can do.
<cjwatson> done
<cjwatson> I reassigned the bug to grub
<gerv> It doesn't boot, but that's because I've just realised I removed evms but didn't change hda1 to sda1.
* gerv goes through process again
<cjwatson> note /dev/sda1 not /dev/evms/sda1
<cjwatson> the evms is a bogus remnant of slightly-dodgy UUID detection
<gerv> Is a bogus remnant anything like a not-carefully-reading scott james remnant?
<StevenK> cjwatson: Right, I have a slightly dodgy fix for the other open twiki bug, I will only restart apache* if apachectl is executable
<gerv> :-)
<cjwatson> I suspect Scott was frantically trying to get through triaging about a million boot bugs before release
<gerv> Sure.
<gerv> No blame, just amusement :-)
<gerv> I'm sure he's a busy guy.
* gerv has seen a little of his frustration in some comments
<StevenK> gerv: Oh my God, can we keep you?
<StevenK> A bug happens and you show amusement, not blame or frustration.
* gerv would be much more upset if his laptop was his only machine
* gerv is very glad he tried it there first
<StevenK> cjwatson: I seem to recall evms being installed on my bosses Feisty machine ...
<StevenK> I also recall having to take it out the back and neuter it.
<cjwatson> indeed, if he upgraded from dapper or before
* gerv waits for his root filesystem to do the "30-mount fsck"
<StevenK> No, fresh install, which is what worries me
<gerv> In fact, 32-mount.
<cjwatson> StevenK: no code that'd do that to my knowledge
<gerv> Thanks everyone!
<cjwatson> gerv: thanks for the help tracking it down
<gerv> Gotta run now, but will clean everything up and get it working properly later.
<gerv> No problem.
<gerv> Thanks for being the guy with a clue :-)
<StevenK> Hrm. I suspect it's been reinstalled since.
<StevenK> Pity.
<cjwatson> I'm not certain we can do anything about it for feisty, but can certainly look at it for the LTS-to-LTS upgrade problem that we need to sit down and solve at some point
<StevenK> Conflicts: are fun. Although it smacks of 'killing a fly with a 30-pound sledgehammer'
<gerv> cjwatson: My problem or his?
<cjwatson> gerv: yours
* gerv sincerely hopes it's possible to do something about machines becoming unbootable before Feisty is released.
<cjwatson> I'd like to, but it's just so close to RC and with public holidays ... I did set the milestone though
<gerv> I upgraded using the applet thingy.
<cjwatson> and bumped priority
<gerv> If this happens to a significant number of people, this could be Really Bad(TM).
<cjwatson> so it is on the list, if it can be crammed in
<gerv> OK.
<gerv> I'll wait and see what happens :-)
* gerv really goes now
<cjwatson> right answer might be to try to transition stuff of the form /dev/evms/hda1 to UUID but not /dev/evms/<otherstuff
<cjwatson> >
<cjwatson> it's a slightly thorny problem - really a case of working around edgy's bugs
<cjwatson> but edgy's bugs have become relevant now that /dev/hda => /dev/sda for you
<StevenK> cjwatson: I wonder if sd* get sucked into that as well, such as /dev/evms/[sh] d*
<cjwatson> I'd be surprised if they didn't - but we can't guarantee exactly how the hd* -> sd* transition will work from userspace, hence UUIDs
* StevenK nods.
<cjwatson> ok, I have a very tentative patch for that
<StevenK> cjwatson: Do you want to see a debdiff for this twiki bug fix?
<cjwatson> StevenK: sure
<StevenK> cjwatson: http://wedontsleep.org/~steven/twiki.debdiff
<cjwatson> StevenK: it's /usr/sbin/apachectl, not /usr/bin/apachectl
<StevenK> DOH!
* StevenK finds a rock to hide under.
<cjwatson> doesn't apache2 need to be restarted?
<cjwatson> in which case you should check apache2|apache2-*) if [ -x /usr/sbin/apache2ctl ] ; then continue; fi ;; or whatever
<StevenK> Okay, I'll also check for apache2ctl
<cjwatson> I'd use grep -q -- -b
<cjwatson> though dunno, maybe -e is more portable after all, I just don't trust it to terminate options
<cjwatson> looks ok otherwise
<cjwatson> in my own packages I often prefer to stick a trivial portable-shell version of which(1) at the top of the script and use it as a function rather than hardcoding paths
<cjwatson> but YMMV
<StevenK> cjwatson: I've never had any problems with grep -e
<StevenK> cjwatson: That part of the patch strikes me as really dirty. I blame mini-httpd
<cjwatson> /usr/bin/which is more or less my code aside from some crackful and wrong option parsing that somebody stuck in there, so I use a reduced version of that
<cjwatson> you can see it e.g. in base-passwd.postinst
<StevenK> cjwatson: debdiff updated.
<cjwatson> yup, looks fine
<cjwatson> argh, which -a was added due to Dan Jacobson
* cjwatson sighs
<cjwatson> as I wrote it, which intentionally had no option parsing whatsoever in order that you could safely use it on any string without having to care about escaping
<cjwatson> though I suppose at least you can now put -- in front
<StevenK> cjwatson: twiki uploaded. Thanks for your help.
<Adri2000> cjwatson: I would like to do an update of devscripts. I need a sponsor and I need your approval (since it's main), the debdiff is at http://adrishost.homeip.net/~adri2000/ubuntu/devscripts_2.9.27ubuntu13.debdiff
<Adri2000> cjwatson: currently requestsync doesn't work because of "distros/ubuntu": example: "Failing command: affects distros/ubuntu/mantis" "There is no project named 'distros' registered in Launchpad."
<Mirv> uh oh, Gaim is now Pidgin.
<cjwatson> Adri2000: I would change 'tla | bazaar' to 'bzr | tla | bazaar' rather than 'tla | bzr' - there's code in devscripts that legitimately does use baz
<cjwatson> Adri2000: aside from that your changes are fine, but please find another sponsor as I'm trying not to spend too much time on work today
<Adri2000> ok, thanks
<Adri2000> debdiff updated, if any core-dev is available: please upload it
<tan_> Hi, does anyone know who I could contact regarding the google SoC?
<dotwaffle> Anyone seen Keybuk recently?
<dotwaffle> re: Upstart.
<Hobbsee> he's on holidays for a copule of days, iirc.
<cjwatson> he was in our London office Tue-Thu, and is now on holiday until next Tue
<cjwatson> (UK public holidays)
<dotwaffle> Ah, ok, no worries. Demoscener here was interested in chatting to him re: getting CPU intensive/Low IO load graphical startup. Will chat to him when he return ;0
<dotwaffle> Thanks.
<dotwaffle> Back to the demoparty ;) www.demoscene.tv if people care...
<gerv> cjwatson: I've now booted successfully, and run update-grub, which stuck UUIDs into my menu.lst, and now it boots on its own fine.
<gerv> Thanks :-)
<cjwatson> ah yes, update-grub would have done that once you put /dev/sda1 there
<cjwatson> great, thanks, trying to set up an environment such that I can test my possible fix now
* gerv presumes mangling your menu.lst will do the trick?
<cjwatson> probably, but I'd rather have a genuine dapper->edgy system to work with
<gerv> Ah. But that might take some time :-)
<cjwatson> "About 1 hours 18 minutes remaining"
<gerv> Is there free software that does virtual machines and disk imaging and rollback and so on?
<cjwatson> that's ok, the computer will do it while I do something more interesting
<cjwatson> gerv: I'm afraid I'm still using VMware, but I keep hearing good things about VirtualBox
<sharms> VirtualBox works good for me using windows guests
<sharms> Wouldnt work with openbsd guest
<sharms> And couldn't install virtualbox-tools on a suse 9 guest
<jdong> sharms: I've got VB to kernel-panic my host on several occasions....
<jdong> especially when running certain apps within the VM
<superm1> cjwatson, Virtual box has worked wonderfully on all ubuntu guests i've tried
<tormod> tepsipakki: does your savage segfault at logout? bug #104188
<ubotu> Malone bug 104188 in xorg-server "[apport]  Xorg crashed with SIGSEGV in memcpy() on logout" [Undecided,Unconfirmed]  https://launchpad.net/bugs/104188
<jdong> bhale: has the beagle log verbosity thing been decreased yet?
<jdong> bhale: it seems to produce like 5MB of logs per day for me still...
<jdong> and like a big 700MB log on the initial index
<bhale> jdong: no, it hasnt
<bhale> we are in hard freeze
<jdong> is that still planned for release?
<bhale> it would be nice
<jdong> yeah, definitely it'd be nice
<bhale> i will ask tollef if i see him
<jdong> awesome, thanks bhale
<bhale> np
<sharms> anyone else on the newest update get multiple usplash progress bars?
<zyga> hello
<Saied> hi all, i have problem with pngtobogl command
<Saied> the content of C source output file is "too many colors (256)"
<Saied> what can i do to solve this problem?
<Mithrandir> reduce the number of colours?
<Saied> Mithrandir: how many colors?
<Mithrandir> 16
<Mithrandir> iirc
<Saied> Mithrandir: i examined with 128 colors but problem exists
<Mithrandir> yes, bogl only supports 16 colours.
<Saied> Mithrandir: 16 colors? i think default kubuntu or ubuntu usplash-theme has more than 16 colors? are you sure?
<Mithrandir> I don't believe it has, no.
<Saied> Mithrandir: i use it for usplash customization according to https://help.ubuntu.com/community/USplashCustomizationHowto
<Saied> Mithrandir: is there a link to kubuntu or ubuntu usplash images to find out number of colors?
<Mithrandir> apt-get source usplash-theme-ubuntu ?
<Seveas> Mithrandir, bogl supports more than 16 colors
<Seveas> Mithrandir, vga16fb (one of the bogl backends) does not
<Saied> Mithrandir: in that customization tutorial you can see "The image you use should have max. 256 colors"
<Seveas> but the backend used on ppc (the only platform where usplash uses bogl now) supports more 
<Seveas> Saied, you should still include a 640x400x16 theme as fallback
<Saied> Seveas: but i have "too many colors (256)" error. without any output
<Seveas> Saied, which versio of ubuntu are you using? Dapper?
<Saied> Seveas: feisty
<Seveas> Saied, are you using pngtobogl?
<Saied> Seveas: yes
<Seveas> then you are reading the wrong tutorial
<Seveas> and since this has nothing to do with ubuntu development, come to #ubuntu-offtopic :)
<Saied> Seveas: which tutorial is correct? please guide me
<sharms> Saied: he just guided you to ubuntu-offtopic, go there.
<WhiteFly> someone can tell how can i localize my custom app?
<WhiteFly> some tutorial about it...
#ubuntu-devel 2007-04-08
<desrt> http://www.answers.com/topic/gallant
<desrt> http://www.answers.com/topic/gnu
<bluefoxicy> hmm
<bluefoxicy> Gaim is now called Pidgin
<bluefoxicy> too late in the Feisty roll-out to change the package name
<sn0> nice new name :)
<bhale> is that some other language
<bhale> or just nonsense.
<sharms> http://en.wikipedia.org/wiki/Pidgin
<bhale> goodness
<Burgundavia> and in other news: steve mcintyre is 2nd again
<bhale> Burgundavia: dpl?
<bluefoxicy> yeah apparently they were tired of AOL trying to sue them
<Burgundavia> bhale: yep
<bluefoxicy> and AOL was tired of running into a corner and hiding under a newspaper when they realized every new GAIM developer still had lawyers
<bluefoxicy> (they would try again when a new dev took lead of the project)
<_ion> The feisty gaim package could still be modified to "Provides: pidgin", no?
<Fujitsu> A little late for that, and there's little reason.
* StevenK quite liked the name gaim
<StevenK> I daresay Debian will handle it, and we'll get a sync for Feisty+1
<sn0> nn <3
<desrt> is debootstrapping ubuntu-desktop likely to result in even a marginally working system these days?
<crimsun> yes. We're reasonably close to RC, so I'd hope so.
<desrt> i actually meant that in the general sense
<desrt> as in: is this a supported way of installing a working ubuntu system?
<crimsun> supported, no.
<crimsun> Does it work? Yes.
<desrt> that's nice.
<desrt> i'm just afraid of all the other magic things that the installer does that won't be done :)
<crimsun> Granted you'll have to do some infrastructure work yourself with locale-gen, tzconfig, etc.
<crimsun> well, right, that stuff you'd have to do by hand.
<desrt> hah.  feisty lacks 'man'
<desrt> wow.
<desrt> you can tell space is getting tight on the CD when...
<desrt> it is mez.
<Mez> it's Mr Lortie
<desrt> how are you today, sir?
<Mez> I'm not a sir yet!
<Mez> And I'm tired, just got home from work
* desrt fscks 500GB.  party.
<desrt> probably doesn't help that this drive has millions of inodes.....
<desrt> (like... 70 million of them)
<jdong> ouch
<jdong> that'll be a pain
<jdong> took MIT in excess of 4 days to fsck the mailserver, to the point that they gave up on the procedure
* jdong had a fantastic excuse why he couldn't do his homework that week!
<Hobbsee> hahhaa
* Hobbsee likes
<Hobbsee> excuses for homework not being done are always good :)
<jdong> yes they certainly are
<jdong> now what's the excuse for why my laundry hasn't been folded 3 hours later....
<jdong> hmm.....
<Hobbsee> it rained
<desrt> blame it on the rain?
<jdong> lol :)
* desrt goes desrtilli
<Hobbsee> yes.
<desrt> god
<desrt> erasing all these files is gonna take FOREVER
* desrt would almost be better off creating a new fs....
<desrt> ext3 really doesn't scale too well
<jdong> well which FS'es erase well?
<jdong> basically only reiserfs....
<ctan> Hi, can anyone give me information regarding the SoC?
<desrt> the reason i erase is because it does everything else so poorly :p
<desrt> ctan; this is pretty much exactly the wrong place to ask :)
<desrt> ctan; but what did you have in mind?
<ctan> well, I submitted my proposal pretty early, but I'm not sure if I was supposed to add it to the SoC wiki too
<desrt> nope.
<desrt> all tracking is done through the google interface
<desrt> if your proposal is in there then you're fine
<ctan> oh okay, thanks :)
<ctan> could you tell me which channel would be more related to SoC? 
<desrt> i'm actually not sure for ubuntu
* desrt is mentoring for a different project
<ctan> cool, what project is that ?
<desrt> gnome
<ctan> did you get a lot of good proposals?
<desrt> most of the proposals were ones that we would not accept, but we definitely have more than enough good ones
<ctan> I looked through SoC 2006 accepted proposals, and the nicest ones that I could find were for AbiSource & Internet2
<ctan> desrt; is it usually so dead in here, or is everyone just using private messages?
<desrt> it's usually more active in here.  it's a holiday weekend, though
<desrt> it's also a week before a release so those few people who are on their computers have lots of work to do :)
<Burgundavia> are the accepted proposals out yet?
<ctan> ah yes, i'm pretty excited about that
<desrt> Burgundavia; on wednesday
<ctan> nope, not until the 11th
<desrt> at "5pm"
<desrt> but i wouldn't be too suprised if they're a bit late
<desrt> google is tragically optimistic :)
<ctan> my application's last modified date still hasn't changed, so I think Ubuntu must be swamped
<desrt> the mentor interface to SoC allows us to rank and comment on your application without you seeing the change
<desrt> there's also the possibility that your application immediately got ranked negatively and hasn't been looked at since
<ctan> hehe yep :P
<miyako> hey, I think I found a bug in the Feisty installer
<miyako> just though I would stop by and report it, see if there was any debugging info that would be useful to anyone
<LaserJock> ok, file a bug on Launchpad
<miyako> alright
<LaserJock> https://launchpad.net/ubuntu/+filebug and the Desktop cd installer package is called ubiquity
<Saied> hi all
<Saied> Seveas: problem with pngtobogl elready exists
<Saied> can anyone help me in usplash customization?
<Saied> i generated usplash-artwork.so but cant be loaded at boot time
<Saied> how can i debug that?
* Hobbsee contemplates fixing oo.o
<Hobbsee> https://bugs.launchpad.net/ubuntu/+source/openoffice.org/+bug/104176/
<ubotu> Malone bug 104176 in openoffice.org "openoffice.org-style-crystal recommends  kde-icons-crystal which pulls in KDE for ubuntu users" [High,Confirmed]  
<LaserJock> don't ... do ... it
<Hobbsee> LaserJock: why?
<LaserJock> no reason
<LaserJock> I just like saying that ;-)
<Hobbsee> LaserJock: apart from the fact htat it's oo.o, and that i wouldnt be test building it, for that reason.
<Hobbsee> holy mashed potatoes... https://bugs.launchpad.net/ubuntu/+source/openoffice.org/+bug/104176/
<ubotu> Malone bug 104176 in openoffice.org "openoffice.org-style-crystal recommends  kde-icons-crystal which pulls in KDE for ubuntu users" [Critical,Confirmed]  
<jdong> LaserJock: that's kinda what I was told when I wanted to plug in that 20,000-turn electromagnet to a marine battery....
<Hobbsee> Need to get 309MB of source archives. sorry
<LaserJock> jdong: hmm
<jdong> Hobbsee: it'll unpack to in excess of a 8GB build environment and take 9 hours on a P4 :)
<Hobbsee> jdong: that's why i wont test build
<jdong> Hobbsee: that's about one of the only things I learned from gentoo ;-)
<Hobbsee> lol
<LaserJock> 9hr?
<jdong> LaserJock: it was 9hr on my A64 3000+
<jdong> LaserJock: stock gentoo emerge openoffice.org
<LaserJock> I must have been a while since I compiled it
<LaserJock> I never remember it taking that long on gentoo
<jdong> LaserJock: I'm not sure if advances in the compiler stack have reduced it
<LaserJock> KDE was always the killer
<jdong> LaserJock: honestly most people emerge openoffice.org-bin
<jdong> LaserJock: not the whole openoffice.org source build....
<LaserJock> well, it's been a couple years
<jdong> LaserJock: OOo takes absurdly long to build
<jdong> it's not even funny
<jdong> longer than all of KDE combined.
<LaserJock> hmm
<jdong> you most likely just emerged openoffice.org-bin :D
<LaserJock> yeah, I remember before they split it all up
<jdong> or ximian-openoffice.org-bin
<LaserJock> nah, I built it a few times
* jdong liked the Ximian variant back then
<jdong> LaserJock: lol once I put /var on a 4GB partition....
<jdong> kinda didn't think ahead on that one :D
<LaserJock> my memory must have been off
<LaserJock> it was probably during one of the "oh, openoffice and KDE updates, I'll come back next week" moments ;-)
* Hobbsee notes she's using someone else's bandwidth to do this fix...
<jdong> hehehe :)
<LaserJock> man I loved Gentoo
<jdong> I gotta say it was a fun ride
<LaserJock> but thank goodness Ubuntu came around
<jdong> as much as I complain about it nowadays, I did have a lot of fun with the OS.
<jdong> and Ubuntu came just when I lost faith in Gentoo
<jdong> perfect timing
<LaserJock> yeah, my problem was always that I never cared about building from source or optimization
<LaserJock> I just loved that darn near every Linux app I ever wanted was an emerge away
<jdong> I went to gentoo for its up-to-date repos and vast breadth of portage
<LaserJock> yep
<jdong> I stayed with it for its community.... Inflammatory at times? most certainly... but some of the most effin creative minds of what you can do with a Linux system
<jdong> I left because of growing QA issues with updates, and also the rolling updates systems often left upgrade "surprises" for me to fix at the most inopportune times
<ctan> doesn't that happen with ubuntu too though?
<sharms> ctan: in theory no.
<jdong> ctan: not nearly as much
<jdong> ctan: our QA mishaps are childsplay compared to some of the Gentoo beefs
<jdong> the most infuriating one I remember.. they were pushing a critical mysql security fix....
<jdong> and the package forgot to install libmysqlclient40.so
<jdong> which effectively zapped the LAMP stack
<jdong> ctan: and Ubuntu has fixed update intervals. That is, you deal with major changes every time you choose to upgrade to a new release
<jdong> incremental security/bugfix updates are very unintrusive
<jdong> you will never apply an apache update to a released version , then have it refuse to start because configfile syntax changed
<ctan> ahh, I've never tried gentoo before
<ctan> their online documentation is really good though
<sharms> yes their wiki is very good
<jdong> their documentation and wiki are both superb
<jdong> and the tips/tricks section of their forum is even better
<jdong> they have some of the neatest mods to a gentoo system
<jdong> such as a squashfs root, or a completely boot-to-RAM system
<ctan> is it really much faster to have something compiled vs downloading a binary?
<jdong> I wouldn't say so
<jdong> what makes gentoo 'faster' is more related to the fact that via USE flags, users can exclude unneeded functionality
<jdong> it's that extra level of customizability that gives gentoo the edge in that regard
<jdong> (also they usually choose not to apply any patches that add certain features at the cost of performance)
<ctan> but with even more tweaking needed :-O
<jdong> ctan: frankly I think the time spent tweaking/configuring/maintaining is not even remotely close to being justified by the 'performance gains'
<ctan> yes, that's why I'm using windows
<ctan> uh oh don't flame me :P
<jdong> :)
<ctan> I love ubuntu-server though
<ctan> except my USB was broken from dapper -> edgy
<ctan> I think I will be switching to ubuntu for desktop soon, once I get starcraft running under wine
<jdong> lol starcraft works ok under wine
<jdong> just no battlenet
<jdong> (but this is terribly off topic :D)
<ctan> yes :)
<ctan> i'm going to sleep, g'nite
<cjwatson_> desrt: huh? feisty does not lack 'man'
<cjwatson_> desrt: sounds like you forgot to install ubuntu-standard
<Nafallo> man-db even :-)
<cjwatson> apt-cache show man-db, I know what the package name is ...
<cjwatson> but desrt was talking about /usr/bin/man
<Nafallo> ah. I thought that was the package for that bin :-)
<Nafallo> cjwatson: dooh. are you the maintainer for EVERYTHING important? :-)
<cjwatson> I took on a fair amount of core stuff about five or six years ago
<Hobbsee> Nafallo: no, not upstart.
<nhy> what are the correct opengl headers for ubuntu?
<Nafallo> Hobbsee: he might aswell have the old init though ;-)
<Hobbsee> :P
<Nafallo> sysvinit, that's the one :-)
<Hobbsee> nhy: #ubuntu for support
<nhy> sorry
<chaks> hi all
<chaks> is there anybody with whom i can discuss regarding Ubuntu AcademicInvolvement as given in this page - https://wiki.ubuntu.com/AcademicInvolvement
<chaks> thanks
<chaks> if this is not the right channel, am sorry :(
<Hobbsee> chaks: interesting
<chaks> thanks Hobbsee, but not sure which channel I should use :)
<chaks> am a Masters Student in University Of Otago
<Hobbsee> chaks: probably not here.  maybe #ubuntu-motu.  anyway, i'd look for dholbach, who is the guy who wrote that
<chaks> and want to discuss regarding my project
<Hobbsee> lots of people are on holidays at the moment
<chaks> oh..yea, Easter!
<Hobbsee> (the people who'd be able to point you in hte right direction)
<chaks> :D
<Hobbsee> yeah
<chaks> anyways, thanks Hobbsee, will check the #ubuntu-motu channel too
<Hobbsee> come back in a couple of days, look for dholbach - he can at least point you to where you shoudl go
<Hobbsee> :)
<chaks> sure :)
<chaks> brb
<Pupeno_> Hello.
<chaks> hi Pupeno_
<Hobbsee> Pupeno_: please see the /topic
<Pupeno_> Hobbsee: yes.
<Hobbsee> :)
<\sh> moins
<Nafallo> morning
<zyga> hey 
<zyga> re
<zyga> thank you guys
<mjg59> tepsipakki: Hm. When you changed wacom-tools to use /dev/input/wacom, did you update the X server config to match?
<Nafallo> according to changelog, he did.
<mjg59> Ah, yeah
<mjg59> I was looking at the wrong package
<tepsipakki> mjg59: yes, it should be fine now
<mjg59> tepsipakki: Yup, looks good. Thanks!
<okaratas> released for debian 4.0 "etch"
<Zic> hello, I have a particular question : in Kubuntu Feisty, the OEM installer is pretty cool, and simply, in Ubuntu Feisty, we always have a poor graphic OEM ...
<Zic> anything is planned for this ?
<desrt> cjwatson; i just installed the herd5 cd...
<Pupeno_> I think I've found at the very least, an incompatibility between Edgy's and Feisty's cryptsetup
<Hobbsee> Pupeno_: please file a bug on it
<Pupeno_> If any dev whishes for my help in debugging this, I'll be willing to spend some hours in it before I remake my crypted FS restoring the backup.
<Pupeno_> Hobbsee: I will.
<Hobbsee> seeing as the relevant devs probably arent here
<Pupeno_> obviously, my password to launchpad is on the encrypted FS... :/
<stgraber> Pupeno_: What kind of problem is that ? (I'm not a developper but I've seen some cryptsetup bugs on LP)
<Pupeno_> stgraber: the encrypted FS is not readable.
<Pupeno_> stgraber: encrypted in Edgy, not readable in Feisty.
<stgraber> Pupeno_: even if you try to mount it manually from the LiveCD for instance ?
<Pupeno_> stgraber: I don't have a Feisty LiveCD, but from the Edgy LiveCD it is readable.
<stgraber> ok, so when do you actually see the problem ?
<stgraber> at boot time ? after ?
<Pupeno_> stgraber: when I try to mount the mapping.
<Pupeno_> stgraber: manually, on the Feisty install (which was upgraded from Edgy).
<Pupeno_> stgraber: it was supousedly to mount automatically, but nevermind that.
<Pupeno_> stgraber: I tried fscking it and what is found doesn't resemble a partition.
<stgraber> :(
<Pupeno_> a filesystem I mean.
<jdong> I would expect fscking an encrypted partition would be a pretty futile operation ;-)
<Pupeno_> jdong: I am fscking the unencrypted mapping of the partition.
<sharms> jdong: I *tried* to resize my ext3 partition, but I didnt realize that ubuntu automatically mounts it, fsck'd it and then updated fdisk for new size
<jdong> ah, ok
<sharms> it died.
<jdong> sharms: ouch
<jdong> sharms: I did the same to my XFS the other day -- I remounted it ro to repair it
<sharms> ofcourse there is no good way to find superblocks if you resize
<jdong> sharms: but it turns out mount lies
<jdong> and it wasn't ro....
<sharms> ooooh
<sharms> ha that is why for now on I am keeping all my important data written down on sticky notes next to my desk
<sharms> I think it is the future of datastorage
<jdong> lol
<jdong> or you can try backups like what I fortunately did :D
<sharms> I dont backup my files, I just generally assume they exist in more than 1 place
<jdong> lol :)
* Pupeno_ keeps two HDs of backup, one updated often, next to the computer, and the other updated less often, hidden in the house.
<jdong> I have a friend who does that :)
<Pupeno_> When I travel I take only one of the and leave the other behind.
<jdong> it turns out his assumptions are kinda flawed
<jdong> like he has a RAID0....
<jdong> and 2 months ago he swapped out one member for a faster drive
<jdong> and last week that faster drive died
<jdong> and he plugged in the 2-month-old one
<jdong> and expected it to work somehow
<jdong> that was a fun phone call :)
<sharms> haha
<Pupeno_> brb.
<jdong> to make matters worse, he is an AVID defragger :)
<jdong> so I basically had to tell him he has 4kb perforated versions of all his files now :D
<pupeno> I'm back.
<pupeno> Ok, I've reported my problem on: https://bugs.launchpad.net/ubuntu/+source/gnome-mount/+bug/88213/comments/25
<ubotu> Malone bug 88213 in gnome-mount "Feisty does not mount encrypted partition" [Medium,In progress]  
<pupeno> Does anybody know any other tests I could run to provide a good report of the problem before re-installing? [about bug 88213] 
<ubotu> Malone bug 88213 in gnome-mount "Feisty does not mount encrypted partition" [Medium,In progress]  https://launchpad.net/bugs/88213
<vciaglia> hi, i think there's a problem with firefox on amd64. When i use multiple tabs and i try to close one of them... i have a server X restart!
<andreasw> Hi I use feisty and my CDs get ejected after some time
<andreasw> [31145.776312]  ata2: soft resetting port
<andreasw> [31148.910237]  ata2.00: configured for UDMA/33
<andreasw> [31149.074351]  ata2.01: configured for UDMA/33
<andreasw> [31149.074374]  ata2: EH complete
<andreasw> [31160.854855]  sr0: CDROM not ready.  Make sure there is a disc in the drive.
<andreasw> I find this in the logs
<Seveas> !bugs | andreasw 
<ubotu> andreasw: If you find a bug in Ubuntu or any of its derivatives, please file a bug report at: http://bugs.ubuntu.com/  -  Bugs in/wishes for the bots can be filed at http://launchpad.net/products/ubuntu-bots
<sharms> andreasw: the best idea there is to check the integrity of the cd first, and also it looks like your cdrom drive might be getting ready to go
<sharms> andreasw: most cdrom drives are made very cheap, wouldn't be the first time
<andreasw> it worked with 6.10 it works with windows it works with arch it works with freebsd
<andreasw> but of course it is a hardware problem
<mjg59> The libata ATAPI code is known to be dubious in places
<mjg59> It's entirely plausible that it's a kernel problem
<mjg59> andreasw: It would be helpful if you could file a bug with that information, and possibly thee previous few lines of dmesg
<sharms> andreasw: it is no reason to get mad about it, I am simply saying it was possible
<andreasw> it only occurs with audio cds however...
<andreasw> data cds aren't ejected
<jdong_> mjg59: I think it might be a libata issue too; those don't look like ordinary unreadable-disc kind of errors
<mjg59> Interesting.
<mjg59> jdong_: Those are just the libata "An  error occured, trying tor ecover" messages
<andreasw> the funny thing is k3b reads out from cd even if there isn't any cd in the device
<andreasw> it sounds a little bit strange than
<andreasw> the output I mean
<finalbeta> Anyone for the kernel here? I'm starting to fear Feisty could air with this bug https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.20/+bug/98782 , And that would render it unusable for me. Check out the latest attached dmesg. I hope I don't overstep any boundaries here, but the desperate... :p.
<ubotu> Malone bug 98782 in linux-source-2.6.20 "kernel 2.6.20-12/13-386 on Dell Inspiron 8200 means 10 minute boot time" [Undecided,Unconfirmed]  
<finalbeta> It's 15 minutes with la latest kernel.
<sharms> finalbeta: I bet there are kernel people at #ubuntu-kernel
<finalbeta> Ok, thanks.
<andreasw> so many ata bugs
<finalbeta> The forums are showing many people with ata problems also. But for many it just seems to be a slower UDMA mode. But one can expect allot of nagging at Feisty release.
<sharms> pitti: is that release date 100% or is there a chance it gets pushed back?
<Treenaks> sharms: there is always a change it gets pushed back.. however slight :)
<Treenaks> change=chance
<sharms> I am hoping so, the amount of open bugs is alarming
<Treenaks> sharms: you could submit patches :)
<sharms> Treenaks: patches are preceded by triaging or organizing, and there is enough triage to last weeks
<pitti> sharms: only major regressions/problems will cause it to slip
<seb128> hi
<seb128> pitti: around?
<robertj_> would this fix the legions of "samba doesn't work" posts related to not creating samba users? --> https://wiki.ubuntu.com/SimpleSambaIntegrationSpec
<robertj_> there are at least 3 bugs opened against that issue a week
<robertj_> can someone *pretty-please* take a look at that just to give a first impression/
<thepumpkin1979> hi. is there a way to trim the memory workingset for a process?
<ColonelKorn> Hey all
<Burgundavia> fabbione: you around? I wanted some information on the new clustering stuff in feisty for the release notes
<bongy> I want to make a PPC64 build of Ubuntu (for Xbox 360) was thinking about a short cut via apt-get source and debootstrap but maybe there is buildscript out there? Sry if asking in the wrong channel
#ubuntu-devel 2008-03-31
<emgent> \sh_away: ping
<calc> anyone familiar with app-installer?
<calc> bug 113358
<ubotu> Launchpad bug 113358 in openoffice.org "[Ubuntu] [hardy] openoffice.org-math missing in gnome-app-installer and not installed with OpenOffice Writer" [Low,In progress] https://launchpad.net/bugs/113358
<calc> i did what colin suggested but it didn't help
<ScottK> slangasek: Do you recall the Postfix backports problem with Soyuz having grown the 'feature' of not looking into Universe for build-deps in backports?  Well postgres 8.3.1 is now hung up on the same problem.
<mattismyname> So, I'm trying to build a package of a library (my first try...).  This library can make use of other libraries if they exist on the system, but it does not require they be present (libtiff, libpng).  My question is...should I include these on the Build-Depends: line in the package control file?
<RAOF> mattismyname: Probably better answered in #ubuntu-motu
<jdong> mattismyname: if you feel that the functionality provided by building with such libraries present would be desired by users, it's probably a good idea to put them as build depends.
<mattismyname> RAOF, jdong: thanks
<mattismyname> More than likely, the users would want this additional library support so I will add it.  Will check w/ #ubuntu-motu as well.
<TheMuso> 5~/c
<RAOF> TheMuso: Good morning :)
<TheMuso> Hey RAOF. How goes it?
<RAOF> TheMuso: Eh, pretty well.  I'm being forced to get up early, though :)
<RAOF> TheMuso: How be your fine self?
<TheMuso> RAOF: Busy, but well thanks.
<RAOF> Eeexcellent.
<twb`> Is this the most appropriate channel for discussing the guts of the python-launchpad-bugs package?
<lifeless> I suspect so
<lifeless> here or #ubuntu-bugs, but I would say here
<twb`> Righto.  I want to extend reportbug so that, out of the box on Ubuntu systems, it talks to launchpad rather than a subscriber-only mailing list (which is what it does currently).
<twb> Or at least better understand how to programmatically query and modify launchpad's BTS subsystem.
<lifeless> There will be a short interruption to bazaar.launchpad.net and the ubuntu wiki to deploy a fix for the performance problems.
<calc> doko: ping
<calc> mjg59`: what will you be doing at redhat (if its not NDA/secret)?
<mweichert> hey guys, anyone know how to get unicode support in bash? I'm trying to paste a unicode-type string but any character outside ISO-8859-1 is not displayed
<twb> mweichert: that could be a problem with the app you're copying from, your terminal emulator, or your locale setting.
<twb> mweichert: regardless, this channel is probably not the appropriate place to discuss it.
<mweichert> twb: okay, sorry... do you know where I might ask?
<twb> mweichert: are you using Ubuntu Gutsy?
<mweichert> twb: yes
<twb> mweichert: #ubuntu, if you can handle the very high traffic.
<twb> mweichert: what terminal emulator are you using?
<mweichert> twb: mac os x terminal ssh'd on to a gutsy vps
<twb> Oh.  Then you should ask ##macosx, since this is very likely to be a problem on the OS X side.
<twb> But make sure the `locales' package is installed on the VPS.
<mweichert> twb: okay, thanks for your help. The locates packages is installed but locale -a produces C and  POSIX.
<mweichert> I think I should have UTF-8 in there, no?
<mweichert> looking at my terminal settings too, I have the charset set to UTF-8
<twb> mweichert: yes, try dpkg-reconfigure -plow locales.  I'll say no more on this here, since it's off-topic and I've talked too much already.
<mweichert> twb: okay, thanks again
<JohnPhys> My apologies if this is off-topic, but what are the plans for Firefox 3 upgrades with respect to Hardy?  Specifically, when FF3 is released in June, are there plans to upload that to the repositories, or will FF3 be "frozen" at the version included in the repos at release time?
<twb> IIUC the standard policy is that only critical upgrades (e.g. security fixes) enter a released version.  I don't know if a release (i.e. not beta) Firefox 3 would count as a critical upgrade, but I doubt it.
<twb> I expect a post-beta firefox 3 would be added to the standard hardy-backports repository.
<ScottK> I've heard, but am not certain that they will update it to final.
<RAOF> Firefox is a pretty special case.  We seem to be adding new stable releases of ff2 to -updates.  Unless I'm imagining that.
<ScottK> We are because that's how we get security fixes.
<twb> Haha
<protonchris> ScottK: I noticed that wxglade was uploaded.  Thanks.  For some reason, LP didn't mark it fix release.  Should I go ahead and mark it fixed?
<RAOF> I suspected as much.
<ScottK> protonchris: I didn't actually upload it, so no thanks needed here.  If it's definitely uploaded, then yes.
<protonchris> ScottK: ok.
<JohnPhys> Thanks for the info.  I wasn't sure if FF3b4 -> rc's -> final was similar to a 2.0.0.x -> 2.0.0.(x+1) release, or the 1.5 -> 2.0 release in dapper, where the package wasn't updated because too many other things depended on the rendering engine and such (iirc).
<warp10> Good morning
<geser> good morning
<JohnPhys> Why the gnome-system-tools package not installed in Hardy beta by default?  Is there another way to use a gui to set up smb/nfs file shares?  I tried searching the forums, bugs, blueprints, and answers, and didn't see anything obvious.  Thanks for your time (and the great distro!)
<dholbach> good morning
<JohnPhys> good evening
<twb> JohnPhys: that question may be more appropriate for #ubuntu+1.
<JohnPhys> twb:  thanks, I'll post it there.
<pitti> Good morning
<geser> Guten Morgen pitti
<dieman> cjwatson: heh, just saw your updates come through on my bug, thanks!
<dieman> cjwatson: im no longer working where I maintain a ton of ubuntu boxes, but i let the guy who took over for me know he gets to make 2 less hacks to the initrd
<dieman> well, to the packages, rather
<dieman> anyhow
<Hobbsee> evening
<soren> No, it's not.
<Hobbsee> morning for you backwards people, then.
<soren> Rather backwards than upside down. :p
<Hobbsee> depends.  you are behind, timewise
<Hobbsee> dholbach: when's the next CC meeting?
<mdke> we haven't set one yet. We should though
<Hobbsee> looks like we've got a few people for your loving care and attention.
<mdke> we really need the regional membership boards up and running too
<Hobbsee> yes, i thought that was supposed to be done ages ago?
<mdke> yeah
 * Hobbsee looks at the CC agenda.
<Hobbsee> most of this should get thrown out, lacking proof.  excellent.
<Hobbsee> mdke: holy hell.  you'll enjoy dealing with all of that.
<mdke> blimey. I wonder if that is the same chap who has been emailing us
<Hobbsee> mdke: likely.
<orbisvicis> have any of the ubuntu patches on autoconf/automake affected mkdir_p vs MKDIR_P ?
<saispo> hi, anydebconf expert here ?
<saispo> any debconf, sorry
<james_w> saispo: do you have a specific question?
<saispo> yes but i found the answer, excuse me :)
<james_w> no problem
<saispo> i just want to hide critical question and i found DEBCONF_FRONTEND=noninteractive solve my question :)
<orbisvicis> anyone find issues with autotools and mkdir_p vs MKDIR_P ?
<cjwatson> dieman: you're welcome - sorry it took a while
<ion_> Hi cjwatson
<ion_> cjwatson: I modified the compcache packaging to use debconf for the cache size setting. Should be possible to preseed the value to something bigger on a live-/install-CD considering that there may be no swap partitions.
<cjwatson> ion_: sounds good
<seb128> carlos: hey
<seb128> carlos: could you approve the nautilus-share template if that has not been done yet?
<carlos> seb128: let me check...
<seb128> carlos: it has been promoted some days ago and uploaded on saturday
<carlos> seb128: approved
<seb128> carlos: thanks
<carlos> np
<warp10> Hi all!
<siretart> could someone from the release team please comment on bug #204557? - security fixes are pending here...
<ubotu> Launchpad bug 204557 in xine-lib "Freeze exception for xine-lib 1.1.11" [Undecided,New] https://launchpad.net/bugs/204557
 * pitti builds new -base langpacks for hardy
<seb128> pitti: will you have nautilus-share in those?
<seb128> pitti: it has been accepted only this morning in rosetta
<pitti> seb128: no, the tarball is from March 26
<pitti> I don't know why they lag so badly, it was generated last night
<seb128> ok
<pitti> seb128: after that I'll reenable the automatic semiweekly uploads (I disabled the cron for the -base refresh)
<seb128> ok
<pitti> siretart: I added a comment to the bug; please go ahead
<siretart> pitti: oh, the update from 1.1.10 to 1.1.11 isn't bugfix only. still, I'm very much in favor of doing it anyways!
<pitti> siretart: hm, it says so in the bug report
<siretart> the bug says: "in the mean time, a bugfix only release (1.1.11.1) has been uploaded to debian".. - I was adding a comment in the bug that I propose to integrate that bugfix only update as well
<siretart> still, the update from 1.1.10 to 1.1.11 wasn't approved yet
<pitti> siretart: the description says "I propose to merge the new debian upload of xine-lib 1.1.11.
<pitti> It consist of security updates and bugfixes. No new features have been added."
<pitti> siretart: so is that a different bug# then?
<siretart> pitti: I'm sorry that wasn't really clear. There have been no real new features and only bugfixes, but the diff is still rather large
<siretart> I wasn't sure if you're comment referred only to my last comment or to the whole bug. Now it is clear
<siretart> thanks!
<pitti> siretart: right; but I guess you tested them, and verified the changelog, so it should be oke
<pitti> s/oke/ok/
<frandavid100> hiya
<siretart> pitti: not yet the very latest version, which I'm testing this afternoon
<siretart> but the diffs looks pretty sane, so I'm confident (will still testbuild/test)
 * pitti hugs siretart
 * siretart hugs back :)
<Hobbsee> mdke: can you make sure you give us (irc council and related people) notice, when you decide on a date for the next CC meeting please?
<kwwii> anyone know how to set the Xephyr size so that I can get a screenshot of gdmthemetester for the gdm theme?
<Riddell> ArneGoetje: any idea why qt 4 might use Nimbus over Deja?  bug 209358
<ubotu> Launchpad bug 209358 in qt4-x11 "fonts in Qt4 look ugly because it uses Nimbus Sans L instead of Deja Vu Sans for Sans-Serif" [Undecided,Confirmed] https://launchpad.net/bugs/209358
<jc-denton> https://bugs.launchpad.net/ubuntu/+bug/209632
<ubotu> Launchpad bug 209632 in ubuntu "[Hardy] CPU freq scaling does not work anymore with the newest kernel" [Undecided,New]
<jc-denton> can anybody confirm this?
<Ng> seb128: re bug 198857, is it likely that we can get something in hardy to turn previously mounted shares into bookmarks? I don't so much care about the aspect of the bug with the desktop icons not being around anymore. i can tell users to go into Places->Bookmarks, but I'd prefer not to have them set up the shares again
<ubotu> Launchpad bug 198857 in nautilus "gnome-vfs network servers are not migrated to gvfs on upgrade" [High,Triaged] https://launchpad.net/bugs/198857
<seb128> Ng: if you send a patch yes, otherwise not likely no
<Ng> ok
<seb128> Ng: there was no mounts in gnomevfs, those were sort of bookmarks
<Ng> yes sorry, "mounts" is poor wording. "server connections" or something maybe
<seb128> do you think it's important to migrate those?
<Ng> seb128: for users like me? not at all, I can recreate them in seconds. however, I suspect it's more likely that features like that are used by less technical users (e.g. most of our business folk use them and set them up by following screenshots)
<Ng> but I'm not even sure where gvfs/nautilus stores the new stuff, so I have no idea how hard it would be to migrate them
<Ng> obviously we're a bit late in the game now
<emgent> hello people
<zorglu_> q. im looking for Jorge Castro on irc, i cant find him. anybody knows if he is on irc ?
<seb128> Ng: there is no such servers now, gvfs does automatic mounting when accessing the share
<Ng> zorglu_: see jcastro
<zorglu_> Ng: thanks
<seb128> Ng: they would need to be added to .gtk-bookmarks
<Ng> seb128: aha. is there any mechamism for doing upgrade related tasks on the first login after upgrading?
<chand> jc-denton: perhaps there is a link between  209632 ansd
<chand> jc-denton: perhaps there is a link between  209632 and https://bugs.edge.launchpad.net/ubuntu/+source/linux-source-2.6.22/+bug/183033
<ubotu> Launchpad bug 183033 in linux-source-2.6.22 "Intel Core 2 Duo - Resume from suspend, CPU Frequency Scaling is gone on CPU1" [Undecided,Confirmed]
<jc-denton> chand: i had this problem before
<jc-denton> all i had to do was changing the governer back to powersave
<seb128> Ng: no, but we could add an autostart entry comparing versions and doing that
<Riddell> ArneGoetje: ubiquity doesn't launch on the kubuntu-kde4 CD, it says "scim-bridge: Cannot establish the socket connection" in syslog
<_MMA_> seb128: This "automounting" is giving me issues. I gotta figure out whats going on. I use the "crossmnt" option on my NFS server and its mounting one of those subfolders as if it were the main share.
<seb128> no idea what crossmnt is and what main share means in this context
<ogra_cmpc> i guess he means the exported dir with "main share"
<seb128> slangasek: could we have a 8.04.1 milestone on launchpad?
<_MMA_> seb128: Sure. I guess you would need to be familiar with the various NFS options. :P
<ogra_cmpc> nfs usually allows you to mount everything as you like below an export, so that no surprise
<seb128> ogra_cmpc: no idea what it means, for me mounts have a mount points and that's all
<ogra_cmpc> *tahts
 * ogra_cmpc curses his typoing 
<ogra_cmpc> i want a brain to kbd interface, damned
<theunixgeek> Would anybody like to test a program? :)
<_MMA_> ogra_cmpc: I couldn't mount some of the subfolders without defining them in the exports file. I also needed the "nohide" (deprecated) or "crossmnt" option to see some subfolders.
<ogra_cmpc> seb128, i dont have a clue what crossmnt is or does either, i want just antig to point out that such behavior is totally fine from an nfs POV
 * ogra_cmpc sighs
<ogra_cmpc> * was just wanting to point out
<seb128> _MMA_: open a bug with a description explain what the issue is in a non too technical wording with a simple testcase, what it does and what else you expect
<ogra_cmpc> _MMA_, ltsp uses /opt/ltsp in /etc/exports ... the clients usually mount /opt/ltsp/$arch for example ... NFS allows everything below the exported dir to be mounted as you like
<seb128> _MMA_: because right now I don't understand what you are asking
<_MMA_> seb128: Sure. Plan for today was to look over it more then do just that. Ill add screenshots as well.
<seb128> there is already some bugs about automount and nfs
<seb128> make sure your issue is not a duplicate if you can
<_MMA_> Sure.
<seb128> thanks
<kwwii> ogra_cmpc: you might want to look into the human icon theme .links file and add the symlinks to gartoon
<phaidros> any hints on hardy nvidia+compiz on a dualhead, which often does not refresh the upper .. uhm .. fifth of the screen?
<ogra_cmpc> kwwii, oh, more links ?
<ogra_cmpc> i r4ecently added a bunch already
<ogra_cmpc> kwwii, thanks for the heads up
<kwwii> ogra_cmpc: glad to be of help :-)
<ogra_cmpc> kwwii, is that uploaded already ? the package i get from the archive doesnt seem to have a .links file
<ogra_cmpc> human-icon-theme-0.24
<kwwii> ogra_cmpc: I just commited half an hour ago or so
<ogra_cmpc> ah, k
<_MMA_> ogra_cmpc: Sorry. I PMed by you're not identified.
<ogra_cmpc> right
<_MMA_> s/by/but
<ogra_cmpc> just wanted to mention that :)
<_MMA_> :P
<ogra_cmpc> in any case nfs behaves correctly here according to your description in the pm
<ogra_cmpc> gvfs might notice that the subfolders are actual devices on the server (even though i wouldnt know how it would do that)
<ogra_cmpc> so it mounts them like extra devices
<_MMA_> ogra_cmpc: On my Gutsy boxes yes. The 2 hardy ones, not for me. I'll file a bug and see how it goes.
<ogra_cmpc> right
<ogra_cmpc> gutsy doesnt use gvfs
<ogra_cmpc> it uses gnome-vfs
<_MMA_> But yes. It mounts a subfolder like an extra devise.
<_MMA_> *device
<tjaalton> Riddell: there's bashism in desktop-effects-kde: 25enable-compiz. I get "[[: not found"
<Riddell> tjaalton: do you know what the fix it?
<Riddell> is?
<tjaalton> Riddell: yes, use single brackets
<Ng> http://wooledge.org:8000/BashPitfalls#head-ad3f850ae3fdcf9751b0eef6451b92ee1d040bef :)
<Riddell> tjaalton: thanks, fixing
<tjaalton> Riddell: thanks
<jc-denton> https://bugs.launchpad.net/ubuntu/+bug/209632
<ubotu> Launchpad bug 209632 in ubuntu "[Hardy] CPU freq scaling does not work anymore with the newest kernel" [Undecided,New]
<jc-denton> any ideas?
<pitti> zul: how is debian bug 365097 solved in hardy?
<ubotu> Debian bug 365097 in bacula-common "bacula-common: Uses the same passwords on every Debian installation" [Important,Open] http://bugs.debian.org/365097
<zul> pitti: we include a gawk script that messes with the catalog
<pitti> zul: do we have a debconf question for the password, or something such?
<zul> pitti: kind of, I forget how it works now but that problem has been fixed
<pitti> zul: ok, thank you
<zul> pitti: np
<pitti> zul: can you please add that to the MIR? looks kinda scary ATM :)
<zul> pitti: sure :)
 * warp10 hugs (and thanks) pitti
<pitti> hi warp10
<pitti> zul: looks like it: "db_input critical bacula/dba_password"
<pitti> zul: I checked the mysql postinst, it uses that apparently
<zul> pitti: yep I was going to put that in the MIR report.
<zul> pitti: done
<pitti> zul: thank you
<zul> er you get the email never mind ;)
<pitti> zul: promoted, see bug
<zul> pitti: sweet..
<asac> siretart: fyi, http://paste.ubuntu.com/6260/ ... thats what was needed to make wpasupplicant bring up the global control socket again.
<asac> siretart: but i guess its fixed in 0.6.x
<siretart> asac: oh, interesting.
<siretart> nm unlinks the supplicant control socket?!
<asac> siretart: yes. and i need SIGKILL as well
<asac> otherwise it looks like it cannot acquire the control socket on every second startup here
<siretart> I can feel your antipathy regarding wpasupplicant :)
<jdong> HOLY CRAP update-manager just gave me a 20-digit ETA!
 * mvo coughs
<mvo> jdong: during download or install (or both)?
<jdong> mvo: during download; my wifi lost association for around 15s
<jdong> when it came back, update-manager must've gotten spooked :D
<ScottK> jdong: The Main/Universe issue is still a problem for backports.  postgres 8.3.1 is currently hung up on it.
<pitti> ScottK: hm?
<nxvl> how is that the update-manager notifications works?
<nxvl> i mean the "restart $application" notifications
<ScottK> pitti: It's depwait in feisty and gutsy backports due to one needed bit (I'll look which) being in Universe
<pitti> ScottK: ah, libuuid-dev, I bet
<ScottK> Yes.
<nxvl> the on in charge to make this notification is $application or update-manager?
<ScottK> pitti: It'd have been much more convenient if Launchpad hadn't grown the 'feature' of caring about Main/Universe for backports.
<nxvl> s/on/one
<pitti> ScottK: oh, did it do that?
<ScottK> Yep.
<pitti> ScottK: I would have assumed it always did
<jdong> ScottK: *sigh* dammit
<jdong> pitti: it was turned off by infinity like 2 years ago...
<ScottK> pitti: Nope.  Otherwise backports from Main would be almost impossible.
<ScottK> pitti: I first discovered this when my latest Postfix backport got borked.
<mvo> nxvl: it uses https://wiki.ubuntu.com/InteractiveUpgradeHooks
 * nxvl HUGS mvo 
<ScottK> slangasek tortured postfix for dapper-backports into Universe somehow, but that's not really a scalable solution.
<lamont> slangasek not scalable.  film at 11
<pitti> ScottK: given that backports are already unsupported, I don't see much value in that check either
<ScottK> pitti: And if it's not reverted, then you'll need to do MIR processing for backports or some such.
<pitti> well, FSVO unsupported, you know what I mean
<ScottK> pitti: "Not commercially supported by Canonical" - Understand.
<ogra_cmpc> ScottK, thats beyond any commercial aspect, we never agreed on supporting upgrading of systems using backports as a developer team and nobody ever tests that
<ScottK> ogra_cmpc: True.
<Hobbsee> crackports, you mean.
<ogra_cmpc> i bet our genious  mvo could solve it if we'd clone him and he had the double amount of time per day to work on it though :)
 * pitti hugs mvo
<ScottK> The server stuff I backport all gets upgrade testing because it's running on my test server when I upgrade it.
<ScottK> Dunno about jdong's crack though.
<ogra_cmpc> well, the thing with dapper is for example that a backport could come from hardy ... if you'd upgrade dapper->edgy that package would simply be left out because of the higher upstream version
<mvo> we could add a automatic test for system with -backports, the problem is currently mostly lack of cpu/io/diskspace, but if somebody is interessted, all it requires is a cpu that supports kvm and some spare cycles
<ScottK> ogra_cmpc: That's true which is why I try to hit all the releases when I backport.
<ScottK> mvo: I haven't seen problems with this so far.  I wouldn't think it's a priority at this point.
<jdong> ScottK / ogra_cmpc: I do test my crack too
<jdong> :D
<afflux> pitti: could we have apport adding retraces stacktraces even if the bug was detected as duplicate? Use cases: bug 145360 is quite old. I reported it upstream yesterday and I wanted to attach a stacktrace with linenumbers matching to the newest upstream versions. The new duplicates (from the new versions) have no retraced stacktraces.
<ubotwo> Launchpad bug 145360 in compiz "compiz.real crashed with SIGSEGV" [Medium,Confirmed] https://launchpad.net/bugs/145360
<pitti> afflux: hmm; just recently I fixed a bug asking to *not* attach stack traces for dups, since they generate bugmail spam :)
<afflux> grrr :)
<afflux> I've another example, give me a second
<afflux> pitti: I may be wrong, but somehow whe thought bug 151200 had no complete stacktraces, but apport added some duplicates. We hoped to get more complete traces with them... ;)
<ubotwo> Launchpad bug 151200 in compiz "compiz.real crashed with SIGSEGV" [Medium,Confirmed] https://launchpad.net/bugs/151200
<afflux> (It may be that the trace is perfectly alright, it just looks... short :))
<ogra_cmpc> tjaalton, bryce, could it be that the via/openchrome driver and vt8623fb disagree bout video ram ? i had some reports that break with "memory size detection failed", which seems to come from the vt8623fb module
<tjaalton> ogra_cmpc: no idea..
<mvo> Riddell: if you have a moment, could you please have a look at bug #208390 ? I can not reproduce it and it looks a bit strange, but maybe you have a idea what goes wrong there
<ubotwo> Launchpad bug 208390 in update-manager "upgrading gutsy to hardy BUG" [Undecided,Incomplete] https://launchpad.net/bugs/208390
<Riddell> mvo: mm, any idea what language he was using?
<mvo> Riddell: unfortunately not, I wonder if the following might be enough: http://paste.ubuntu.com/6264
<Riddell> mvo: could be, I'll try and do some testing shotrly
<Riddell> mvo: bug 204818 is nasty, might it be caused by the lack of a proper terminal?
<ubotwo> Launchpad bug 204818 in update-manager "update manager crashed upgrading 'libc6' package." [Undecided,Incomplete] https://launchpad.net/bugs/204818
<mvo> Riddell: let me check
<mvo> Riddell: I will commit the utf8() change in translate_widget (if you don't mind) - it should do no harm and may cure it if the translation file is not in utf8() for some reason
<Riddell> mvo: yeah go ahead
<mvo> Riddell: yeah, 204818 is evil. I think its not terminal releated, but it might be that the lack of proper terminal triggers the bug.
<ArneGoetje> Riddell: For bug 209358 I have also no idea why qt3 gets it right and qt4 wrong...
<ubotwo> Launchpad bug 209358 in qt4-x11 "fonts in Qt4 look ugly because it uses Nimbus Sans L instead of Deja Vu Sans for Sans-Serif" [Undecided,Confirmed] https://launchpad.net/bugs/209358
<ArneGoetje> Riddell: regarding scim-bridge on kde4: which image are you using?
<Riddell> ArneGoetje: today's daily
<ArneGoetje> Riddell: will download
<sroecker> what's up with ubuntu.com, all the graphics look pixelish
<Nafallo> no?
<Pici> Looks fine here..
<sroecker> hmm
<Pici> I even put my face up to the monitor
<jdong> is someone playing with compiz zoom? :D
<sroecker> hehe, don't have compiz enabled
<sroecker> strange
<jdong> even on Hardy with Firefox 3's WONDERFUL and INTELLIGENT dpi and scaling detection abilities, ubuntu.com looks normal
<jdong> ;-)
 * ogra_cmpc can only agree on that looking at a scaled down ff3 on 800x480
<jdong> ogra_cmpc: aww you poor thing
<Amaranth> jdong: isn't the problem with that it now uses what X says the dpi is instead of a hardcoded value?
<jdong> Amaranth: I have no idea :)
<Ng> that's a good thing, surely?
<ogra_cmpc> jdong, i started to like it over time ...
<Amaranth> but if it's using pango it should match the rest of gnome with gnome's DPI setting
<Amaranth> unless they don't use that part of pango
<jdong> ogra_cmpc: yeah I had a low-res monitor for the longest time
<ogra_cmpc> jdong, on 7" thats just perfect and crisp ...
<jdong> ogra_cmpc: yeah, the eeepc is at that resolution and seems just fine to me
<ArneGoetje> Riddell: what's the rsync command to download the daily? iso.qa.stgraber.org is not reachable from here, so I cannot lookup the link... :(
<ogra_cmpc> jdong, right, on the classmate i'm using since some months as my main work environment as well
<Riddell> ArneGoetje: rsync -CvzapP --stats rsync://cdimage.ubuntu.com/cdimage/kubuntu-kde4/daily-live/current/hardy-desktop-i386.iso .
<ArneGoetje> Riddell: thanks :)
<sroecker> jdong, http://img523.imageshack.us/my.php?image=bildschirmfotorq3.png
<Amaranth> sroecker: you're zoomed in, i guess
<sroecker> Amaranth, doh, you are right :/
<jdong> yeah, I was surprised at first too when I realized FF3 actually zooms
<Amaranth> fullpage zoom that remembers your zoom level for certain pages can sometimes be annoying
<cjwatson> Keybuk: I recently changed openssh-server to adjust the OOM-killer priority for sshd, which you can do by poking numbers into /proc/PID/oom_adj. This works but is a bit fiddly. Do you think upstart jobs could have a neat way to do that?
<elmo> cjwatson: \o/
<Keybuk> cjwatson: probably, are the numbers meaningful?
<cjwatson> Keybuk: -17 => disable, -16 through +15 => various priorities
 * cjwatson blames the kernel :-/
<slangasek> seb128: AFAIK I don't have access to create the milestones
<calc> asac: have you heard of any issues with ipw3945 not coming back after a suspend/resume cycle?
<calc> asac: mine worked until sometime recently
<elmo> yeah, mine is fucked
<elmo> + too
<elmo> I'm pretty sure it worked when I first dist-upgraded too
<asac> elmo: only after susped/resume?
<elmo> asac: yes; if I reboot -> fine again
<calc> yea i have to reboot to fix it
<asac> does NM crash?
<calc> there isn't a daemon any longer, not sure if that is an issue
<asac> or do you see anything in syslog that suspicious?
<calc> asac: not sure, i do know nm-applet is still there, next time i will check nm the daemon as well
<seb128> slangasek: do you know who has?
<asac> calc: look in syslog please too
<calc> asac: actually i can go over to my desktop machine and cause it to happen on my laptop and tell you right now
<asac> calc: cool
<seb128> cjwatson, Keybuk, mdz: could one of you add a 8.04.1 milestone on launchpad?
<elmo> asac: nothing suspicious for me, FWIW
<calc> ok, now i'm on my desktop :)
<asac> elmo: when did it start breaking?
<elmo> asac: sorry, I'm not 100% sure, but I think no earlier than Friday
<calc> i think a few days ago, but i can't pinpoint it either
<asac> elmo: ok ... you probably track hardy for quite some time, right?
<mdz> seb128: slangasek should be the one to do that; he should have privileges now (and if not, let's fix that instead)
<calc> asac: i have tracked hardy for months also
<seb128> mdz: <slangasek> seb128: AFAIK I don't have access to create the milestones
<mdz> slangasek: have you tried?
<mdz> slangasek: you're in ubuntu-drivers, which should confer  that
<mdz> slangasek: https://edge.launchpad.net/ubuntu/hardy/+addmilestone
<slangasek> checking
<slangasek> ok, I do have access now
<calc> ok its not coming back, looking in logs
<asac> calc: maybe paste your syslog
<calc> ok i see it
<calc> well i think i do
<asac> ?
<calc> Error getting killswitch power: org.freedesktop.org.Hal.Device.KillSwitch.NotSupported - hal-ipw-killswitch-linux returned 255
<calc> i can copy them and then reboot so i don't have to type them verbatim ;)
<asac> ok
<calc> asac: only need syslog?
<asac> yes
<calc> ok
<asac> i didn't change anything killswitch related in recent uploads. so either that message is not related or something else broke it (hal, driver update)?
<calc> maybe so
<calc> brb
<slangasek> seb128, mdz: 8.04.1 milestone added
<seb128> slangasek: thanks!
<tkamppeter> pitti, hi
<calc> asac: http://pastebin.ubuntu.com/6266/
<asac> calc: that stops when resume is finished?
<Keybuk> cjwatson: would something like oom adjust disable or oom adjust -16..+15 be sufficient?
<asac> does nothing happen afterwards?
<cjwatson> Keybuk: sounds plausible to me
<calc> asac: wireless doesn't seem to ever come back until i reboot
<Keybuk> cjwatson: it'd get applied to all of the scripts as well as the main executable, that's ok I guess?
<Keybuk> what's oom_score ?
<asac> calc: lshal -u /org/freedesktop/Hal/devices/net_00_19_d2_8a_0c_19
<asac> (after and maybe before resume)
<cjwatson> Keybuk: oom_score is output from the OOM scoring algorithm, I think
<cjwatson> Keybuk: hmm, would really prefer just the main sshd executable if possible
<calc> asac: be back in a few, will have to reboot after suspend/resume cycle
<pitti> hi tkamppeter
<jwendell> asac, did you upload liferea-ubuntu4? I only see -3
<tkamppeter> pitti, I have opened a dialog ...
<pitti> tkamppeter: you need to register first
<calc> asac: http://pastebin.ubuntu.com/6267/
<asac> jwendell: yeah sorry. ubuntu3 is the latest
<jwendell> asac, ok, will try
<asac> calc: and there are no more messages from networkmanager after resume?
<calc> asac: no more
<calc> asac: i went back and looked at my syslog just a min ago
<calc> Mar 31 11:28:06 laptop-c2d NetworkManager: <debug> [1206980886.432324] nm_hal_device_added(): New device added (hal udi is '/org/freedesktop/Hal/devices/usb_device_4f2_b008_SN0001_if1').
<calc> Mar 31 11:28:08 laptop-c2d gnome-power-manager: (ccheney) Resuming computer
<calc> Mar 31 11:31:02 laptop-c2d init: tty4 main process (4628) killed by TERM signal
<calc> that was the way the log looked for the first test
<calc> at least in syslog
<asac> calc: ok.
<calc> its possible its a driver bug, i don't know when/if it got updated
<calc> BenC: ping
<asac> please try the latest branch which should add a bit more stability
<asac> sudo apt-get build-dep network-manager
<asac> bzr branch https://code.edge.launchpad.net/~ubuntu-core-dev/network-manager/ubuntu.0.6.x
<calc> ok
<asac> and just debuild
<calc> ok downloading now
<BenC> calc: ?
<asac> calc: the info.category should be just net.80211 ... not net.80211control
<asac> calc: you sure it works before suspent :)?
<calc> asac: yea
<calc> BenC: has any changes been made to the ipw3945 driver in the past couple weeks?
<asac> iwl3945 that is i guess
<calc> BenC: elmo and I are having trouble after resume it never comes back
<calc> yea maybe iwl3945 (the intel wireless 3945 driver)
<calc> btw the daemon is still in /etc/modprobe.d/ipw3945 file but doesn't seem to actually exist in /sbin
<asac> calc: whats loaded?
<calc> iwl3945
<calc> iwlwifi_mac80211
<asac> right
<BenC> calc: ipw3945 is the one you want to use, if at all possible
<asac> BenC: i think iwl is used by default in hardy though, isn't it?
<calc> BenC: hmm why does it automatically use the other one then? and is that a bug?
<BenC> because of a booger in our prep scripts
<BenC> ipw3945 should be default, so try blacklisting iwl3945 in the meantime
<calc> i don't see ipw3945 under /lib/modules/2.4.24-12-generic is it somewhere else?
<calc> also the daemon it tries to load isn't in /sbin
<asac> BenC: will you switch to ipw3945 by default even though we don't have any feedback on that for quite some time?
<calc> find /lib/modules/2.6.24-12-generic -iname "*3945*"
<calc> /lib/modules/2.6.24-12-generic/ubuntu/wireless/iwlwifi/iwlwifi/compatible/iwl3945.ko
<BenC> asac: Yes, since it's roughly the same as in gutsy anyway
<calc> the /etc/modprobe.d/ipw3945 file is there but the driver and daemon look missing (at least to me)
<asac> BenC: well ... could you please try to think about network manager when doing such kind of things in future? would be really helpful
<BenC> hmm
<BenC> asac: not sure what you mean
<calc> ah i see there is -13 kernel now
<BenC> calc: it's not in the kernel..it's in lum...or should be
<calc> BenC: ah
<asac> BenC: well ... whenever you change modules and things like that i need to make sure that network manager works with that.
<BenC> asac: hasn't network manager always worked with ipw3945?
<BenC> asac: and can't it work with them at the same time, regardless of switching back and forth?
<BenC> it does query the driver name before acting on things, right?
<asac> no ... we had issues in gutsy that required tweaks
<calc> BenC: its not there but the microcode is
<BenC> were the tweaks dropped?
<asac> BenC: we have 0.6.6 now so things might be different.
<calc> i did a dpkg -L and there is no ipw3945.ko
<BenC> calc: talking to rtg now
<calc> BenC: ok
<calc> if its in the package and not on my machine somewhere weird happened
<asac> i don't say that it will not work, but i'd rather want the most important drivers in the archive well ahead of release
<calc> er something :-)
<mjg59`> BenC: http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-hardy-lum.git;a=commitdiff;h=ceca971c63ec135e0f01453ff3d527be493d915b
<BenC> mjg59`: thanks
<BenC> we should remove all traces of it then
<BenC> there's still microcode and modprobe.d files laying around
<mjg59`> BenC: The modprobe.d file is a conffile. I'm not sure there's a huge benefit in removing it.
<calc> so if we aren't actually supposed to be using ipw3945 then the iwl3945 should work, i assume ;)
<BenC> calc: right, it should
<BenC> mjg59`: only harm I can think of is conflicts with manual installs
<calc> ok well i'll try the new nm and see if it helps any
<BenC> calc: alternative is to use the upcoming lbm, which has a newer (non-branded) 1.2.25 iwlwifi
<compbrain> Anyone know if you can run the installer without the curses frontend?
<cjwatson> compbrain: and with what in its place?
<compbrain> Some scrolly text, from vc3 or 4. I'm capturing install logs over serial, lots of pretty ncurses scroll in the logs right now
<TomaszD> pitti, what happened with langpacks twice a week? It's been two weeks... :( the date of last langpack is 20080317 :(
<TomaszD> carlos, care to shed any light on this?
<carlos> TomaszD: I don't control it. However I know pitti did an upload today
<carlos> TomaszD: with the 'I don't control it' I mean that I'm not helpful on that...
<TomaszD> carlos, ok thanks :] do you know why the langpack uploads don't appear on the hardy-changes list? Is there a list to track this?
<carlos> TomaszD: no idea, I don't know the details about the packages when it moves to .deb ones...
<TomaszD> ok
<pochu> seeds' recommended packages are installed by default, right?
<calc> BenC: when will that be uploaded?
<BenC> calc: before RC
<calc> BenC: ok
<cjwatson> compbrain: there's the teletype frontend
<cjwatson> compbrain: boot with DEBIAN_FRONTEND=text
<cjwatson> compbrain: the installation guide recommends that for serial installs
<compbrain> ah, glorious. Thanks :)
<carlos> TomaszD: I think I found an explanation, Martin did a full language pack update, that takes more time to prepare and test, so I guess that's the reason we didn't get so often updates last week
<TomaszD> carlos, ok, fair enough then :]
<collusion> Hi, I'm DebuggingKernelSuspend on an IBM X40 and I got a hash match from /sys/power/pm_trace for ptyq9.  What's the next step I should take?
<mjg59`> collusion: Try linux-image-2.6.24-13-generic
<collusion> mjg59: is that out? i didn't see any kernel upgrades when i just apt-get update/upgraded.
<mjg59> collusion: Yes, but there's no lum or lrm yet
<collusion> mjg59: er, sorry, what's lum/lrm?
<mjg59> linux-ubuntu-modules and linux-restricted-modules
<slangasek> ummmm, so we're switching back from iwl3945 to ipw3945 two weeks before RC, after spending the entire release cycle using iwl3945?
<mjg59> slangasek: I don't think that was the conclusion
<collusion> oic, the package exists and can be explicitly installed... so i should manually install that and see if it fixes suspend? alright, giving it a try.
<slangasek> mjg59: what is the conclusion then?
<calc> ok got it built will test it out now
<mjg59> slangasek: Uhm. I /think/ that nothing would change.
<mjg59> Maybe I'm misreading this.
<slangasek> ok, I like that conclusion better :)
<collusion> mjg59: the 2.6.24-13-generic kernel does suspend properly.  but i'll need lum to get my wireless working unfortunately.  when is that scheduled to be released?
<calc> asac: the new version didn't fix the problem
<calc> asac: i can show syslog output if that is useful
<asac> calc: unfortunate. only thing you could try for me is to see if downgrading NM helps
<asac> otherwise its not a regression by nm i guess
<calc> asac: http://pastebin.ubuntu.com/6273/
<calc> asac: ok
<calc> asac: i'll downgrade to 0.6.6-0ubuntu1 and see if it works there and then upgrade
<calc> asac: how do i get old debs out of launchpad, i forgot
<calc> asac: i know how to get old source but that wouldn't be binary identical
<\sh> Hobbsee: hmm...who removed the ban from u-m for kmos?
<slangasek> interesting to find my name in an upstream changelog that I'm reviewing for an FFe when it's an upstream I've never had any direct interaction with
<asac> calc: you go to the release and find the resulting binary on the left
<asac> calc: https://edge.launchpad.net/ubuntu/+source/network-manager/0.6.6-0ubuntu1/+build/534632
<asac> thats for i386
<\sh> slangasek: which one?
<slangasek> \sh: nfs-utils
<slangasek> (it's entirely valid, but still surprising)
<\sh> slangasek: you mean the sign off message? :)
<slangasek> yes
<calc> asac: ok
<\sh> slangasek: well, it's always surprising when you find your name inside upstream changelog...
<jdstrand> hi slangasek! can you look at bug #209845 ? What is your opinion-- bug fix or feature (I thought fix)?
<\sh> but now I wonder why my hardy-amd64-source chroot disappeared suddenly from schroot.conf
<\sh> more strange, I build something this afternoon with it...and now it's just gone
 * jdstrand finds it to be a fine line sometimes
<slangasek> jdstrand: definitely a feature, but probably one that would be accepted if the diff was reasonable
<\sh> well, not exactly the chroot but the LVM device for it
<mjg59> collusion: Should be shortly
<jdstrand> slangasek: ok.  the diff to program is reasonable, the diff to the test suite is large (to verify correctness)
<\sh> cjwatson: thx for the gpt patch :)
<cjwatson> \sh: no problem; does it work for you?
<collusion> mjg59: ok, i'm eagerly awaiting.  thanks for the help.
<jdstrand> slangasek: I'll prepare the upload and you (or whoever) can ping me if there are questions
<\sh> cjwatson: tomorrow I'll test it with a areca raid storage server...
<\sh> cjwatson: the schedule was very good :)
<slangasek> jdstrand: ok. I agree that the program diff should be reasonable in size, but I'd prefer to see it anyway before upload, to assure myself that the implementation doesn't paint us into a corner somehow :)
<cjwatson> \sh: heh
<slangasek> mvo_: that's a whole lot of foo in that python-support changelog ;)
<\sh> grmpf...what can cause the disappearance of a logical volume? even if it's displayed by lvdisplay?
<slangasek> volume gnomes
<\sh> hmm...
<\sh> no it can't be gnomes fault ;)
<\sh> -ESTRANGE...it isn't even listed in /dev/bs01/* which is my lvm device here
<\sh> http://paste.ubuntu.com/6276/ this is the output if lvscan and ls -la /dev/bs01/* and now tell me what's wrong here
<\sh> looks like I should test the windows way now...reboot is goot..
<jdstrand> slangasek: I did not mean to suggest accepting the upload on my word :)
<jdstrand> slangasek: http://bazaar.launchpad.net/~jamie-strandboge/ufw/trunk/revision/138
<ArneGoetje> Riddell: scim support on the current Kubuntu-KDE4 image is incomplete.
<\sh> looks like that it has something to do with the non forced fsck
<ArneGoetje> Riddell: the following packages and their dependencies need to be installed for scim to work: scim, scim-bridge-agent, scim-bridge-client-qt, scim-bridge-client-qt4, im-switch
 * \sh reboots
<jdstrand> slangasek: the non-test file in question is src/ufw
<calc> asac: it worked on the 20080318.1 cd so i am going to download some others and verify it doesn't work when booted off them versus using my system
<asac> calc: ok
<jdstrand> slangasek: I should also mention that a) this is against trunk, and I am going to cherrypick this patch for hardy, b) I plan to also cherrypick r135 and r136 for bugs #209709 and #207156
<jdstrand> (no code changes-- just adjusting logging for INVALID packets and noisy services
<jdstrand> )
<calc> too bad cdimage doesn't have enough space to hold daily's back to the previous release (in this case beta)
<calc> there are only dailys for yesterday and today
<asac> calc: there are not many updates that might have caused this
<calc> asac: ah ok
<asac> try hal
<calc> asac: once i verify that the new daily doesn't work i will generate a package version diff and try hal first
<asac> sounds good
<calc> will be about an hour before its done downloading
<sroecker> does hardy has this new /dev/mem protection?
<calc> asac: https://bugs.launchpad.net/ubuntu/+source/udev/+bug/208103
<calc> asac: i think this is my problem (maybe?)
<calc> ubuntuforums probably solves my problem :)
<calc> now i just should try moving that file and see what happens
<jdong> sroecker: yes
<sjoerd> thee
<sjoerd> woops wrong window
<calc> asac: yep that fixed it
<calc> asac: its a problem with that file
<asac> calc: good. can you take care that this gets fixed somehow?
<slangasek> jdstrand: would it be possible for you to open a bug report for an FFe about this, including the full package diff (== upstream diff, for a native package..) of what you plan to upload?
<calc> asac: i'm swamped with OOo stuff right now, but if it doesn't get fixed in the next few days I'll try to look into getting it done
<jdstrand> slangasek: sure, no problem
<calc> asac: i'm not sure what the proper solution should be, unless we just rm a conffile(?)
<slangasek> calc: 70-persistent-net.rules isn't a conffile
<slangasek> I think ideally we would have udev edit that file on upgrade if the attributes are missing
<slangasek> but I'm not sure if adding these two new fields is *always* the right thing
<slangasek> Keybuk: ^^ ?
<Keybuk> it's not always the right thing
<Keybuk> that's the problem
<slangasek> is it possible to detect when it's the right thing?
<Keybuk> not once you've booted with the broken file
<Keybuk> it's possible to migrate people when they are running gutsy
<Keybuk> fix the file
<Keybuk> so that when they boot into hardy, it works
<Keybuk> I have that working for upload this week
<Keybuk> once you've rebooted with the broken file, it's damned hard to sort out
<slangasek> hmm, ok
<slangasek> but at least in theory it's fixable for people who have not yet upgraded to hardy
<Keybuk> yes
 * slangasek nods and leaves it in your hands :)
<mvo_> slangasek: yeah, I guess I should have explained it on the sepolgen and python-sepolgen example :)
<Keybuk> it's maybe fixable for others too
<Keybuk> I'm working on it
 * \sh has the bugger...superblock was corrupted on the ext3 partitions of his lvm schroot devices......after all, removed all schroot lvms, updated mk-sbuild-lv to format with xfs, recreated all schroots ... ready for work
<calc> just deleting the file (i guess if the user doesn't modify it) fixes the problem also
<calc> or does that not work in some cases?
<slangasek> ... so your answer for an ext3 superblock corruption is to switch to a filesystem that likes to eat individual files instead?
<slangasek> calc: it means that on next reboot, the devices are not guaranteed to come up with the same name mapping
<Keybuk> calc: that will randomly rename your network interfaces
<Keybuk> many might consider this pessimal behaviour
<slangasek> (also, this file might have been customized by the user in the corner case)
<calc> slangasek: ah yea
<calc> Keybuk: yea that would be very bad for servers, probably not a big deal for desktop users
<mvo_> Keybuk: do you have a opinion on bug #209347 ? I was wondering if the conversion should be moved back to udevs postinst or if it should just run on new installs of volumeid too (might confuse the installer?)
<Keybuk> calc: unfortunately we also install udev on servers :)
<calc> Keybuk: yea :)
<Keybuk> mvo_: err, the conversion has never been in udev's postinst?
<Keybuk> (it can't go there for various reasons)
<calc> elmo: see scrollback to fix your wireless issue
<mvo_> Keybuk: hm, there goes my nice theory about the bug. I will look closer
<Keybuk> didn't we add it in edgy?
<Keybuk> I can't remember
<mvo_> Keybuk: yeah, its available since edgy (according to packages.ubuntu.com)
<Seveas> Keybuk, hmm, that may be why ubotu is down -- didn't come up after dapper->harder upgrade :)
<Hydrant> calc: Hey, I found a bug in OO for Ubuntu you might want
<calc> Hydrant: what is that?
<Keybuk> mvo_: I'm trying to remember how this may have worked
<crimsun> Keybuk: what about checking the return value of, say, `ps -C nm-applet >/dev/null' and acting accordingly?
<Keybuk> crimsun: removing that file is *always* wrong
<Hydrant>  /usr/lib/openoffice/sdk/linux/bin/regcomp is a posix script file
<crimsun> (obviously that's not a comprehensive solution)
<Hydrant> ... regcomp isn't working on a .so file in my cwd unless I add "." to LD_LIBRARY_PATH in that script
<Keybuk> mvo_: ah
<Keybuk>  * Ship the UUID migration script as a separate executable, called by
<Keybuk>     volumeid's postinst; also ensure we don't call it when installing the
<Keybuk>     base system on the LiveCD (oops!)
<calc> Hydrant: ah yea i have a bug open about that i think
<Hydrant> calc: otherwise I'd have to copy the .so file to $OO/program
<mvo_> Keybuk: aha! so it is probably safe to remove the [ -n "$2 ] bit from it, because the livecd diverts it?
<calc> Hydrant: oh nm that isn't the same bug, please report it
<Keybuk> mvo_: does it?
<Hydrant> calc: where do I file a report ?
<Keybuk> mvo_: the [ -n ] is there to protect the Live CD creation process
<calc> Hydrant: launchpad.net/ubuntu/+source/openoffice.org/
<crimsun> Keybuk: I don't remove it locally.  One option I'm considering is checking for loaded modules that are in a whitelist and removing the lines from that file.
<Hydrant> calc: thx... how is your OO'ing going
<Keybuk> crimsun: removing the lines is always wrong
<Keybuk> the only correct solution is to add ATTR{type}=="1" for the individual entries that need it
<mario_limonciell> Keybuk, ping (once you are done with the above conv).  wanted to follow up on the thinkfinger stuff.  It looks like everything is in main now, so just that last piece for enabling it in pam is necessary, right?
<mvo_> Keybuk: hm, currently on dapper->hardy the -n test will fail because there is no volumeid in dapper yet
<Keybuk> mario_limonciell: right
<Keybuk> mvo_: indeed
<mario_limonciell> Keybuk, which package's postinst was going to enable it?
<calc> Hydrant: just waiting on some changes from doko then i will be uploading a first pass of 2.4.0 final
<crimsun> Keybuk: when I get back, I'll show you an entry that will fail, since the entry that is created is bunk.  i.e., it's the MAC of the wifi iface prepended to a broadcast address.
<Keybuk> mario_limonciell: no postinst will do it
<calc> Hydrant: may have another upload before RC next week though
<Keybuk> I still think that's wrong
<mario_limonciell> Keybuk, oh.
<Keybuk> it'll break upgrades, etc.
<Keybuk> crimsun: ?
<slangasek> Keybuk: trying to understand your comment above - is the plan to enable thinkfinger by default only on new installs or somethinG?
<crimsun> Keybuk: on a dist-upgrade from gutsy, the generated entry for b43 (vice bcm43xx) had the MAC prepended to the broadcast address.
<Keybuk> crimsun: that I don't know about
<Keybuk> slangasek: we shouldn't ever enable thinkfinger by default
<Keybuk> it has too many issues
<slangasek> ok
<slangasek> just making sure I understood
<Keybuk> crimsun: if new lines are being generated wrong, that's a different bug
<slangasek> whereas I am pondering enabling smbpasswd by default yet, and may need to rely on other people to check my sanity in this regard...
<crimsun> Keybuk: understood.
<Hydrant> calc: I've completely messed up my OO install with my development... I tried dpkg -l openoffice | grep openoffice and doing an apt-get remove for each followed by dpkg --purge, but my install is still messed up
<Hydrant> calc: any suggestions for purging everything?
<theunixgeek> How do I get my app to appear in the desktop menu after installation? Is there a shell script?
<calc> Hydrant: | dpkg -l | grep (oo full version number) | cut -f 3 -d " " | xargs dpkg --purge --force-depends
<calc> er get rid of that first |
<calc> Hydrant: if that doesn't work you really screwed up something, since that will uninstall all of openoffice
<calc> Hydrant: removing ~/.openoffice.org2 may help in some cases
<seb128> slangasek: what timezone do you use to get bug #208598? The bug is not here using a french one for example
<Hydrant> calc: thanks...yeah I got rid of ~/.openoffice..
<Hydrant> calc: thx
<Hydrant> calc: I don't see a meta package for OO, is there a quick way to put it back on
<slangasek> seb128: America/Los_Angeles.
<calc> Hydrant: openoffice.org
<calc> Hydrant: that is the meta-package
<seb128> mdke: around?
<mdke> seb128: (In case I'm not around at the moment, please provide a bit of information about what you want and I will respond when I get back)
<mdke> seb128: yeah
<seb128> mdke: is smb file sharing described in the ubuntu documentation?
<seb128> mdke: we just switched to nautilus-share which is a bit of sucking situation
<seb128> shares-admin was requiring command line use and not allowing to use anonymous shares
<seb128> so the change should be useful but it's late
<Hydrant> calc: thx
<mdke> seb128: looking
<mdke> damn, Ctrl Z sucks
<Nafallo> does it?
<mdke> seb128: yes, it is documented in the "Internet" section - file:///usr/share/gnome/help/internet/C/internet.xml#networking-shares
<seb128> mdke: hum, I don't like late changes
<mdke> seb128: what would change from the user's POC?
<seb128> mdke: no tools to do the shares, only right click on a folder from nautilus
<seb128> mdke: so the first list of steps would need to be changed to that
<seb128> mdke: the new dialog installs smb too if not installed and allow anonymous sharing
<seb128> mdke: the part about setting the smb passwd is still true and the debugging one too
<mdke> seb128: so basically the first section would be simplified?
<seb128> mdke: yes
<seb128> mdke: do you use hardy?
<mdke> seb128: yes
<seb128> mdke: it's, basically right clik on a folder in nautilus, select Sharing Options
<jdstrand> slangasek: bug #209897
<jdstrand> where's ubotu today?
<seb128> mdke: and then you can describe the read only, anonymous and comment fields if you want
<jdstrand> slangasek: that's the FFe for ufw
<Nafallo> bug 209897
<mdke> seb128: I'll upgrade now
<Nafallo> hmm
<seb128> mdke: thanks!
<mdke> seb128: it sounds like it will be easy to change the documentation. But I'm more concerned about the translations of the documentation - quite a few languages are pretty advanced on translating that document. If the advantages of the change are pretty big, then we should try and go for it, I think - and warn the translators
<seb128> mdke: I'll warn them
<seb128> mdke: we will update the translations after stable and ship 8.04.1 cds, etc with updated packages when it'll be available
<seb128> mdke: well, the new tool allow anonymous sharing which was not possible before which is a good thing ;-)
<mdke> seb128: well, ubuntu-docs translations are done manually, although we will try to do that if the timeline for the point release is documented
<mdke> seb128: can shares-admin and the new tool exist together? Or are they basically different?
<seb128> mdke: they can exist together, though we removed shares-admin for now
<seb128> I'm considering adding it back it a limited form though
<seb128> ie, removing the nautilus integration and masking the menu item
<mdke> that sounds pretty uncomfortable
<seb128> what do you mean?
<mdke> well, more work for you :)
<mdke> anyway, that solution would answer require amendment to the docs
<mdke> I'll see what I can do to amend it tonight, although if it will take a long time or access to a windows network, I will struggle...
<mdke> seb128: I don't have a "Sharing Options" in my nautilus, although i just upgraded. What do I need?
<slangasek> seb128: why would you add shares-admin back?
<seb128> mdke: nautilus-share
<seb128> slangasek: people complaining loud about late change, no way to modify their shares and nfs, no transition plan, etc ... though I think they are vocal minority as usual
<slangasek> "shares and nfs"?
<seb128> slangasek: I'm wondering if having only the capplet available and not listed in the menus would be a compromise to make them happy
<mdke> never underestimate the vocal minority :)
<mdke> seb128: thanks
<slangasek> shares-admin did NFS management?
<mdke> that looks neat
<seb128> slangasek: yes
<TameLion> Laney: Now all I need is a bot which responds to !cheek-seeker
<slangasek> hmm, ok
<TameLion> Hello all..
<seb128> slangasek: but we don't think that's something desktop user are using
<TameLion> I just really really need to say a huge THANK YOU! Hardy beta is the easiest install ever!
<mdke> seb128: isn't it something that we should encourage desktop users to use over smb though?
<slangasek> seb128: I for one wasn't even aware of it
<seb128> slangasek: and I'm not really sure it was working, so far nobody complained about that, it seems they are just trying to argue
<seb128> mdke: nfs? I don't think so
<seb128> I think we should install gnome-user-share next cycle
<slangasek> mdke: no, because user-based NFS auth is not straightforward to configure yet
<seb128> it does webdav sharing using apache
<slangasek> (prerequisites include Kerberos, and... 5 years experience administering Kerberos)
<slangasek> seb128: and drop the samba sharing altogether, or..?
<seb128> slangasek: no, samba sharing is the only thing which integrates to windows networks
<mdke> slangasek: fair enough
<seb128> webdav advertised over avahi is neat between linux boxes
<seb128> but win doesn't list those
<slangasek> gar why is ucf hanging on my Debian unstable dist-upgrade, that makes it harder for me to test the bzr 1.3 packages :P
<Hydrant> calc: I think I really messed up my install
<calc> Hydrant: what did you do to mess it up?
<asac> slangasek: nm 0.6.6-0ubuntu5 upload ... all hidden network issues known so far fixed \o/
<Hydrant> calc: I'm really not sure
<calc> Hydrant: what are the symptoms?
<Hydrant> calc: I've been working on my own modules for OO...
<Hydrant> calc: The icons are all missing, OO looks like win95
<Hydrant> calc: Also when I type "=" into OO Calc it crashes
<calc> wow = crashes OO sounds bad
<asac> lets hope that the next driver round doesn't break all these :)
<calc> the icon issue may be related to the fallback not working, if you aren't using human theme
<calc> but the = crashes oocalc isn't
<Hydrant> calc: yeah, the = thing is likely me
<mathiaz> slangasek: I'm trying to figure out how to add the default feisty smb.conf to allow for a smooth upgrade to hardy - I was wondering why do you use 3.0.26a-1 in the postinst script ?
<Hydrant> calc: I'll have to so some slocating and hope to find something remaining
<slangasek> mathiaz: version number from gutsy; split upgrade handling between gutsy and dapper
<slangasek> mathiaz: so to handle the possibility of one of a number of different configs having been the initial version, we'd want to loop through a copy of the default configs for each release, debconfize them, and check which one is "closest"
<mdke> seb128: neat tool. I've written the instructions and will upload a new pot template now to Rosetta, and post to -translators
<seb128> mdke: thanks!
<mdke> seb128: if you fancy checking the instructions, see http://mdke.org/tmp/smb.png
<Daviey> mdke: gah, i tried to use the scrollbar in the pic..
<seb128> mdke: looks good!
<mdke> Daviey: ;)
<tjaalton> slangasek: nfs-utils> you mentioned about some breakage in the build-deps?
<mdke> seb128: cool. presumably nautilus-share will be installed by default, right?
<seb128> mdke: yes, it is already if you try a daily CD
<mdke> seb128: fine, guess that hasn't filtered through to my install yet
<seb128> mdke: how do you update?
<seb128> mdke: it's only a recommends and apt doesn't install those by default in ubuntu
<mdke> seb128: update-manager
<mdke> seb128: if not all users will have the package, we may have to add another line to document that! But shouldn't it be a dependency of ubuntu-desktop?
<seb128> mdke: ubuntu-desktop recommends are installed by default and it let the choice to the user to uninstall
<slangasek> tjaalton: yes, the change I cited was not a change that should've been made to nfs-utils, this was actually a bug in libnfsidmap-dev
<mdke> seb128: hmm. Strange I didn't get it then
<slangasek> tjaalton: it's a minor blemish, but since you weren't aware that it was an error, I wanted to make sure that you've tested this package in other respects :)
<seb128> mdke: I don't think update-manager install those
<seb128> mdke: new install and people using the dist-upgrader will have it though
<tjaalton> slangasek: ah, yes. I've been running it on a couple of clients for a few days. Note that many of the upstream commits were already in the old package
<mdke> seb128: ok, that may be enough. We don't really have a policy on whether our docs should take into account those who have tracked the development version
<slangasek> tjaalton: yep, I see that
<tjaalton> slangasek: -2 is mostly cleanup, but why not merge with it while fixing the build-deps?-)
<seb128> mdke: well, those know what they are doing usually and should read the upgrade notes if they don't
<seb128> mdke: but right, that's worth discussing at some point, nautilus-share is not the only package concerned by such situations
<tjaalton> slangasek: so our libnfsidmap is safe since it's rebuilt against the new libldap2-dev?
<mdke> seb128: agreed.
<slangasek> tjaalton: our libnfsidmap is also broken; it's supposed to have a dependency on libldap2-dev and doesn't
<slangasek> tjaalton: so even though I've highlighted that change as an error, it can't be dropped from nfs-utils without also making changes to libnfsidmap :/
<tjaalton> slangasek: ah right, libnfsidmap-dev doesn't depend on libldap2-dev, gotcha
<tjaalton> heh, there's already a bug filed about that on b.d.o
 * lamont wonders if the gnome-equiv of jpilot has ever learned that more than one category exists in phone lists
<slangasek> tjaalton: I think so; but perhaps not, since it was one of the nfs-utils comaintainers who brought it to my attention
<slangasek> lamont: what's the gnome equiv of jpilot? :/
<lamont> slangasek: ISTR evo was pretending to be that back then
<tjaalton> slangasek: sesse is also a comaintainer of libnfsidmap, and filed the bug :)
<lamont> but only believed in one category of phone contacts, so happy merge-o-rama
<lamont> slangasek: more to the point, where did /usr/bin/dund move, I wonder?
<slangasek> tjaalton: right, that would be the one :)
<slangasek> lamont: I don't know what that is, so couldn't say
<lamont> it's the implementation of MS DUN (ppp over bluetooth)
<lamont> and was in bluez-utils in gutsy
<lamont> and isn't in Contents-i386.gz for hardy...
<lamont> loss
<lamont> it's how one does bluetooth palm-sync with jpilot, you see....  no BT sync,  so we just do network sync over bluetooth networking.  win.
<lamont> so... WTF dropped the --enable-dund from bluez-utils debian/rules invocation of configure, I wonder...
<lamont> ah.  iz new config options
 * lamont files a bug
<kirkland> lamont: see Bug #191704
<slangasek> lamont: ah, ick
<kirkland> lamont: I think that bug is related to your discussion with slangasek
<lamont> that'd be the same family
<lamont> hrm... so who do we slap around for getting BT network back, I wonder?
<lamont> I mean, I could just do the upload, I suppose... but someone would probably squawk
<slangasek> lamont: looks like a plain regression halfway through the release cycle with no rationale, consider yourself freeze-blessed if that's the concern
<lamont> slangasek: woot!
 * lamont will compare the gutsy binary list until it's "right" then. "-)
<slangasek> lamont: oh, but before you do, maybe this says the binary is no longer needed?: https://bugs.launchpad.net/ubuntu/+source/bluez-utils/+bug/191704/comments/16
<lamont> well, for things that it supports...
<slangasek> right; so is dund the only bit really still missing?
<lamont> show me network over BT :-(
<lamont> and that was more someone saying "my keyboard/mouse work now", not that they were involved in dropping it...
<lamont> there might be other stuff that still needs hidd... not sure
<lamont> dund, hidd, pand, and passkey-agent are the dropped binaries...
<slangasek> well, my understanding is that the standalone daemons are supposed to be replaced by these "service" records that DTRT
<lamont> not sure why, though...
<slangasek> so we now have bluetoothd-service-{input,network,serial}
<slangasek> but I'm not sure that any of those map correctly to dund
<slangasek> (whereas -input == hidd, and -network == pand)
<lamont> well, I just know I broke my desktop when I upgraded to hardy...
<lamont> so it sure as hell wasn't transparent...
<slangasek> wrt which service?
<lamont> (the DTRT that is)
<lamont> syncing my palm
<slangasek> so dund
<lamont> right
<slangasek> which is the one I'm not sure how it's mapped to the new services
<lamont> so you want I should just enable that one?
<slangasek> that seems the least disruptive change, anwyay
<lamont> or should I wait until morning and have a flamefest^Wdebugging session with someone european?
<slangasek> well, I'm less sure now that the dropping was unintentional... it may be that these daemons are no longer even provided upstream...?
<lamont> hrm... stevenk and Mithrandir
<lamont> dund is in the source still
<slangasek> ok
<lamont>   --enable-hidd           install HID daemon
<lamont>   --enable-pand           install PAN daemon
<lamont>   --enable-dund           install DUN daemon
<lamont> from configure
<slangasek> StevenK: you're not European
<lamont> those names were from the blamelog^wchangelog
<slangasek> yes
<kirkland> lamont: slangasek: i know that the helper scripts that I use in gutsy to do dial up networking and syncing my palm, broke when I upgraded to hardy due to a missing dund (see comment #19 in that bug).  there was something about "dbus" providing that functionality now, but i have yet to figure out how
<lamont> kirkland: right - it's either broken by not being there, or broken by not being transparent
<lamont> since delivering /usr/bin/dund should make it just work again
<xivulon> slangasek, would you agree with the proposal in my last comment of #140458 to provide wubi-specific metalink url?
<kirkland> lamont: i'll gladly test, if you build a package with dund
<lamont> kirkland: yeah - it's on my list for tonight, I think
<kirkland> lamont: usb syncing sucks ;-)
<lamont> esp if StevenK shows up...
<lamont> kirkland: and big time
<lamont> anyway, afk for a bit
<slangase`> lamont, kirkland: you have the bluetooth-gnome stuff installed?  Icon in the panel?
<kirkland> slangasek: yes
<slangasek> kirkland: right-click, preferences, services: enable the serial service (or network service, according to your needs)?
<kirkland> slangasek: I tried those, it didn't work for me
<slangasek> is your device listed under 'bonded devices' in the adapter paneL?
<slangasek> s/panel/tab/
<kirkland> slangasek: yep
<kirkland> slangasek: is there more you wanted me to try?
<slangasek> kirkland: not that I know of at this point :)
<kirkland> slangasek: ah, okay...  i was on the edge of my seat :-)
<elmo> calc: err, summarize, pls?
<calc> elmo: /etc/udev/rules.d/70-persistent-net.rules is broken, remove or move it and it is likely to work
<elmo> calc: right, sorry, just managed to fish that out of scroll back
<calc> elmo: keybuk has more details about the problem, but apparently its hard or maybe impossible to fix for people who tracked hardy without removing the file or manually modifying it
<elmo> calc: (and keybuk/slangasek) thanks
<calc> elmo: no problem :)
<slangasek> kirkland: heh, well, /usr/share/doc/bluez-utils/README.Debian.gz still talks about pand and dund, so I'm at a loss
<slangasek> I think this may be in the category of "things the bluez developers know and google does not" :)
<kirkland> slangasek: yup.  i've scoured the documentation looking for the newfangled way of doing what I had become accustomed to with dund.  and i'd gladly write a wiki page if i figured it out.
#ubuntu-devel 2008-04-01
<kirkland> slangasek: which is why i glimmered to life when I saw you and lamont discussing the possibility that dund might be coming back!  :-P
<slangasek> aoh, here's some info though: http://lists.maemo.org/pipermail//maemo-users/2007-December/007933.html
<slangasek> not *encouraging* info, it basically says "use dbus-send", but...
<kirkland> slangasek: nice, "successively calling dbus-send...and parsing its output"
<kirkland> slangasek: hrm, perhaps someone should write a "daemon" to do that?  oh wait!  :-)
<slangasek> kirkland: well, the python dbus bindings are certainly a saner choice than dbus-send... :)
<kirkland> slangasek: about like writing a webserver in awk, though isn't it?  :-P
<slangasek> hrm?
<slangasek> surely you're not comparing python to awk? :)
<kirkland> slangasek: never.  i was comparing the dbus-send hack to writing a webserver in awk.  it can be done, but......
<slangasek> ah, yes
<kirkland> slangasek: awk is more like a tire iron.   there bigger, better, faster, prettier, tools in the shed, but in the right situation, it'll get you out of a jam.
<slangasek> kirkland: "awk is more like a tire iron.  If you find yourself faced with someone wielding it, back away slowly."
<kirkland> slangasek: i'd agree with that one too ;-)
<kirkland> slangasek: i suppose you could "hit them with a pipe" and "grep it away from them" ?
<slangasek> haha
<kirkland> nerd humor gone too far
<slangasek> no, nerd humor gone too far would be "sed plerumque sequitur ocassio calvata"
<slangasek> or "occasio calvata", if I could spell today
<verb3k> Are there plans to upgrade Transmission to the latest release? it fixes many problems
<verb3k> http://www.transmissionbt.com/
<alex-weej> asac: still up?
<verb3k> It has smaller memory footprint
<pochu> verb3k: don't think so, too late and it adds new features
<pochu> jdong: ^
<jdong> see bug 208836
<verb3k> pochu, but it also fixes many many problems, we will need this during the 3 year timespan
<verb3k> + lower footprint
<jdong> please read the bug report
<verb3k> ok
<jdong> so far I am planning , with Charles, to isolate the bugfix patches to 1.06
<jdong> we will hold off on the new features of 1.10 for now
<lamont>  Warning: Color name "'#400040'" is not defined
<lamont> stupid uxterm
<verb3k> I see
<jdong> transmissions's also one of those things that I backport within a week of a new release, so that's where Hardy users can go for newer versions
<jdong> but at this stage IMO it's too big of a risk to upgrade the default torrent client to a UI-changed version.
<verb3k> jdong, I see, I think I agree now :)
<jdong> verb3k: alright, cool :)
<verb3k> jdong, as long as there will be backports I am cool :)
<jdong> verb3k: I promise there will be backports :)
<verb3k> thanks for your time jdong  :)
<jdong> of course
<ScottK> Oh sure.  He applies and then runs off.
 * mneptok does the Deluge dance
<RAOF> mneptok: Is that the one where the UI blocks all the time, and the blocklist plugin crashes it? :P
<mneptok> RAOF: not in my experience.
<RAOF> I could be using the wrong plugins, of course.
<mneptok> generally you'd want to use Deluge plugins with Deluge. *shrug*
<mneptok> >:)
<emgent> heya people
<RAOF> Right, yes :P
<nabcore> Can I use apt to upgrade my current gutsy 7.10 to the hardy 8.04 beta?
<nabcore> it's an old test laptop; I've got the desktop 8.04 beta, but it cannot use that since it's not powerful enough and I don't have resources to burn another CD
<ion_> Use do-release-upgrade, and now please read the topic.
<theunixgeek>  How can I call various arguments for a callback? here's the declaration: void command (GtkWidget *joliet, GtkWidget *rock, GtkWidget *verbose, GtkWidget *volid_entry, GtkWidget *input_entry, GtkWidget *output_entry); and I'm pretty sure this won't work: g_signal_connect (G_OBJECT (make_button), "clicked", G_CALLBACK (command), (gpointer) joliet, (gpointer) rock_ridge, (gpointer) verbose, (gpointer) volid_entry, (gpointer) in
<Nafallo> theunixgeek: wrong channel
<RAOF> theunixgeek: /topic.  This channel is not for development *on* Ubuntu :)
<theunixgeek> oh
<theunixgeek> never mind :)
<keescook> jdong: *rofl*
<jdong> keescook: lol you saw it too :)
<keescook> you totally had me for like 10 seconds.  multiple layer of "wtf" before I remembered the time.
<keescook> http://lkml.org/lkml/2008/3/31/367
<StevenK> Twitch
<StevenK> Perhaps they should have said OpenBSD and Theo is going to be a co-admin
<lamont> StevenK: did you see scrollback re: bluez-utils?  I wantses my dund back... or a writeup of how to get palm net-over-bt without it...
<lamont> StevenK: and I'm wondering if maybe dund isn't in the current dbus-hackery or such?  what about the other util binaries that got dropped, I wonder?
<StevenK> lamont: I saw it, but I'm not sure about it
<lamont> I'm pretty sure that it's the only thing keeping my secondary work surface on gutsy
<StevenK> So a binary has been dropped between gutsy and hardy?
<lamont> 3 of them
<ion_> jdong: Saw what? URL please. :-)
<lamont> see the diff in dpkg --contents between the two bluez-utils debs
<StevenK> lamont: Where is that output?
<lamont> StevenK: and comments in the bug about how maybe at least part of that is intentional
<StevenK> lamont: I've been distracted with $WORK for the better part of four hours since, what's the bug number?
<jdong> ion_: https://lists.ubuntu.com/archives/ubuntu-motu/2008-April/thread.html
<jdong> ion_: see if you spot anything wrong
<lamont>  dpkg --contents bluez-utils_3.19-0ubuntu3_i386.deb | grep /bin/
<lamont> drwxr-xr-x root/root         0 2007-10-03 02:55 ./usr/bin/
<lamont> -rwxr-xr-x root/root     10716 2007-10-03 02:55 ./usr/bin/ciptool
<lamont> -rwxr-xr-x root/root     20204 2007-10-03 02:55 ./usr/bin/dund
<lamont> -rwxr-xr-x root/root     39864 2007-10-03 02:55 ./usr/bin/hcitool
<lamont> -rwxr-xr-x root/root     32680 2007-10-03 02:55 ./usr/bin/hidd
<lamont> -rwxr-xr-x root/root      6904 2007-10-03 02:55 ./usr/bin/l2ping
<lamont> -rwxr-xr-x root/root     20620 2007-10-03 02:55 ./usr/bin/pand
<lamont> -rwxr-xr-x root/root     26784 2007-10-03 02:55 ./usr/bin/passkey-agent
<lamont> -rwxr-xr-x root/root     26848 2007-10-03 02:55 ./usr/bin/rfcomm
<lamont> -rwxr-xr-x root/root     62936 2007-10-03 02:55 ./usr/bin/sdptool
<lamont> -mix 780 : dpkg --contents bluez-utils_3.26-0ubuntu3_i386.deb | grep /bin/
<lamont> drwxr-xr-x root/root         0 2008-02-14 18:07 ./usr/bin/
<lamont> -rwxr-xr-x root/root     10620 2008-02-14 18:07 ./usr/bin/ciptool
<lamont> -rwxr-xr-x root/root     39864 2008-02-14 18:07 ./usr/bin/hcitool
<lamont> -rwxr-xr-x root/root      6844 2008-02-14 18:07 ./usr/bin/l2ping
<lamont> -rwxr-xr-x root/root     26848 2008-02-14 18:07 ./usr/bin/rfcomm
<lamont> -rwxr-xr-x root/root     62520 2008-02-14 18:07 ./usr/bin/sdptool
<StevenK> Argh. Pastebin!
<lamont> sorry - it looked shorter
<jdong> tha'ts what she said.
 * StevenK belts jdong
<Fujitsu> Yes, yes it is.
<StevenK> lamont: So, dund, hidd, and pand are missing?
<lamont> and there are corresponding --enable-foo entries in configure that weren't there before...
<ion_> jdong: Haha! (the email)
<lamont> OTOH, there are comments about having dbus integration for at least some parts of it...
<StevenK> lamont: You think we need a few --enable's scattered around, and the extra files installed?
<lamont> well, I can't see how to get dund otherwise... not so sure about hidd
<lamont> hidd and pand seem to maybe just possibly have dbus ducttape
<TheMuso> But that doesn't help those who may need such daemons on a system where there is no GUI, and no dbus...
<StevenK> lamont: Are you able to play, or were you hoping I would just fix it?
<lamont> I can play - I just wanted to give you the opportunity to say "hell no, not that way" :-)
<lamont> and then there's the question of whether we want to restore all of those binaries, just dund, or somewhere in between...
<lamont> and then there's the little tidbit that I'm going to hit bed in about 3 minutes...
<StevenK> lamont: I have no idea about bluetooth
<lamont> heh.  you gonna use my old argument of "I just upload bits??" :-)
<StevenK> lamont: Works for me. :-)
<lamont> ok.  so you think I should just enable all the binaries - and people can sort out dbus vs helper binaries at their leisure?
<lamont> anyway, I'll upload something in about 16 hours or so. :-)
<lamont> or maybe sooner, depends on how my day looks before core-hours tomorrow
 * lamont -> sleep
<calc> http://live.gnome.org/GnomeGoals/XDGConfigFolders <- Rock!
<ion_> calc: Awesome.
<calc> now just get .bashrc into there and it will be complete ;-)
<ion_> "if the user choose a default preference, this preference should not be saved anywhere and the corresponding entry in the config file should be empty" â¥
<ion_> calc: I have a ~/.config/shellrc, which is sourced by both .bashrc and .zshrc. :-) The .<shell>rcs still contain shell-specific stuff, but .config/shellrc contains everything that works in both shells.
<ion_> Slightly relevant to the quote i pasted, i've been thinking of hacking together a script that goes through your gconf settings and deletes every personal setting that matches with the system setting.
<RAOF> calc: Wheee!!!!  Yay, that'd be cool.
<calc> i just submitted the upstream bug for OOo
<calc> it will likely take a few centuries for them to fix that one ;-)
<Fujitsu> Isn't getting to OOo to work, not look like it has been hit by a train, and be quick, a little more important?
<Amaranth> Yes, I'd much rather have it look like a GNOME app instead of a Windows app with a gtk-like theme :)
<pitti> Good morning
<calc> Amaranth: changing the functionality of it though would end up making it hard for users to transition from Windows to Linux, but the look is going to improve some with the new font display patch
 * calc bbl, bedtime
<dholbach> good morning
<pitti> keescook: ah, thanks for fixing PK (bug 205037); did you forward it upstream?
<pitti> cjwatson: do you know why d-i in bug 193696 was marked 'invalid'? it's obviously still an issue
<\sh> Mithrandir: congrats to your new job...but hopefully you stay with ubuntu :)
<Mithrandir> \sh: thanks, and yes, I will
<warp10> Good morning
<Fujitsu> mvo: Around?
<mvo> Fujitsu: yes, hello
<Fujitsu> mvo: Hi. You're only running upgrade tests for main, aren't you?
<mvo> Fujitsu: mostly yes, universe is just so big. currently I have a test running with gutsy universe, but it takes quite a long time to finish. are you interessted in running some of this too?
<Fujitsu> mvo: It is unfortunate that it's so large :(
<Fujitsu> But yes, I poked you to ask how I could help.
<Fujitsu> We rebuilt universe and multiverse in 5 days, I'm sure we can manage upgrade testing in only a few times that interval.
<ogra_cmpc> oh, jdong finally uploaded automatix to the archive
<ogra_cmpc> cool :)
<bryce> wasn't automatix just declared as dead?
<ogra_cmpc> bryce, https://lists.ubuntu.com/archives/ubuntu-motu/2008-April/003510.html
<ogra_cmpc> bryce, morning btw
<mvo> Fujitsu: ok, sounds cool!
<bryce> morning
<mvo> Fujitsu: do you have access to a machine that supports kvm?
<bryce> huh, well whatever, guess I'm confused
<Fujitsu> mvo: Said machine is currently running Xen. Probably can't run both at the same time :(
<slangasek> Seveas: I've subscribed you to bug #209429 (the tzdata issue from the other day) because you indicated you were able to reproduce the problem; I'm having trouble reproducing it, and am hoping you can help me narrow it down
<mvo> Fujitsu: right, xen is fine for semi-manual testing.
<slomo> slangasek: hi :) may i update swfdec, swfdec-gnome and swfdec-mozilla? all in universe, no other rdeps except these three... swfdec-gnome is part of gnome 2.22 and needs swfdec0.6 (we currently have 0.5, soname change)... if we get these two we require new swfdec-mozilla too because the old version doesn't work with the new swfdec0.6
<slomo> slangasek: what do you think? if you need more information just ask :)
<slangasek> slomo: if you're asking for a freeze exception, you need to talk to motu-release
<slomo> slangasek: which makes things much more complicated... *sigh* ok, thanks
<dholbach> slomo: the bug is filed already and was approved AFAIK
<slomo> dholbach: thanks, i'll search for it
<dholbach> slomo: bug 202468
<james_w> can someone confirm that in https://bugs.launchpad.net/ubuntu/+source/ca-certificates/+bug/153625/comments/29 we are not using "ubuntu" in the version as we don't need to worry about auto-syncs?
<slangasek> james_w: I think that may have been an oversight on pitti's part
<james_w> so I need to prepare them as normal, but make sure that there is an upgrade path between all releases?
<james_w> (including maintainer update?)
<slangasek> make sure that the version numbers for each upload sort correctly wrt the releases, yes
<slangasek> (perhaps pitti did mean what he said, I don't know; but I don't see any reason that SRUs would be exempt from the DebianMaintainerSpec)
<james_w> I shall wait for his return, there's plenty of time while I create all my chroots anyway.
<lool> cjwatson: Hmm that Xsettings for the IM in Gtk+ never worked, right?
<ogra_cmpc> bryce, still around ?
<seb128> lool: do you understand the change sent to the bts?
<lool> seb128: Yeah, the backport was incorrect
<lool> I thought these were some codes, but these are actually offsets
<seb128> ok
<seb128> lool: btw about the glib upload, did you commit your changes to debian?
<lool> AFAIK yes, did I miss any?
<lool> I don't see anything pending in my SVN checkout
<Riddell> mvo: want me to approve release-upgrader-apt?
<Riddell> and -dpkg?
<mvo> Riddell: from when are those?
<Riddell>   456636 | S- | release-upgrader-apt | 0.7.9ubuntu1         | 12 days
<Riddell>          | * release-upgrader-apt/0.7.9ubuntu1 Component: main Section: debian-installer
<mvo> Riddell: please do, much appreciated
<Riddell> mvo: ok.  also update-manager 0.81.3 has been stuck in gutsy unapproved for 5 weeks I believe to wait for 0.81.2 to move from -proposed to -updates, is that in progress?
<mvo> Riddell: sort of, I need to nag bdmurray again I think
<Riddell> mvo: he added a comment to bug 172609 a while ago
<ubotu> Launchpad bug 172609 in update-manager "mishandles prerequists-sources.list on ports architectures" [High,Fix committed] https://launchpad.net/bugs/172609
<asac> soren: as part of the server team i wonder if you have a working samba setup :)?
<Fjodor> Sorry if this seems like a support question, but I just want to know if what I see is expected behaviour or not... I have replaced 2 old dvd drives with a single new one, and the symlink to the device is now /dev/dvd1 (and dvdrw1, cdrom1 and cdrw1). Is this to be expected, or shouldn't it rather be dvd, dvdrw, cdrom and cdrw, now that there is now only a single one of those types of drives?
<james_w> Fjodor: that's expected behaviour. hotplugging means that you can't know there will only ever be one.
<soren> asac: I have samba installed, and I haven't noticed it not working... But it's not something I use on daily basis (or even a monthly basis). What's up?
<asac> soren: :)
<Fjodor> james_w: Ok, thanks. I personal opinion would be, then, that it should be /dev/dvd0 then, shouldn't it?
<asac> soren: you are my tester then ;) ... bug 134082
<ubotu> Launchpad bug 134082 in network-manager "[gutsy][fiesty] network-mannager should restart samba if ip-address is changed." [Medium,Confirmed] https://launchpad.net/bugs/134082
<james_w> Fjodor: I don't know about that.
<asac> soren: does that happen?
<asac> soren: otherwise we might wanna try to ship a restart script in /etc/NetworkManager/dispatcher.d/
<asac> soren: what do you think?
<Fjodor> james_w: Ok. Thanks for your answer ;-)
<soren> asac: Restartin samba unconditionally seems icky. Won't a SIGHUP do the trick?
<asac> soren: you are much more in samba land than i am :)
<asac> (i guess)
 * soren tries to act innocent
<pitti> slangasek, james_w: right, that indeed was a typo; of course it should be ubuntu0.6.06 etc.
<asac> soren: you think we can come up with a script for dispatcher.d?
<asac> soren: how can me make samba behave correctly when changing the IP?
<pitti> james_w: do you want to prepare the SRUs, or shall I help you with them?
<soren> asac: Well, I'm hoping a SIGHUP (or smbcontrol reload-config) will make samba figure out that it's got a new IP.
<asac> soren: so only call SIGHUP on start) :?
<asac> and do nothing on stop?
 * ogra_cmpc thinks smbcontrol reload-config sounds way cleaner ... leave it to the tool to care 
<asac> well s/start/up/ s/stop/down/
<james_w> pitti: I'm happy to do it, I have all the chroots now, I might just have a couple of questions along the way.
<soren> asac: Yeah, when stopping, I think it figures it out on its own.
<pitti> james_w: right, I'll gladly help you with anything you encounter
<asac> soren: but thats strange
<james_w> pitti: so for dapper it would be 20050804-0ubuntu0.6.06 ?
<asac> soren: well not
<james_w> pitti: given that dapper currently has 20050804
<pitti> james_w: exactly
<james_w> great, thanks.
<pitti> james_w: -0ubuntu6.06 would work, too, but for hysterical raisins we usually use 0ubuntu0.6.06
<asac> soren: so you say that samba recognizes the down, but then doesn't get to know about he "up" ?
<asac> soren: would reload-config the right thing then?
<pitti> james_w: so that the next 'regular' ubuntu upload (ubuntu1) would be greater
<soren> asac: Well, in the down case, it notices that the network has gone away. In the up case (in the bug), it's just a matter of the IP changing.
<soren> asac: It's worth a try.
<soren> asac: I've not tried it. It's just a guess.
<soren> asac: (and haven't looked at code either)
<soren> asac: I can take a quick peek at the code, when I'm back from lunch.
<james_w> pitti: the bug referenced as an example on the SRU page also includes .changes, are those required? It also mentions something about the changelog mentioning approval.
<pitti> james_w: the debdiff is enough for review
<pitti> james_w: the .dsc, .diff.gz, and source.changes are the bits that actually get uploaded, but they can be generated from the debdiff
<pitti> james_w: well, since the changelog is part of the debdiff, it needs approval, too, right
<pitti> james_w: I'm picky about it because a lot of users read stable changelogs in update-manager
<pitti> james_w: so " * Fix bug (LP: #1234)" isn't helpful at all
<james_w> pitti: but the text of the changelog doesn't need to specify that the SRU is approved or anything?
<pitti> james_w: no; it should be a human-readable text which points out the impact, some technical details, and the bug #
<pitti> james_w: sth like " * Do not mark variable names ad translatable. This fixes certificates under Brazilian Portugese locales (LP: #1234)"
<pitti> i. e. properly describe the bug (for users), the solution (for developers), and the bug# (for tracking)
<james_w> ok, great. Thanks
<asac> soren: you could use /etc/NetworkManager/dispatcher.d/01ifupdown as a template if you want to give it a quick shot.
<ogra_cmpc> asac, btw, we were advised to use the suspend.d and resume.d dirs for that in gutsy (for dhcpd), is it better to use /etc/NetworkManager/dispatcher.d/ here ?
 * ogra_cmpc notes that the dhcpd patch should be updated to use pm-utils though
<ogra_cmpc> soren, are you the dhcpd guy now ? ^^^
<asac> ogra_cmpc: why suspend and resume if i want up and down handling?
<ogra_cmpc> hmm, indeed
<asac> i am confused :/
<ogra_cmpc> dhcpd is unlikely to be used on dynamic devices :)
<asac> ogra_cmpc: who knows. i am sure that someone complained that dhcpd doesn't work well with network-manager :)
<ogra_cmpc> heh
<ogra_cmpc> sorry, i didnt think that far, i thought they could be related but dhcpd is indeed different
<ogra_cmpc> still though, the patch needs updating
<asac> not sure ... maybe it should be restarted as well when network manager downs and ups interfaces :)
<ogra_cmpc> well, dhcpd should be run on dynamic interfaces at all imho
<ogra_cmpc> *shouldnt
<asac> how do prevent that?
<ogra_cmpc> by not tieing dhcpd start/stop to NM but to pm-tools :)
<ogra_cmpc> dhcpd will start if it finds an interface with an IP range iot knows from its own config
<ogra_cmpc> it wont start at all if thats not the case
<ogra_cmpc> so NM doesnt matter for it here
<soren> ogra_cmpc: I don't think so, no.
<ogra_cmpc> soren, i just saw it was handed to the server team recently here in teh channel, but forgot to whom
<ogra_cmpc> might have been mathiaz
 * soren has lost track of the amount of things he's supposed to handle :)
<james_w> pitti: I think the original fix may have been too simplistic, do we need to provide an upgrade path from broken versions that does something for pt_BR users?
<james_w> currently they still won't get any enabled, as they are all marked to ignore.
<james_w> is there a way we can detect if they were hit by the bug? We don't know what locale was used originally do we?
<cjwatson> pitti: because the bug was filed elsewhere, and in any case was never a d-i bug
<cjwatson> pitti: Steve's comment is correct
<cjwatson> pitti: there were two different bugs conflated into one
<scobby> hi all
<scobby> why you dont fix that errors in /usr/bin/compiz for the path !! the path is /usr/local/bin/compiz. but the right path would be /usr/bin/compiz.real !!
<scobby> i have already hardy installed and this basic bug is annoying
<pitti> james_w: indeed, there should be a transition path; maybe detect if the file sizes are 0?
<james_w> pitti: that's probably the safest, it would be bad for anyone that had chosen to enable no certificates
<pitti> james_w: hm, if someone dpkg-reconfigure'd the package and chose not to use any certificate, it would be empty as well?
<pitti> james_w: if we need to take debconf values into account, then IMHO a 'forced reconfigure' on upgrade should work?
<seb128> scobby: what bug is that? do you have a launchpad bug number?
<scobby> i dont know but its only a minor bug. the path is wrong. the right path is /usr/bin and there is /usr/local/bin. and the libary path is wrong too, and the compiz bin path
<scobby> every time i update compiz or reinstall i have to change these path to /usr/bin
<seb128> scobby: where is the wrong path used?
<soren> scobby: Where to you change that path?
<james_w> pitti: I'm unable to actually get debconf to ask me in the pbuilder chroot, I haven't yet worked out why
<scobby> wrong path in /usr/bin/compiz
<james_w> pitti: but a forced reconfigure wouldn't work for pt_BR I think, as they are all marked as rejected and so filtered out from the list that would be shown
<scobby> you see the wrong pathes in the compiz wrapper?
<scobby> any dev should repair that. but btw some people report it is working with that wrong path. but not for my 2 pcs
<soren> I see them, but I'm deeply surprised. compiz works just fine here.
<james_w> scobby: is there a bug in the bugtracker?
<scobby> you are one of them
<scobby> james_w: didnt search
<seb128> what wrong path is used?
<soren> seb128: The first variable set is COMPIZ_BIN_PATH
<scobby> wrong: /usr/local/bin  right: /usr/bin  same with COMPIZ_NAME="compiz"  but COMPIZ_NAME="compiz.real" is right
<seb128> Amaranth, mvo: around? ^
<soren> seb128: The final line that ends up calling compiz starts with $COMPIZ_BIN_PATH. Running it with sh -x clearly says /usr/bin/compiz.real, though.
<soren> Ah. /etc/xdg/compiz/compiz-manager has the answer.
<soren> scobby: Do you have that file?
<scobby> i have similar files
<scobby> scobby@laptop:~$ nano /etc/xdg/compiz/compiz-manager.
<scobby> compiz-manager.bak              compiz-manager.ubuntu           compiz-manager.ubuntu.dpkg-new
<scobby> compiz-manager.dpkg-dist        compiz-manager.ubuntu.bak
<scobby> but the pathes are wrong or i am wrong?
<Hobbsee> greetings
<james_w> that looks like fallout from some conffile updates
<seb128> scobby: the path are sent in /etc/xdg/compiz/compiz-manager
<seb128> s/sent/set
<seb128> hey Hobbsee
<soren> The paths in /usr/bin/compiz is (as you've seen) /usr/local/bin. However, we override that in a configuration file, which you seem to have chosen to remove.
<soren> (or at least rename)
<scobby> hmmm sucks. maybe in /usr/bin/compiz should be the right path from the beginning
<seb128> scobby: would need Amaranth or mvo to comment, but it seems to be the upstream version there and the ubuntu changes in /etc/xdg/compiz/compiz-manager
<seb128> scobby: why did you remove the correct configuration?
<scobby> i never removed that config. and i didnt know that there is also a config hidden ;-)
<mvo> scobby: as seb128 said, we use the compiz-manager wrapper that comes from upstream and use the config to customize it to our needs
<scobby> i think some people have that problems and the best solution would be to set the right path in /usr/bin/compiz and dont hope for a correct use of n /etc/xdg/compiz/compiz-manager
<seb128> scobby: if you didn't do that you used some broken tool which did it for you
<scobby> since i can think i always have to edit that /usr/bin/compiz
<scobby> and with hardy i have also to comment out that new laptop check for radeon ......
<seb128> scobby: restore /etc/xdg/compiz/compiz-manager and you will have no need to do those changes
<scobby> ok i try it
<scobby> but the laptop check has to be removed for me to, btw i dont understand why my laptop should not use compiz??
<scobby> ok i renamed that compiz-manager and now it works
<scobby> but this is not a good solution
<pitti> james_w: you might need dpkg-reconfigure debconf first
<pitti> james_w: hm, too bad; ah, right, the bug was in debconf itself, not in the evaluation of the debconf DB
<james_w> pitti: dpkg-reconfigure debconf does nothing either
<james_w> even with -plow -freadline
<Hobbsee> \sh: i did, then persia reinstated it.  Don't mention the lack of power of the MC and such
<cjwatson> pitti: sorry, lacking context, which bug in debconf?
<pitti> cjwatson: sorry, bad expression; I mean "the bug was in ca-certificate's debconf templates itself"
<cjwatson> ah
<pitti> cjwatson: not in the debconf package
<pitti> james_w: hm, weird
<james_w> http://lists.debian.org/debian-mentors/2003/09/msg00047.html
<james_w> it appears I can't do it within the chroot
<ogra_cmpc_> james_w, you can do fiddly things with the passthrough frontend and work through a filedescriptor that you can access from outside the chroot then i think
<pitti> Riddell: nice one on u-archive@!
<james_w> pitti: I think we can do it with a forced reconfigure, so that the only annoyance will be an extra question for non pt_BR users.
<james_w> ogra_cmpc_: I'd be happy with the readline frontend, so let's hope it doesn't come to that
<pitti> james_w: hm, extra question for affected users is ok (pt_BR), but not for the unaffected users?
<james_w> pitti: so, forced reconfigure if the file is empty, and just cope with annoying those few users who deactivated all certificates?
<pitti> james_w: that sounds good
<james_w> pitti: I'll try and come up with that then
<ogra_cmpc_> pitti, is there an easy way to prevent translations to be ripped out of a package ?
<james_w> pitti: we should put the improved fix in hardy as well?
<pitti> james_w: indeed, and please let's have it uploaded to hardy first
<pitti> ogra_cmpc_: export NO_PKG_MANGLE=1 in debian/rules
<ogra_cmpc_> thanks :)
<pitti> ogra_cmpc_: that will also suppress pkgmaintainermangler, though
<pitti> ogra_cmpc_: and prevent LP import
<pitti> ogra_cmpc_: why do you want to do that?
<ogra_cmpc_> seems we got a patch for ldm to make it translateable
<ogra_cmpc_> pitti, i dont need lang\packs in ltsp chroots ... the only thing exposed to the user is the ldm gui
<james_w> pitti: sure.
<ogra_cmpc_> so i'd like to keep the translations in ldm to save size
<ogra_cmpc_> (instead of installing the whole translation set)
<pitti> ogra_cmpc_: I see; that currently means that you need to use LP manually for translations
<pitti> ogra_cmpc_: yeah, makes sense
<calugor> haha I need to download more than the size of the CD to upgrade to 8.04
<calugor> 900mb :/
<Hobbsee> calugor: got a lot of stuff that's not on the cd installed?
<calugor> yeah
<calugor> but I thought they were the latest :P
<cjwatson> soren: is it intentional that kvm seems to do no work when it doesn't have X input focus?
<soren> cjwatson: Um.. No :)
<cjwatson> actually, that's not quite true - when it isn't on the current virtual desktop
<cjwatson> it's rather inconvenient not to be able to just leave a test running and go and do something else
<soren> cjwatson: Execution is halted?
<soren> cjwatson: With the sdl frontend?
<cjwatson> I'm running 'sudo kvm -hda ~/desktop.img -cdrom hardy-desktop-i386.iso -boot d -m 512'
<cjwatson> so whatever is the default I guess
<cjwatson> when I switch desktops, activity in my system monitor applet drops to zero
<cjwatson> but, interestingly, only if kvm had focus before I switched desktops
<cjwatson> if I alt-tab and then switch desktops, activity continues
<soren> When running like that, you don't need sudo.
<soren> Just access to /dev/kvm.
<cjwatson> ok, but does that matter?
<soren> Nono, not at all.
<soren> I'm just saying.
<cjwatson> I'll add myself to the kvm group, then
<ogra_cmpc_> but it might expose something
<soren> cjwatson: I can't seem to reproduce it..
<cjwatson> I noticed the same thing last night
<cjwatson> (but didn't nail it down quite as much)
<soren> Are you using compiz?
<cjwatson> no
<ogra_cmpc_> X bug ?
<cjwatson> Spads: do you have a minute to help me debug bug 210200?
<ubotu> Launchpad bug 210200 in cdrom-detect "cdrom-detect fails for HP DL145 in hardy beta" [Undecided,New] https://launchpad.net/bugs/210200
<jono> quick q - is the updated theme still in hardy - so when I click on Places, it has a brown border on the left?
<jono> after my upgrade that theme doesnt seem to be there
<\sh> Hobbsee: I just wanted to know..a bit surprising ;)
<soren> cjwatson: Wow. I've reproduced it. Extraordinary.
<Hobbsee> jono: you should switch to kubuntu.
<jono> heh
<cjwatson> soren: glad it's not just me
<soren> cjwatson: You switch virtual desktops with ctrl-alt-arrow keys, right?
<soren> Or did you trigger it some other way?
<mvo> Riddell: I did another upload of release-upgrader-apt that should make pkgstriptranslations happy, would be cool if you could accept it
<soren> ctrl-alt tells kvm (qemu, actually) to grab input focus. When you switch to a different virtual desktop, I'm guessing it can't finish grabbing input, so it gets stuck.
<cjwatson> soren: ctrl-alt-arrow, yes
<soren> qemu does it, too.
<Riddelll> mvo: ok
<mvo> rock, thanks riddell
<davmor3> soren: in qemu at least there is  the option to change the key for grabbing.  I think it's in prefs if memory servers
<soren> davmor3: prefs?
<davmor3> preferences
<soren> What preferences?
<davmor3> soren: sorry that might be part of qemu launcher the gtk app for setting up qemu
<soren> The key combo to do it seems to be #define'd in the code.
<cjwatson> davmor3: I'm not bothered about changing the key for grabbing, I'm fine with it being ctrl-alt; I just occasionally have to press ctrl-alt twice, that's all
<soren> davmor3: Maybe you're thinking of the alternate grab code? (ctrl-alt-shift)
<soren> davmor3: You don't seem to be able to specify arbitrary ones.
<soren> But yeah, at any rate, this is a bug.
<davmor3> soren: could be
 * Hobbsee erks
<Hobbsee> haven't been thru the u-d moderation quuee in a while, obviously
<Hydrant> hey all, quick question... how do I add libs to ld.so.conf under Ubuntu ?  I added a new .conf file in the ld.so.conf.d dir, but it doesn't get picked up
<Hydrant> I did an ldconfig after
<pitti> dholbach: argh, you assigned sponsoring of bug 205854 to me, but I cannot push into https://code.edge.launchpad.net/~ubuntu-art-pkg/usplash-theme-ubuntu/ubuntu
<ubotu> Launchpad bug 205854 in usplash-theme-ubuntu "Progress bar flickers during redraw" [Undecided,In progress] https://launchpad.net/bugs/205854
<pitti> dholbach: BTW, the source should get Vcs-Bzr: for debcheckout love
<pitti> dholbach: oh, and the branch is horribly out of date, too (from feisty)
<TomaszD> carlos, hi, could you take a look at https://bugs.launchpad.net/ubuntu/+source/seahorse/+bug/188859 , as this is a prevalent problem even after the latest langpack update
<ubotu> Launchpad bug 188859 in seahorse "Italian translation of seahorse is missing" [Low,New]
<TomaszD> Polish translation is missing as well
<TomaszD> something ain't right
<TomaszD> also, someone ( dholbach ? :] ) really needs to look at this simple patch-and-go https://bugs.launchpad.net/ubuntu/+source/brasero/+bug/200532
<ubotu> Launchpad bug 200532 in brasero "Brasero doesn't utilize .desktop translations from Rosetta" [Low,Confirmed]
<TomaszD> these two issues really mess up the translation state
<carlos> TomaszD: do you have /usr/share/locale-langpack/it/LC_MESSAGES/seahorse.mo file?
<TomaszD> pl, not it, but yes, I do have it carlos
<TomaszD> heh, pun not intended
<carlos> TomaszD: hmm, yeah, sorry
<carlos> TomaszD: I do have the es.po file too and it shows translated here
<TomaszD> carlos, there's just the desktop file that is translated and one string during authorization that says something about an app taking an action
<TomaszD> that's it
<TomaszD> the whole interface is in English, apart from this
<TomaszD> and I see the translation status for seahorse in Polish is 100% imported a long time ago
<TomaszD> so it must be in the langpack I'm using
<carlos> TomaszD: could you execute 'msgunfmt /usr/share/locale-langpack/pl/LC_MESSAGES/seahorse.mo|grep msgid|wc -l' ?
<carlos> that should give you the number of messages translated from language packs
<TomaszD> the result is: 751
<carlos> that means it's fully translated
<carlos> well, except two strings
<carlos> in Spanish I get 751 files
<carlos> in Spanish I get 751 translations
<TomaszD> carlos, in Rosetta it says:
<TomaszD> Statistics
<TomaszD> Messages: 758
<TomaszD> To do: 0
<carlos> TomaszD: do you have this other file? /usr/share/locale/pl/LC_MESSAGES/seahorse.mo ?
<TomaszD> carlos, no such file
<TomaszD> only in locale-langpack
<carlos> then I don't have an answer for you. You have the translations and nothing is overriding it
 * carlos installs the Polish lang pack
<TomaszD> hurray for carlos !
<TomaszD> ;]
<cjwatson> keescook: I've changed openssh in my CVS repository to have a proper CVE reference for bug 210175, FYI
<ubotu> Launchpad bug 210175 in openssh "[openssh] [CVE-2008-1483] allows local users to hijack forwarded X connections" [Undecided,Fix released] https://launchpad.net/bugs/210175
<carlos> TomaszD: it works here...
<TomaszD> carlos, oh shit... I meant policykit-gnome, I'm really sorry
<carlos> TomaszD: at least I don't see English strings neither Spanish strings but something I don't understand when I execute LC_ALL=pl_PL.UTF-8 seahorse
<carlos> TomaszD: ;-)
<carlos> ook
<TomaszD> try that
<TomaszD> it's UpowaÅ¼nienia in the menu
<TomaszD> why oh why was I thinking this was seahorse, damn
<TomaszD> ok, anyway
<TomaszD> I see that in launchpad the translation isn't imported
<TomaszD> "2008-02-29" last update
<TomaszD> lol, carlos I reported the problem a month ago already https://bugs.launchpad.net/ubuntu/+source/policykit-gnome/+bug/199029
<ubotu> Launchpad bug 199029 in policykit-gnome ".pot file isn't regenerated on build time or another template problem" [Undecided,New]
<dholbach> pitti: sorry, I didn't know the package was out of date, etc - I'm not an admin of the team, so I can't help with it
<pitti> dholbach: I just uploaded it now, since the branch was already out of date
<dholbach> pitti: right-o
<TomaszD> and then there's this problem https://bugs.launchpad.net/ubuntu/+source/policykit-gnome/+bug/200092
<ubotu> Launchpad bug 200092 in policykit-gnome "Untranslatable string in policykit authentication dialog box" [Undecided,New]
<lamont> slangasek: btw, the bottom of https://bugs.edge.launchpad.net/ubuntu/+source/bluez-utils appears to be mostly-dups of the "you changed bluez-utils to not work" collection :-)
<carlos> TomaszD: the first one is fixed
<carlos> TomaszD: about the second one... I cannot do anything about it...
<carlos> however, I think that's a duplicate
<TomaszD> carlos, yeah well it wasn't exactly fixed, did you try opening policykit-gnome with Polish locale?
<seb128> what is the issue?
<carlos> TomaszD: yeah, I get it untranslated too
<carlos> seb128: https://bugs.edge.launchpad.net/ubuntu/+source/policykit-gnome/+bug/200092 is a duplicate of https://bugs.edge.launchpad.net/ubuntu/+source/policykit-gnome/+bug/199255
<ubotu> Launchpad bug 200092 in policykit-gnome "Untranslatable string in policykit authentication dialog box" [Undecided,New]
<carlos> at least that's what it seems to be
<seb128> pitti: shouldn't this tool be masked from the menus? is it useful to any standard user?
<carlos> seb128: I'm not sure whether it may help you to fix it, but with strace, the policykit-gnome programs try to open message.mo file to get translations from
<TomaszD> I too think that policykit-gnome in the menu is not a good idea
<carlos> seb128: well, one of the missing translations is the one about the auth dialog when you try to increase your privileges
<TomaszD> yeah, just fix that, hide the menu entry and it'll be fine
<carlos> so that's still an issue, even that other application is removed from the menu
 * carlos -> back to the translations sprint....
<seb128> carlos: enjoy ;-)
<pitti> seb128: it's quite an expert tool, indeed
<pitti> it would be best if this was a separate package which we wouldn't install by default
<jeromeg> can somebody upload something for me in gutsy-proposed ?
<jeromeg> the bug is bug 156432
<ubotu> Launchpad bug 156432 in zim "Zim freeze when create a link" [Undecided,Fix released] https://launchpad.net/bugs/156432
<jeromeg> i attached a debdiff and it was approved by a member of motu-sru
<keescook> pitti: yes, oops, forgot to link it.
<keescook> cjwatson: ah, great, thanks.
<nxvl> cjwatson: i already fix Bug #210175
<ubotu> Launchpad bug 210175 in openssh "[openssh] [CVE-2008-1483] allows local users to hijack forwarded X connections" [Undecided,Confirmed] https://launchpad.net/bugs/210175
<nxvl> cjwatson: can you please take a look
<pitti> keescook: good morning
<pitti> keescook: thanks
<keescook> pitti: hi!  :)
<james_w> pitti: hi. http://paste.ubuntu.com/6327/ is my new propsed fix for hardy
<james_w> it checks if they are upgrading from a broken version and the file is empty, and if so offers a list of all certificates
<james_w> however the user must still select them all if they want them, which is a pain
<pitti> james_w: the version comparison looks a bit weird
<james_w> yeah, that might be my lack of shell scripting knowledge showing
<pitti> james_w: shouldn't a version for $release just compare against lt-nl fixed_version_in_$release?
<pitti> instead of each release testing versions from all other releases?
<pitti> james_w: right, IMHO you should pre-set the choices to enable all of them in debconf
<pitti> james_w: in particular, all choices which get enabled by default if you install the package from scratch
<pitti> I wonder if there is a much easier way to trigger that?
<james_w> I'm trying to take care of the upgrade path, so that if they install a fixed version and then reject all certificates they will not be prompted each time they upgrade a release.
<pitti> james_w: also, $cur_version is the old version in many cases, I think, not the one you are upgrading to
<pitti> because debconf often runs before preinst (ICBW, though)
<james_w> yes, that's what I want to use
<pitti> but 'eq'? shouldn't you need 'ge' then, which would again ruin the comparison?
<pitti> if we'll get another version into any release, it'll fail again, no?
<james_w> it will break if there are any more updates to stable releases, yes
<cjwatson> nxvl: uh, *I* already fixed it ... ;-)
<cjwatson> nxvl: oh, dapper-gutsy. Please talk with Kees
<cjwatson> nxvl: your patches look fine, but you should include the CVE ID in the changelogs
<pitti> james_w: hm, without knowing the package in detail: wouldn't it suffice to check the 'seen' flags?
<pitti> james_w: if seen is true, don't touch configuration; otherwise (seen is false), behave like installing from scratch
<pitti> shouldn't that be much more robust and less code?
<nxvl> cjwatson: yes, i meant dapper-gutsy patches i saw that it was already fixed on hardy
<cjwatson> nxvl: right, sorry, I was confused by the way you used the word "already"
<nxvl> cjwatson: np, so keescook is the one which need to take a look?
<cjwatson> or one of the other security team members, yes
<nxvl> ok thnx
<james_w> pitti: yes, you may be right, let me try that.
<pitti> james_w: *crossing fingers*
<SEJeff> jcastro, ping
<mvo> hm, "loadkeys de" seems to not work anymore in hardy, is that replaced with something different?
 * mvo takes that back
<cjwatson> it should do ... I thought I fixed that in hardy
<cjwatson> it didn't work in edgy-gutsy
<mvo> I'm confused now, it says loading /usr/share/keymaps/de.map.bz2 but that direcotry is empty :) - but it works
<mvo> (in hardy that is)
<cjwatson> the message lies, it actually runs ckbcomp behind the scenes
<mvo> heh :) ok, thanks
<mathiaz> mvo: is there a way to tell do-release-upgrade to use a local deb repository during the upgrade ?
<mathiaz> mvo: I'm trying to test a new version of the samba package to fix an upgrade problem
<mvo> mathiaz: yes, but its a bit complicated currently and requires some manual hacking unfortunately
<mathiaz> mvo: ok - I'll use apt-get dist-upgrade then
<james_w> pitti: it works: http://paste.ubuntu.com/6329/
<james_w> at least for the pt_BR case
<pitti> james_w: hm, that looks better, but isn't exactly what I meant
<james_w> ah, ok
<pitti> james_w: I thought if seen is false, then the question should stay 'low', and it shuold Just Happen
<mvo> mathiaz: in automatic upgrade  testing mode its simpler, but you need a kvm capable machine for this
<pitti> james_w: i. e. if the question is seen=false, we can assume that the user never dpkg-reconfigured it
<pitti> (right?)
<mathiaz> mvo: I do have such hardware !
<pitti> james_w: and thus clean up automatically; and if it's seen=true, we don't do anything, since it is manually configured
<james_w> well, I think the problem is the even if the user did the values are not stored correctly in pt_BR
<pitti> james_w: would that work?
<pitti> james_w: ah, I see
<james_w> I don't know if in the default case seen=false
<mario_limonciell> asac, I've been wondering, why does NetworkManager spam /var/log/syslog in it's own nonstandard format rather than it's own log file?
<pitti> james_w: ok, in this case we should set the priority to critical if locale is pt_BR only
<james_w> pitti: the current locale?
<TomaszD> carlos, sorry to bother you again, but where in lp can I find the template for this /usr/share/ubuntu-artwork/home/locales/index-pl_PL.html page (welcome page of firefox). dpkg -S doesn't return any package for this.
<carlos> TomaszD: if it's in Launchpad, it should be ubuntu-docs because is the only documentation that we translate using Launchpad
<pitti> james_w: I jsut installed ca-certificates from scratch, and the debconf questios  do not have the seen flag
<asac> mario_limonciell: i think its planned upstream for 0.7
<jwendell> hi, seb128. is gdm broken? console-kit, or something?
<carlos> TomaszD: better check with mdke
<mario_limonciell> asac, ah okay very good
<pitti> james_w: yeah, that should be good enough IMHO
<TomaszD> mdke, hi, where in lp can I find the template for this /usr/share/ubuntu-artwork/home/locales/index-pl_PL.html page (welcome page of firefox). dpkg -S doesn't return any package for this.
<pitti> james_w: (you can check it in /var/cache/debconf/config.dat, you know that?)
<james_w> pitti: you mean peek in to the file to see the current values?
<pitti> james_w: right, and the seen flags
<pitti> james_w: so: "unseen" -> behave like fresh installation, i.e. enable defaults without asking; "seen" and pt_BR: raise prio to critical; "seen" and != pt_BR: do nothing
<pitti> james_w: ^ is that correct?
<pitti> james_w: and all wrapped into a dpkg --compare-versions "$cur_version" lt-nl "fixed_version_in_this_release"
<pitti> james_w: maintainer scripts need to be idempotent anyway, so the code must work if run twice
<pitti> so, relying on 'eq' comparison is dangerous IMHO
<james_w> pitti: looking in the confid.dat it seems that all the information is there somehow, so perhaps it's possible to rescue this properly
<pitti> james_w: what do you think about the three cases I stated above?
<james_w> pitti: I think that's sensible.
<evand> We need to put something in the provider field in Add / Remove programs for Wubi.  Would the Ubuntu Foundation be the most appropriate option, or would "Ubuntu Community" or "Canonical Ltd." be preferred.
<evand> err publisher, not provider
<jcastro> SEJeff: pong
<cody-somerville> Is there any easy way to see if adding a package to the seeds will pull in other packages not already pulled in?
<cjwatson> james_w: use FGET rather than looking in /var/cache/debconf/config.dat by hand
<cjwatson> cody-somerville: you can run germinate locally and diff the output
<jwendell> Is GDM broken? https://bugs.launchpad.net/bugs/210335
<seb128> jwendell: re, not that I know
 * seb128 opens the bug
<seb128> jwendell: that bugs says nothing about gdm apparently
<jwendell> seb128, yes, I know, but this is the only clue I have
<seb128> how "broken" is it and since when?
<seb128> gdm didn't change for a while
<seb128> nor did consolekit
<cjwatson> evand: Ubuntu Foundation wouldn't be appropriate really, and Canonical doesn't feel appropriate since it's largely not written by us. Perhaps just "Ubuntu"?
<jwendell> seb128, GDM starts, I see the brown background, but it doesn't show the faces, the cursor is the 'wait' (circle)
<cjwatson> evand: (provided that this isn't a statement of copyright)
<evand> cjwatson: yeah, agreed.  Ok, thanks.
<jwendell> seb128, maybe usplash? there was an update of it...
<seb128> jwendell: try to downgrade or boot without usplash
<cjwatson> the usplash update is a no-op if you have a configured /etc/usplash.conf
<evand> cjwatson: in which case it would be Canonical?
<seb128> jwendell: since when do you have the issue, did you try to reboot?
<seb128> jwendell: what else did you upgrade?
<cjwatson> evand: no, that would be incorrect
<jwendell> seb128, yep, twice
<cjwatson> evand: we didn't write most of it and it's legally very dodgy indeed to claim copyright on something you didn't write (or pay for)
<seb128> jwendell: maybe try booting without usplash if you want to make sure
<jwendell> seb128, ok, will try now
<evand> ah, point taken
<ogra_cmpc_> evand, doesnt wubi have a copyright file you can pull that out from ?
<cjwatson> evand: the copyright holders are the actual legal entities who wrote the code - so Ago et al, and Canonical Ltd. for our contributions
<cjwatson> evand: but IIRC the provider field is not a statement of copyright so this is moot
<evand> ok, thanks
<jwendell> seb128, same thing :(
<seb128> jwendell: what did you upgrade since it was working?
<jwendell> seb128, it's not usplash
<jwendell> seb128, let me see
<seb128> jwendell: you can look to /var/log/dpkg.log
<cody-somerville> cjwatson, Can I use --seed-packages option to do what I want?
<jwendell> seb128, gnome-system-tools, gtk2-engines-ubuntulooks, gnome-icon-theme, apport, launchpad-integration, policy-kit, network-manager, console-setup, pulseaudio
<jwendell> seb128, I mean, I just upgraded all packages available today...
<seb128> I didn't upgrade yet
<seb128> cjwatson: could the console-setup changes create issues?
<seb128> jwendell: I don't see something which could create issues there
<jwendell> :'(
<lool> Heh #20276
<seb128> bug #20276
<ubotu> Launchpad bug 20276 in gtk+2.0 "CAL shows dates 5 - 14 october 1582 -  but they do not exist." [Low,Triaged] https://launchpad.net/bugs/20276
<slangasek> haha
<cjwatson> cody-somerville: yeah, I guess, though I'd just edit a local branch of the seeds and point it at that
<cjwatson> seb128: shouldn't think so ...
<cody-somerville> cjwatson, thats what I've ended up doing
<warp10> Hi all
<pitti> hey warp10
<lool> http://article.gmane.org/gmane.comp.tv.elisa.general/428
<lool> elisa team moves to bzr and launchpad
<pitti> warp10: congratulations to your ubuntu-dev badge! *hug*
<pitti> lool: ooh! not an April's fool, I hope? :)
<warp10> hi pitti, thank you! :) /me hugs back
<lool> pitti: Ah you're too quick :)
<pitti> lool: https://code.edge.launchpad.net/~elisa-developers/elisa/trunk doesn't look like a joke, though :)
<lool> pitti: Well I'm checking
<pitti> if it was a joke, the email wouldn't be funny at all, too
<lool> pitti: It didn't sound very funny, but then you have to be careful
<lool> Yeah
<ForzaPalermo> hey guys any luck getting system-config-samba working in heron?
<seb128> what is system-config-samba?
<ForzaPalermo> gui for samba
<ForzaPalermo> for idiots lik eme that cant configure it properly
<seb128> what is wrong with nautilus-share?
<jwendell> seb128, gdmgreeter eats 100% cpu...
<jwendell> seb128, any clue?
<seb128> no
<ForzaPalermo> never herad of that
<seb128> attach gdb to ir and look at the stacktrace
<ForzaPalermo> im runinning kubuntu
<seb128> ah, dunno about kubuntu
<seb128> jwendell: or strace it
<mathiaz> slangasek: I've attached a debdiff to bug 201059
<ubotu> Launchpad bug 201059 in samba "conffile prompt on latest upgrade in hardy" [Undecided,In progress] https://launchpad.net/bugs/201059
<mathiaz> slangasek: could you have a look at it ?
<slangasek> mathiaz: it'll take me a bit, but I will look at it, thanks
<mathiaz> slangasek: great ! thanks
<mdke> carlos: have replied to TomaszD in #ubuntu-doc, but for the record, the file is included in the ubuntu-docs source package, but not in rosetta - translations are done manually
<mdke> carlos: unless you know a reliable html<->po toolchain?
<cjwatson> mdke: have you tried po4a?
<cjwatson> assuming xhtml
<cjwatson> that's odd, the web site has http://po4a.alioth.debian.org/man/man3pm/Locale::Po4a::Html.3pm.php, but I don't see that module in the package
<mdke> cjwatson: no, will look into it. I don't think it is strict xhtml though
<cjwatson> still there in CVS too
<cjwatson> ah, "It also contains additional modules which are being considered, but are not of a sufficient quality."
<cjwatson> so maybe grab it from :pserver:anonymous@cvs.alioth.debian.org:/cvsroot/po4a and try it out
<mdke> will do, thanks for the suggestion
<slangasek> james_w: mime-support uploaded, thank you for your contribution to Ubuntu :-)
<jwendell> seb128, I guess it was latest human-icon-theme
<jwendell> seb128, I switched gdm theme from face browser to normal and it worked
<jwendell> seb128, how can I download human-icon-theme 0.25?
<jwendell> seb128, I'm going to download 0.24 and do the downgrade
<james_w> slangasek: thanks.
<jwendell> seb128, no way...
<seb128> jwendell: ?
<seb128> jwendell: I doubt the icon theme will create such issues
<jwendell> seb128, I thought it was human-icon-theme's fault
<jwendell> seb128, face browser is broken
<jwendell> I'll try another face browser theme
<jwendell> seb128, yep, it worked... somehow ubuntu humanlist theme is broken
<seb128> jwendell: ah, you don't use the default theme
<jwendell> seb128, isn't it default? ubuntu with face browser?
<seb128> no
<seb128> the default is human
<seb128> no face browser
<jwendell> seb128, ok then
<jwendell> :(
<Hydrant> calc: hey
<Hydrant> calc: do you know where I can get the SDK out of OO's downloads?  All I find is .exe files for anything prior to 2.4
<slangasek> mathiaz: oh, interesting heuristic indeed :)
<slangasek> mathiaz: was there no difference between the edgy and feisty configs?
<slangasek> mathiaz: otherwise - confirmed, and I look forward to dropping ALL of this code again for intrepid :)
<calc> Hydrant: nope
<pitti> keescook: why is bug 210175 an SRU? shouldn't it be an USN?
<ubotu> Launchpad bug 210175 in openssh "[openssh] [CVE-2008-1483] allows local users to hijack forwarded X connections" [Low,In progress] https://launchpad.net/bugs/210175
<keescook> pitti: right, it shouldn't be an SRU.
<keescook> odd, I didn't sub u-sru
<keescook> pitti: can you please unsub that?
<slangasek> Seveas: looks like the timezone bug is reproducible with an edgy install but not with a feisty install; following through
<pitti> keescook: sure, thanks
<Seveas> slangasek, strangely enough, my feisty install also doesn't have the file
<slangasek> Seveas: right, that confused me; but if I can reproduce it with edgy I at least have a starting point.
<slangasek> er, oh
<slangasek> no, /etc/timezone does get created during the install, eventually :/
<slangasek> so it's still not reproducible for me, mutter grumble
<Seveas> slangasek, which timezone are you picking?
<slangasek> mathiaz: btw, if you'd like me to do that samba upload, I have another fix I could roll in (bug #206036)
<ubotu> Launchpad bug 206036 in samba "package samba 3.0.28a-0ubuntu3 failed to install/upgrade: " [Undecided,Incomplete] https://launchpad.net/bugs/206036
<slangasek> Seveas: America/Los_Angeles; is there another you'd like me to try?
<Seveas> mine are both Europe/Amsterdam
<slangasek> ok, will try that
<Seveas> could be that cjwatson hates the dutch
<slangasek> then afterwards I'll try upgrading edgy->feisty->gutsy->hardy
<slangasek> you said your systems were installed as edgy/feisty; how far have they been upgraded?
<Seveas> incrementally to hardy
<slangasek> ok
<cjwatson> what timezone bug?
<cjwatson> (since I got highlighted ...)
<slangasek> cjwatson: bug #209429
<ubotu> Launchpad bug 209429 in tzdata "/etc/localtime bitrots" [High,Confirmed] https://launchpad.net/bugs/209429
<slangasek> basically, lifeless reported that /etc/timezone was missing, so he wasn't getting updated timezone data
<cjwatson> slangasek: I suggest asking for /var/log/installer/syslog to see if anything went wrong during instal
<cjwatson> l
<cjwatson> it could be that ubiquity didn't finish but he went ahead anyway, for example
<cjwatson> sometimes the system can still be mostly usable
<slangasek> Seveas: you still have /var/log/installer/syslog to hand?
<slangasek> cjwatson: so the timezone is saved after the bootloader is written out (hmm, eew)?
<cjwatson> slangasek: no, but somebody could have made bootloader arrangements by hand and then forgotten about it :)
<slangasek> heh
<cjwatson> tzsetup writes /etc/timezone unconditionally
<cjwatson> are we sure that lifeless' problem is that /etc/timezone is missing? he doesn't mention that in the bug
<Seveas> slangasek, one line related to tzsetup:
<Seveas> Jul 19 22:54:11 ubuntu ubiquity: Jul 19 22:54:11 ubiquity: Starting up '['log-output', '-t', 'ubiquity', '--pass-stdout', '/usr/lib/ubiquity/tzsetup/post-base-installer']' for ubiquity.components.timezone_apply.TimezoneApply
<slangasek> yes, we discussed it at length on IRC, the bug submission was more terse though
<Seveas> and something indeed went wrong
<Seveas> the system was not connected to the internet so could not install the NL langpacks
<cjwatson> slangasek: tzdata.postinst looks wrong to me
<slangasek> Seveas: could you attach the log to the bug, then?
<slangasek> cjwatson: current or past?
<Seveas> will check for sensitive info and do
<cjwatson> ... oh, no, sorry, I misread
<cjwatson> I thought it would only ever update /etc/localtime if you were in dpkg-reconfigure
<cjwatson> but I read || instead of &&
<slangasek> cjwatson: I've already been over the current tzdata.postinst with the Debian glibc folks, I'm fairly confident that it's correct
<cjwatson> yeah
<cjwatson> Seveas: that's just status output, we'd need more context
<Seveas> cjwatson, yeah, but that's a bit too much for irc, attaching to bug...
<Seveas> attached
<emgent> heya
<cjwatson> Seveas: and /etc/timezone is missing after that?
<cjwatson> there's no mention of a problem at that stage in the installer
<cjwatson> I think a maintainer script must be stomping on it
<slangasek> cjwatson: "after that" being "now that he's upgraded across three releases and is running hardy" :/
<cjwatson> perhaps the preinst should check if /etc/timezone is missing and if so try comparing /etc/localtime with all the timezone files to reconstruct it ...
<cjwatson> might not help either, but would help if the upgrade were direct
<Seveas> I'll run sime tests tomorrow
<cjwatson> could be gnome-system-tools for all I know
<Seveas> err, thursday
<cjwatson> or the clock applet
<Seveas> trashable system is in the office
 * cjwatson acquires a new level of understanding of how horrible the handling of the numeric keypad . (or in some layouts ,) key is
<mathiaz> slangasek: there isn't any difference between edgy and dapper
<slangasek> mathiaz: ok, cool
<mathiaz> slangasek: so you can upload a new version of samba with your fix
<slangasek> sounds good
<pitti> mjg59: WDYT about https://bugs.edge.launchpad.net/ubuntu/+source/network-manager/+bug/162654/comments/8 ?
<ubotu> Launchpad bug 162654 in pm-utils "networkmanager (0.6.5-0ubuntu16.7.10.0) needs to be restarted manually after suspend using pm-utils, while functioning correctly using acpi" [Undecided,Triaged]
<croSmiley> is there any way to code in c# in ubuntu?
<pitti> mjg59: I forwarded the 'network modules unload' patch to upstream, BTW, they didn't like it very much ('fix kernel instead kthxbye' type)
<pitti> mjg59: however, if we keep it, then I agree that we should also call /etc/init.d/networking stop/start on suspend/resume
<cjwatson> croSmiley: we ship Mono; this isn't a good place to ask about development *on* Ubuntu, though (this channel is for people actually developing Ubuntu itself)
<croSmiley> cjwatson: thank you, sorry for OT
<keescook> okay, so who is a g-p-m expert?  I want to immediately trigger power-save mode on my monitor (since it seems to have stopped working)
<thom> who do i need to talk to about #204066 ? (jcastro, you're in th eloop on this i think)
<slangasek> keescook: doesn't sound like a g-p-m thing if you're talking about a one-time event, though, maybe you want 'xset dpms'?
<slangasek> though ICBW
<keescook> slangasek: mostly I'm trying to just debug the lack of power-save.  :P  I'll start with xset...
<seb128_> keescook: g-p-m didn't change recently, since when do you have the bug?
<bryce> keescook: you could look at the code in xdg-screensaver; I think I included power saving commands in that
<keescook> seb128_: I noticed after my last big dist-upgrade, which was about 4 days ago (which covered maybe 10 days of updates)
<keescook> I just did another update today, and it's still a problem.
<keescook> so now it's time to debug.  ;)
<keescook> "xset dpms force standby" worked just fine
<seb128_> keescook: you can run gnome-power-manager --no-daemon --verbose
<seb128_> keescook: and set /apps/gnome-power-manager/timeout/sleep_display_battery in gconf-editor to some low value
<mjg59> pitti: Wurgh. No, I'm not convinced that's the right thing to do.
<keescook> but I'm on AC (this is my desktop)
<pitti> mjg59: but rmmod'ing any network devices will kill all up'ed devices in /etc/network/interfaces...
<seb128_> keescook: there is a similar ac key
<bryce> keescook: for reference, last change to xserver was the 13th, but mostly dealt with exa/glx video issues, not power saving (AFAIK)
<jcastro> thom: someone in -motu can probably look at it
<bryce> wait, let me doublecheck that
<keescook> bryce: yeah, it seems that x/intel is happy (dpms force worked)
<seb128_> keescook: well, the power saving delay will be idle + g-p-m setting, so you want to set /apps/gnome-screensaver/idle_delay to 1 too
<keescook> seb128_: it's safe to kill the existing g-p-m daemon first?
<seb128_> keescook: yes
<keescook> seb128_: okay, cool
<bryce> ah, timo put in 3 more patches over the weekend.  1 exa, 2 xkb.
<bryce> keescook: changes to -intel in last 10 days aren't likely to affect dpms either
<bryce> the last major -intel change was the greedy heuristics stuff, though, which had pretty far reaching implications (almost entirely good)
<keescook> seb128: hm, no standby happened.
<seb128> keescook: anything useful in the log?
<keescook> wtf, is the pastebin rot13'ing stuff for apr1st?
<keescook> http://paste.ubuntu-nl.org/61850/
<keescook> it doesn't mention DPMS during the idle.
<keescook> [x11_sync_server_dpms_settings] gpm-dpms.c:130 (13:45:01):       Syncing DPMS settings enabled=1 timeouts=0 0 0
<keescook> that seemed odd (the 0 timeouts)
<seb128> maybe worth talking to ted, he maintains gnome-power-manager now
<seb128> he did some change to the code to be action based
<keescook> tedg: I'm trying to debug lack of DPMS when idle
<keescook> dpms itself works (xset dpms force standby)
<keescook> and g-p-m notices I'm idle, but DPMS never seems to trigger
<keescook> log of it here: http://paste.ubuntu-nl.org/61850/  (though it seems pastebin is rot13'ing eveyrhting today)
<slangasek> heh
<tedg> It's probably because you don't have a laptop panel entry in your HAL.
<tedg> HAL tells GPM whether it has a panel that it can dim.
<tedg> Oh, wait, DPMS should be regardless of that.
<keescook> tedg: yeah, this is a desktop system.
<keescook> I'm unclear if this is sane:
<keescook> [x11_sync_server_dpms_settings] gpm-dpms.c:130 (13:45:01):       Syncing DPMS settings enabled=1 timeouts=0 0 0
<tedg> keescook: Nobody uses desktops anymore... *wontfix* ;)
<keescook> timeouts all 0?
<keescook> haha
<keescook> tedg: what should I expect to see in the gpm logs?
<tedg> You should see it setting that value.
<tedg> I'm trying to look for the logic, just a sec.
<keescook> okay
<keescook> tedg: note that this is, from my perspective, a regression -- it worked correctly prior to a few weeks ago-ish.  (I didn't change any gconf settings)
<keescook> (until today that is to debug it based on seb128's advice)
<andrea_c7a> Hi. I created a debdiff to fix bug #201330. Now I should look for a sponsor but https://wiki.ubuntu.com/SponsorshipProcess is not very clear on how to do this. Shall I set it as "Fix Released" ? Why not "Fix Committed" ? Why "unsubscribe ubuntu-main-sponsors" ?
<ubotu> Launchpad bug 201330 in compiz "Need to whitelist multiple ATI cards, or remove blacklisting" [Medium,Triaged] https://launchpad.net/bugs/201330
<pitti> andrea_c7a: subscribe ubuntu-main-sponsors and set it to 'fix committed'; that sounds pretty appropriate to me
<pitti> andrea_c7a: the part you are reading is for the sponsor
<tedg> keescook: I believe that it broke on my desktop also, but I hadn't looked into it at all.  I'm curious if an X change happened...  nothing GPM related has change.
<andrea_c7a> pitti: thanx I think I'll try that
<tedg> keescook: but there have been bugs where people complained about similar behavior.
<keescook> tedg: how do we debug it?
<tedg> keescook: So I'm thinking that GPM only sets DPMS for laptop panels.  Elsewise it expects X to set them.
<keescook> tedg: is that behavior a regression?  the gpm-prefs show a DPMS timeout.
<keescook> though it's called "put display to sleep"
<tedg> keescook: Perhaps, I'm thinking that the value has never actually done anything :)
<keescook> tedg: that's certainly not true -- my desktop goes into blank, and later into DPMS
<keescook> (or rather, it used to)
<tedg> keescook: But did that value change based on how you slid the slider?
<keescook> yeah
<keescook> at least I think so
<keescook> and either way, how do we debug the change in behavior?
<seb128> keescook: use the source? ;-)
<seb128> the g-p-m code is not really complicated
<keescook> I was hoping to avoid that if someone else knew it better already.  :P
<seb128> and the debug mode is verbose
 * keescook downgrades gpm
<seb128> tedg: btw did you package the new version?
<tedg> I don't think that'll fix it, but go ahead :)
<tedg> seb128: Yes, but I haven't logged out and in to make sure it doesn't kill my laptop yet, it works well on my desktop though.
<tedg> keescook: I'm thinking that it's getting that DPMS is disabled, but it turns out there is no debug message for that....
<seb128> tedg: could you give it a try so it can be uploaded? ;-)
<keescook> hrm...
<keescook> $ xset dpms 10 20 30
<keescook> $ xset -q | grep Stand
<keescook>   Standby: 10    Suspend: 20    Off: 30
<keescook> *change gpm*
<keescook> $ xset -q | grep Stand
<keescook>   Standby: 0    Suspend: 0    Off: 0
<keescook> I assume that's what this means:
<keescook> [x11_sync_server_dpms_settings] gpm-dpms.c:130 (14:07:38):       Syncing DPMS settings enabled=1 timeouts=0 0 0
<keescook>                         gpm_debug ("not laptop, so use GPM_BACKLIGHT_METHOD_STAGGER");
<keescook>                         method = GPM_DPMS_METHOD_STAGGER;
<keescook> that's a debug typo...
 * keescook wishes he had his gnome vcs login again
<keescook> I think sync_settings is failing
<keescook>         if (dpms->priv->active) {
<tedg> Yeah, it would seem that's the only path to all zeros.
<tedg> Do you see where "active" is initialized?
<keescook> tedg: not yet, I'm looking at the "Idle state changed" stuff currently
<keescook> i never see "Idle state changed: SYSTEM" in my logs.  should I?
<tedg> I guess it's possible depending on your timeout values.  But I don't think it should be normal if GPM is controlling everything.
<tedg> keescook: You find anything odd?
<keescook> I'm presently suspicious of 01_no_backlight_on_idle.patch
<keescook> yup.  that appears to be unchecked in my gconf for "idle_dim_ac".
<keescook> which means it never attempts DPMS
<keescook> tedg: that's a problem.  :P
<tedg> Yeah, for me too.  I wonder why it's unset.
<tedg> And why so recently... that patch has been in for a while.
<keescook> confirmed, checking that box made my DPMS kick in on idle.
<keescook> so... where does that gconf setting get controlled, and how could it get cleared?
<keescook> btw, it was only added 2 weeks ago
<tedg> It's in the schemas.  I just verified that we're not changing it in the packaging.
<keescook>   * Adding patch 01_no_backlight_on_idle.patch which was attached on to
<keescook>     Bug # 137598 by Tim Hull.  Not sure that it fixes the problem, but
<keescook>     seems like good code to include.
<keescook> I would refute your claim of "good code".  ;)
<tedg> No, that's when I combined everything.  I guess that's when it got pushed out to everyone then.
<tedg> I guess the problem here is that the GConf value is related to dimming, in reality we're talking about blanking.
<keescook> other people in bug 137598 have my same complaint.  :(
<ubotu> Launchpad bug 137598 in gnome-power-manager "Screen brightness resets to default (maximum) on idle with AC plugged in" [High,Fix released] https://launchpad.net/bugs/137598
<keescook> tedg: idle_changed_cb is the entire "backlight" idle entry point.  :P
<tedg> keescook: Yes, that report makes sense now....
<keescook> the dim check needs to happen somewhere else, I imagine.
<keescook> can we drop that patch for release, and file the dimming bug upstream to get solved more cleanly?
<tedg> Well, it seems like it should be in "evaluate_and_set" when it checks to see if the other dimming options are set.
<keescook> tedg: 207553
<Level15> if i boot off the alternate cd in recovery mode and choose Reinstall Grub boot loader option, is there a way to know if it worked (besides rebooting), and if it didn't work, see the error messages?
<norsetto> pitti: any chance superpitti is around?
<tedg> keescook: It looks like the patch is included in 04, so when moving it, it becomes duplicate.
<tedg> keescook: I'm removing that one in favor of 04.
<TheMuso> norsetto: pitti is off for the night I believe.
<norsetto> TheMuso: Yes, I wouldn't be surprised, how is it going with you?
<TheMuso> norsetto: Well thanks. Yourself?
<alex-weej> scaled video looks like ass with compiz in the default install
<alex-weej> can we not use gl output or something?
<keescook> tedg: sure, sounds good
<norsetto> TheMuso: I'm fine, thx
<keescook> tedg: okay, so you'll drop 01 as a fix for 207553?
<tedg> keescook: Yes, building a PPA version and testing, but that's the plan.
<seb128> don't reintroduce the other bug
<keescook> \o
<tedg> seb128: Yes, it turns out that it was also fixed by the 04 patch.  We were infact fixing it twice.
<seb128> ah, ok
<seb128> alright then
<tedg> If we fix it twice does that mean we have negative bugs?
<tedg> ;)
<alex-weej> is Xv supposed to work with composite?
<tedg> alex-weej: I don't believe so.  There is a compiz video plugin, and a gstreamer output for it, but I dont' think it's super stable.
<jdong> supposed to? yes.
<jdong> depends on what card whether or not it actually works.
<alex-weej> i've just discovered that fglrx actually does composite well now
<tedg> alex-weej: Sorry, work, yes, is it GL happy, no.
<alex-weej> so i'm testing it out
<jdong> it works perfectly on nvidia for me, somewhat okay on Intel, puke on fglrx
<alex-weej> is Xv supposed to work at all?
<jdong> alex-weej: for everyone not fglrx, yes
<alex-weej> cause i can't get gst to run with xv sink
<alex-weej> it didn't work with radeon either
<jdong> alex-weej: fglrx has been braindead retarded with xv for the past decade
<jdong> right now xv works okay with moderate diagonal tearing with composite off
<jdong> and with composite on, 90% of users report freakish flickering
<jdong> so YMMV
<alex-weej> with fglrx?!
<jdong> yes, with fglrx
<jdong> personally I run fglrx 8.40.4 with Xgl because it works the smoothest
<alex-weej> maybe it's my card then, but the R350 on both fglrx and radeon fails to get an Xv output
<alex-weej> hm, aticonfig...
 * alex-weej restarts X
<jcole> im trying to install the latest hardy beta from the destop cd and cant figure out how to find my raided /home partition
<jcole> i see the 2 separate ones, but not the unified of those 2
<jcole> i originally installed via the debian installer
<jcole> prehaps i can modprobe something in ctrl-alt-f1?
<jcole> software raid0
<TheMuso> jcole: The desktop CD doesn't support installing/using RAID partitions for installing.
<jcole> TheMuso: ah, just like encrypted partitions...
<TheMuso> jcole: I believe so yes.
<TheMuso> jcole: I think the alternate CD is your best bet.
<jcole> TheMuso: the alternate cd and the mini.iso both hang
<TheMuso> jcole: How so?
<jcole> TheMuso: locks up my machine
<TheMuso> jcole: Where abouts in the process does it hang?
<jcole> TheMuso: installing the kernel
<TheMuso> ah ok... interesting.
<jcole> TheMuso: it install all the packages
<jcole> TheMuso: everything
<jcole> TheMuso: but cant get to the kernel or grub
<jcole> TheMuso: ya, that shouldnt matter since its running the d-i kernel
<jcole> TheMuso: i wanted to see ctrl-alt-f4 but it locked up
<TheMuso> jcole: Right, I'm not sure if I can help you then.
<jcole> TheMuso: march 20 was the last release right?
<jcole> TheMuso: the mini.iso is dated the 10th -> http://ubuntu.osuosl.org/ubuntu/dists/hardy/main/installer-i386/current/images/netboot/
<TheMuso> jcole: Are you referring to the beta?
<jcole> ya
<TheMuso> jcole: Have you tried the latest daily cd image?
<jcole> no
<jcole> TheMuso: where do i get it?
<TheMuso> jcole: http://cdimage.ubuntu.com/daily/current >- alternate CD
<TheMuso> jcole: http://cdimage.ubuntu.com/daily-live/current <- desktop CD
<tedg> keescook: It's in my PPA, should be built shortly.
<keescook> cool
<jcole> TheMuso: ill get the images from there from now on
<jcole> TheMuso: is there a daily mini.iso?
<jcole> TheMuso: thats what i usually use... we have internal mirrors that we point to
<TheMuso> jcole: The only time mini.iso gets updated is when a new debian-installer is uploaded.
<TheMuso> jcole: But you can find the mini.iso in your local mirror dists/hardy/main/installer-i386 dir I think it is.
<jcole> TheMuso: i did... and burnt it... doesnt work
<jcole> TheMuso: it should be rebuilt everytime there is also a kernel change
<TheMuso> jcole: Yes thats right.
<jcole> TheMuso: thanks alot
<jcole> TheMuso: ill try the daily build and see how it goes :)
<jcole> $ wget -c --no-cache http://cdimage.ubuntu.com/daily/current/hardy-alternate-i386.iso
<jcole>  6% [=>                                   ] 43,375,965   105.11K/s  ETA 1:12:30
<cjwatson> a hang installing the *kernel* is pretty odd - oh, he's gone
<cjwatson> syslog will be useful, if he comes back
#ubuntu-devel 2008-04-02
<verb3k> Whatever happened to the to the kernel scheduler bug? (I've been trying to find it's entry in launchpad but no luck so far)
<Hobbsee> morning all
<LaserJock> hi Hobbsee!
<TheMuso> Afternoon Hobbsee.
<Hobbsee> hey LaserJock, TheMuso!
<LaserJock> jdong, imbrandon : around?
<lamont> slangasek: if we just do dund, then there's no bug in LP...
<lamont> hrm... maybe I should get dbus working again on this machine before I upload a new bluez-utils, eh?
<slangasek> ... ok :)
<lamont> 105      12403  0.0  0.0   4268  1792 ?        Ss   Mar27   0:03 /usr/bin/dbus-daemon --system
 * lamont is pretty sure there should be a name there, rather than '105' :-)
<StevenK> 105       5380  0.0  0.0  23876  1248 ?        Ss   Feb05   0:19 /usr/bin/dbus-daemon --system
<StevenK> It's like that on my machine too
<lamont> interesting
<lamont> I'm betting you don't get a dbus permission denied when you plug in a usb drive, though
<StevenK> Right, I don't.
<lamont> cannot mount volume.  Error org.freedesktop.DBus.Error.AccessDenied.
<lamont> \o/
<lamont> am I supposed to have a 'hal' group?
<StevenK> I have a haldaemon group
<StevenK> But no hal group
<lamont> haldaemon:x:131:
<lamont> ok
<lamont> the other thing I did right about the time I upgraded to hardy was to rip out the ldap entries in nsswitch.conf... I fear maybe I needed some of that...
<lamont> for my next trick, I'll just --reinstall all the hal and dbus crap
<lamont> er, pacakges
<slangasek> lamont: that's just because strlen("haldaemon") > 8 :P
<lamont> slangasek: iz not.
<slangasek> the 105 in your ps output? yes it is
<lamont> oh, that
<lamont> ok
<lamont> actually, it's because strlen("messagebus") > 8 :-p
<lamont> so, iz not. :-)
<slangasek> ah, heh :)
<lamont> interesting.  reinstall hal/dbus --> system restart required.  heh
<StevenK> Yes.
 * lamont applies the full-on redmond solution
<lamont> brb
<StevenK> Upstream are convinced you can't restart the dbus message bus, you need to reboot
<slangasek> The full-on redmond solution?  You're going to buy someone else's innovation to solve your business needs?
<StevenK> Hahah
<lamont> well, I'm gonna guess that maybe the 5 "dbus-daemon --fork --print-address 25 --print-pid 27 --session" processes on the machine _might_ be related to my challenges
<lamont> slangasek: lol
<lamont> I was referring to the "reboot and see if that fixes it" approach, you ninny. :-p
 * lamont really reboots
<lamont> well, that was less than successful...
<StevenK> Now it fails to boot?
<lamont> nah
<lamont> it boots
<lamont> still refuses to mount media
<lamont> A security policy in place prevents this sender from sending this message to this recipient
<lamont> where is "message bus configuration file"
<lamont> ?
<lamont> error name "(unset)" destination "org.freedesktop.Hal"
<StevenK> /etc/dbus-1/system.{conf,d/}
<lamont> or am I missing something trivial?
<lamont> well, on the bright side, I only have one dbus-daemon --session process now (and one --system)
<lamont> does the user need to be in any particular group to mount USB media, I wonder?
<StevenK> plugdev
<lamont> plugdev:x:46:lamont,haldaemon
<lamont> hrm... gutsy laptop has /var/run/hal, broken hardy desktop does not... I wonder if it should?
<lamont> OTOH nothing is using /var/run/hal on the laptop
 * lamont actually logs in on the laptop
<lamont> ah.  that's just var/run/hal -> var/run/hald in the gusty->hardy transition
 * lamont wishes he had some clue of how dbus/hal/etc actually bolt together so he could debug this...
<lamont> I guess I'll just file the bug and see what happens... :-(
<lamont> I wonder what package I should file that bug against?
<lamont> well, adding dund fix0rs my palm syncing at least.
<lamont> slangasek: last chance to squawk before I upload it (just added --enable-dund)
 * lamont smiles at http://www.coloradoan.com/apps/pbcs.dll/article?AID=/20080331/BUSINESS/803310324/1046/CUSTOMERSERVICE02
<slangasek> cjwatson: huh, system-tools-backends already has code that scans for matching zone files in some cases
<warp10> Good morning
<ogra_cmpc_> bryce, are you aware of problems with via chipsets and framebuffer memory detection ? seems i have some users where X doesnt start due to a memory mistmatch of what the framebuffer driver detects and what the xserver wants ao allocate
<ogra_cmpc_> s/ao/to
<ogra_cmpc_> bug #208137 (and probably related) bug #197514
<ubotu> Launchpad bug 208137 in ltsp "HP t5000 - vt8623fb - memory size detection failed" [Undecided,New] https://launchpad.net/bugs/208137
<bryce> ogra_cmpc_: nope; is that due to recent via changes?
<ubotu> Launchpad bug 197514 in xserver-xorg-video-openchrome "VIA/S3G VT8623 [Apollo CLE266] display no longer works" [Undecided,Confirmed] https://launchpad.net/bugs/197514
<ogra_cmpc_> bryce, i have feedback from three people, they claim it worked with one of the alphas
<dholbach> good morning
<ogra_cmpc_> bryce, https://lists.ubuntu.com/archives/edubuntu-users/2008-March/003815.html might be intresting as well
<ogra_cmpc_> morning dholbach
<dholbach> hi ogra
<bryce> ogra_cmpc_: looks like superm1 has been posting updates to it - I'd speak with him.  Looks like a new upstream version was released in early January
<ogra_cmpc_> ok, i'll try to catch him
<bryce> ogra_cmpc_: timo has also done some recent updates, but only packaging stuff
<ogra_cmpc_> yeah, i asked him already, he didnt know about the prob
<bryce> ogra_cmpc_: it looks like the driver hasn't changed since january, so if the problem cropped up later than that, then it may be due to something other than the driver
<ogra_cmpc_> bryce, do you mean the frameboffer driver or the X server ?
<bryce> the X driver
<ogra_cmpc_> to me it looks like X wants 32M while FB only allocates 16M
<TheMuso> evand: Before you vanish, as I said in the meeting, I can start earlier tomorrow so we can work through a11y issues, if thats any help.
<kagou> Hi
<evand> TheMuso: ok, fwiw fixing the SUDO_* issue alone doesn't seem to solve the problem.
<TheMuso> Ok, but that still needs addressing...
<evand> I don't need to be anywhere tomorrow night, so I should be around to work through it with you.
<evand> indeed
<evand> I'm just invalidating my earlier statement about us being really close :)
<evand> s/should/will
<TheMuso> ok
<TheMuso> And sorry, I meant this for the installer channel. :p
<evand> heh, no worries
<slangasek> Hobbsee, TheMuso: would you mind having a look at bug #209783 for a universe FFe?
<ubotu> Launchpad bug 209783 in translate-toolkit "UVF exception / sync request for translate-toolkit" [Undecided,Confirmed] https://launchpad.net/bugs/209783
<ogra_cmpc_> tjaalton, q-funk is using his ppa atm
<tjaalton> ogra_cmpc_: hmm ok
<ogra_cmpc_> so indeed he wont complain
<ogra_cmpc_> and imho we should pull his packages for an SRU (with extreme testing in advance indeed)
<ogra_cmpc_> we lost many users due to the amd breakage i'd love to win back
<tjaalton> hmm the packages he's ppa has are for gutsy
<ogra_cmpc_> (but i fear SRUs of such a size and possible impact)
<tjaalton> so hardy should be fine
<ogra_cmpc_> yeah, for hardy you dont need SRUs yet :0
<ogra_cmpc_> :)
<tjaalton> ah :)
<LaserJock> is there a buildd admin about?
<cjwatson> $ bzr checkout bzr+ssh://bazaar.launchpad.net/~ubuntu-core-dev/grub/ubuntu
<cjwatson> bzr: ERROR: Repository KnitPackRepository('file:///home/cjwatson/src/ubuntu/grub/bzr/ubuntu/.bzr/repository/') is not compatible with repository RemoteRepository(bzr+ssh://bazaar.launchpad.net/%7Eubuntu-core-dev/grub/ubuntu/.bzr/)
<cjwatson> slangasek: do you have any idea what's going on here?
<slangasek> hrm, can't say that I do
<cjwatson> hmm, the remote is a rich-root repository
<slangasek> old version of bzr locally?
<cjwatson> bug 205579
<ubotu> Launchpad bug 205579 in bzr "bzr checkout doesn't work with rich-root-pack" [Undecided,New] https://launchpad.net/bugs/205579
<cjwatson> includes workaround too, woo
<slangasek> mm
<slangasek> ah, good :)
<slangasek> rich-root was unfortunately the only option that would let me splice a Debian svn branch with an upstream bzr branch
<slangasek> ... and then I haven't been able to use it since because of a bzr-svn bug
<cjwatson> yeah, it would be
<seb128> does moving a conffile between binary packages require maintainer script handling?
<slangasek> no
<seb128> or just the appropriate replaces in the new binary?
<slangasek> yes
<seb128> ok, good
<seb128> thanks
<\sh> cjwatson: hmm....what about the daily of hardy server from today? I see, that alternate is already there...is server still in preparation? :)
<pitti> Good morning
<\sh> moins pitti :)
 * pitti yawns and radiates hate towards EINTR, which kept him awake debugging half of the night
<seb128> hey hey pitti
<LaserJock> pitti!
<LaserJock> just the man I wanted to see
 * pitti hides
<LaserJock> pitti: I need ghemical given back
<pitti> LaserJock: done
<LaserJock> pitti: excellent, thanks
<cjwatson> \sh: cron job runs at a different time *shrug*
<cjwatson> 31 7 * * *      for-project ubuntu cron.daily; for-project ubuntu cron.daily-live
<cjwatson> 29 10 * * *     for-project ubuntu-server cron.daily; for-project ubuntu-server cron.ports_daily
<\sh> cjwatson: ah...so it's still in makeing ;) -ENO it's UTC or CDC? or is CDC now UTC? :)
<soren> CDC?
<cjwatson> \sh: London time (UTC+0100 right now). Please have patience
<cjwatson> Canonical Data Centre, I imagine
<slangasek> asac: well, mozilla-plugin-gnash prerm is buggy, it uses "set -e" and then a "&&" instead of if;then
<soren> Ah.
<\sh> soren: in the past there was this special timezone named CDCT ;) Canonical DataCenter Timezone ;)
<cjwatson> slangasek: is that buggy? I always used to think it was, but && is supposed to be enough to prevent set -e firing
<soren> timezones are confusing enought withou people inventing their own acronyms and adding them to the soup.
<soren> (how did that 't' wander all the way from the end of "without" to the end of "enough"?)
<cjwatson> bash(1) says "The shell does not exit if the command that follows is [...] part of a && or || list"
<cjwatson> dash(1) says "The exit status of a command is considered to be explicitly tested [...] if the command is the left hand operand of an "&&" or "||" operator"
<cjwatson> http://www.opengroup.org/onlinepubs/009695399/utilities/set.html has similar language
<cjwatson> so I think any shell that terminates under 'set -e' when you run 'false && true' is buggy
<slangasek> oh, hmm
<harrisony> has ext2 support being removed from the ubuntu installer (trying to debug why it isnt working)
<cjwatson> harrisony: ! no
<pitti> I created an ext2 partition with last week's daily
<cjwatson> slangasek: bash, dash, and posh all seem to get this right; I think this is one of those pervasive shell myths, since both you and I had picked it up (unless it really does fail in some case more sophisticated than 'false && true')
<slangasek> cjwatson: ok, you're right then; I guess I was mistaking this for the fact that it'll kill make if you do this :)
<harrisony> argh, must be lvm then
<cjwatson> harrisony: desktop CD?
<cjwatson> slangasek: wow, so it does
<slangasek> asac: ok, so instead it's just buggy because xulrunner-addons is missing from the list :-)
<harrisony> cjwatson:  http://ubuntuforums.org/showthread.php?p=4635054
<cjwatson> of course, because the compound command exits 1 and make can't/doesn't-want-to tell that it's part of a && list
<harrisony> yes desktop cd
<slangasek> cjwatson: right :)
<cjwatson> harrisony: desktop CD doesn't support LVM, RAID, or encrypted partitions
<cjwatson> harrisony: use the alternate CD
<emgent> heya
<cjwatson> ooh, the kernel guys made EDD a boot option
<harrisony> cjwatson: ah ok, thanks
<cjwatson> we might actually be able to do something with all those grub device mapping bugs, at least with a release note saying "if it breaks, use edd=on"
<cjwatson> with a little bit of glue in grub ...
<dneary> Any sign of Jono about?
<asac> slangasek: oh its missing in prerm you mean?
<slangasek> asac: correct
<asac> slangasek: ok fixing
<asac> slangasek: hmm ... do i need to do some cleanup?
<slangasek> asac: ok, thanks - I haven't looked yet whether there's an open bug about this
<slangasek> not really, the only opportunity you'd have to cleanup is if the user installed mozilla-plugin-gnash again?
<slangasek> in which case, it's automatically not an issue? :)
<asac> slangasek: no ... i mean cleanup for all those poor users that ended up in manual state :)... but i don't think i can detect if that happened by accident
<slangasek> mmm, yes, difficult
<pitti> tkamppeter: cupsys' ppd-poll-with-client-conf.dpatch was apparently rejected upstream; what should happen with that patch? Mike said it's incorrect?
<slangasek> asac: some additional cleanup /may/ be possible, but there's no reason to tie it to fixing this part of the bug
<asac> slangasek: i will upload the fix without cleanup for now
<slangasek> ok, cheers
<asac> at least there is a pattern. same is missing for gnash
<asac> doing that too now
<slangasek> :)
<tkamppeter> pitti, it is some way to work around problems caused by badly implemented routers. I have a T-Online router which answers DNS requests with "noname" to all IPs which it has given via DHCP, and for which no hostname was set manually in the router.
<pitti> tkamppeter: hm, why does upstream neglect that problem? i. e. does Mike refuse to fix the problem, or does he ack it, but he doesn't like the patch?
<tkamppeter> Reverse DNS lookup of "noname" returns the IP of one arbitrary machine, always the same one.
<pitti> tkamppeter: (BTW, I prepared 1.3.7 last night, will upload soon)
<tkamppeter> CUPS covers the sace of not having DNS at all, but on my router one cannot turn off the DNS.
<tkamppeter> Mike does not relly like to fix something here. He simply rejected the bug report once telling the patch is wrong and second telling it is a configuration problem of the network.
<tkamppeter> It seems that Mike is strictly against workarounds for buggy hardware. See also the Ubuntu bug report about Brother printers which do return broken device IDs erratically. Bug 35638]
<ubotu> Launchpad bug 35638 in cupsys "Printer is not detected properly over USB" [Medium,Confirmed] https://launchpad.net/bugs/35638
<tkamppeter> I think this bug can probably fixed somehow by patching the USB CUPS backend.
<dholbach> Keybuk: do you think we could have       create_devices || true        in udev's postinst? that'd fix its installation in my vserver :)
<tkamppeter> I think this bug can probably fixed somehow by patching the USB CUPS backend.
<tkamppeter> I was already thinking about starting some initiative with the distros (and also driver developers of manufacturers) about patching CUPS concerning hardware bug workarounds.
<tkamppeter> Mike supports only what follows EXACTLY the standards.
<tkamppeter> pitti, WDYT, what should we do here?
<pitti> tkamppeter: ok, let's keep the patch for a bit then; maybe you can add some details to the ## DP: of the dpatch, an explanation, rationale, pointers to STRs?
<ogra_cmpc_> seb128, if i understand 03_blacklist-directories.patch in glib2.0 right, everything mounted under /live/cow and /live/image should be completely ignored by nautilus ?
<seb128> ogra_cmpc_: yes
<ogra_cmpc_> hmm
<ogra_cmpc_> doesnt work here
<seb128> at least you should get no mount icons for those
<seb128> not sure what you call completely ignored
<ogra_cmpc_> i still se the cow device on my classmate desktop and its definately mounted under /live/cow everywhere
<seb128> weird
<seb128> only /media and user directory mounts should be listed
<ogra_cmpc_> /dev/sdb2 /live/cow ext3 rw,noatime,relatime,data=ordered 0 0
<ogra_cmpc_> unionfs / unionfs rw,relatime,dirs=/live/cow=rw:/live/rofs=ro,debug=4294967295,delete=whiteout 0 0
<ogra_cmpc_> unionfs /dev/.static/dev unionfs rw,noatime,relatime,dirs=/live/cow=rw:/live/rofs=ro,debug=4294967295,delete=whiteout 0 0
<ogra_cmpc_> thats what /proc/mounts has
<ogra_cmpc_> shoould be ok i think
<ogra_cmpc_> oh, wait
<ogra_cmpc_> seb128, does it read mtab or /proc/mounts ?
<ogra_cmpc_> i dont have a line for /live/cow in the output of mount
<seb128> ogra_cmpc_: mtab I think
<ogra_cmpc_> (i.e. no mtab entry)
<ogra_cmpc_> aha
<beasty_> morning
<beasty_> is there some way to build your own .deb package out of a modified 'apt-get source' package ?
<tkamppeter> pitti, I have added the description to the patch on SVN.
<pitti> tkamppeter: to trunk?
<pitti> tkamppeter: right, thanks!
<cjwatson> beasty_: debuild (devscripts package)
<pitti> keescook: you'll love the new cups' test suite, it's very rigorous (and it too me until 3 am to fix the bugs that it caught :) )
<YokoZar> pitti: looks like we might need to add another package to ia32-libs https://bugs.edge.launchpad.net/ubuntu/+source/ia32-libs/+bug/210572
<ubotu> Launchpad bug 210572 in ia32-libs "No sound in wine under amd_64" [Medium,New]
<beasty_> cjwatson: thanks i'll take a look at it
<tkamppeter> pitti, I have now reduced the fdi file for HPLIP to 10.5 kB, making space for one more package on the live CDs.
<tkamppeter> Thank you for the tip.
<pitti> tkamppeter: yay, with int_outof?
<pitti> great
<tkamppeter> I have tested it with my printers and it works. I have uploaded it to the Debian SVN of HPLIP and now I am test-building the package.
<tkamppeter> Yes, it is with int_outof now.
<beasty_> cjwatson: thanks it worked
<tkamppeter> pitti, I have now replaced my HPLIP 2.8.2-0ubuntu5 packages by new ones with the same name, containing the new script which generates the smaller fdi file. Please re-download and upload them into Hardy.
<pitti> tkamppeter: right, I'll do that
<pitti> tkamppeter: what was the URL again?
<laga> slangasek: did you have a change to talk to pitti or cjwatson about the priority of mythbuntu-diskless-client-builder for the alternate disk?
<slangasek> laga: ah, no
<slangasek> pitti, cjwatson: trying to get mythbuntu-diskless-client-builder installed by default on the mythbuntu alternate CDs; is setting Priority: standard on it in the archive a reasonable means of achieving this, or is that a Bad Idea?
<pitti> slangasek: do we even look at Priority:? I thought our way of doing that was to put it into the ship seed?
<slangasek> pitti: udebs don't go in the seed...
<pitti> erm, not ship, mythbuntu  desktop?
<slangasek> sorry, I guess I omitted that part
<slangasek> this is a udeb :)
<pitti> ah, udeb; no idea about that one, sorry; installer seed?
<ogra_cmpc_> seb128, now thats silly, the device is ignored if i have an fstab entry for /live/cow ... no matter what mtab says
<pitti> slangasek: AFAICS udebs are in the 'installer' seed
<slangasek> pitti: I'm pretty sure the alternate CD doesn't use seeds at install time
<pitti> right, they don't
<slangasek> pitti: this is about being able to get a udeb automatically installed in the installer environment
<pitti> slangasek: definitively cjwatson's domain now, I'm afraid
<ogra_cmpc_> seb128, i mean it helps me to work around on the classmate and i can cover that from the installer, but i really dont understand the logic here
<slangasek> unless Ubuntu d-i is different than Debian d-i, this is achievable by setting the Priority
<seb128> ogra_cmpc_: describe your usecase with an easy example and steps to trigger the bug in a bug report and I'll speak with upstream about it
<slangasek> pitti: well, I was first soliciting opinions on whether it would be sane to set a universe udeb to Priority: standard
<ogra_cmpc_> seb128, it might be because the dir is move mounted in intramfs ... i'll add a bug and work around it on the classmate in the way that works for now
<cjwatson> slangasek: hmm, no, Priority not a great idea because that could affect netboot images
<slangasek> cjwatson: ok, thought that might be the case
<slangasek> laga: that means we're back to trying to auto-select udebs for install using preseeding, I think; sorry
<cjwatson> though that was the solution we used for Edubuntu
<cjwatson> but it was problematic
<cjwatson> if it does nothing by default, then using Priority is OK, just ugly
<slangasek> right
<cjwatson> is using preseeding a problem?
<slangasek> I don't think so, it was just that setting priority was the first thing that had come to my mind
<cjwatson> i.e. 'd-i anna/choose_modules string mythbuntu-diskless-client-builder'
<laga> cjwatson: oh, i haven't tried that yet.
<cjwatson> I'm pretty confident that will work
<laga> i didn't know you had to tell d-i explicitly to install something.. i think i was told it would just work if i just preseeded debconf questions for the package itself
<laga> thanks, i'll try that asap
<cjwatson> ah, if so you were told wrongly I'm afraid
<pitti> tkamppeter: looks fine, uploaded
<laga> cjwatson: or i mistunderstood something, happens all the time :)
<cjwatson> namespacing of debconf questions is just a convention; d-i can't and doesn't rely on it to figure out where the questions come from
<cjwatson> for instance, most of the mirror/* questions are actually in the choose-mirror-bin udeb
<pitti> mvo: *nag* do you happen to have a dist-upgrade /etc diff -Nur somewhere? time's getting tight for fixing everything, I feel
<pitti> mjg59: hm, so what would you recommend that we do for bug 162654? revert the network module unloading in pm-utils, or add a /e/i/networking restart call?
<ubotu> Launchpad bug 162654 in pm-utils "networkmanager (0.6.5-0ubuntu16.7.10.0) needs to be restarted manually after suspend using pm-utils, while functioning correctly using acpi" [Undecided,In progress] https://launchpad.net/bugs/162654
<ogra_cmpc_> cjwatson, the optimal solution would have been to add the code from laga to ltsp-client-builder ... and just have switches ... something for intrepid ...
<laga> ogra_cmpc_: it'd be very nice to merge some of my stuff back. i'm still not keen on maintaining my own initramfs scripts for example :)
<ogra_cmpc_> yeah
<james_w> pitti: I think I have the fix you want now, it's attached to the bug report.
<james_w> https://bugs.launchpad.net/ubuntu/+source/ca-certificates/+bug/153625
<ubotu> Launchpad bug 153625 in ca-certificates "update-ca-certificates error. ca-certificates.crt empty (with pt_BR locale)" [High,In progress]
<james_w> pitti: do you want to look now, or shall I subscribe the sponsors and let you get to it in your own time.
<pitti> Keybuk: WDYT about https://bugs.edge.launchpad.net/ubuntu/+source/rhythmbox/+bug/62400/comments/15 ?
<ubotu> Launchpad bug 62400 in rhythmbox "Podcasts directory should be created when required" [Low,In progress]
<pitti> james_w: great! looking
<mok0> I suggest to remove gcalctool (a calculator claiming to be a calendar :-)) from hardy. It has a lot of serious unfixed bugs associated with it; yet a desktop calculator is an important item on the desktop! We can't ship hardy with a calculator that doesn't work
<mok0> https://edge.launchpad.net/gcalctool/
<pitti> james_w: that's thorough analysis and testing! *hug*
<james_w> \o/
<pitti> james_w: the patch looks good to me; maybe cjwatson can also have a look, just to get more eyes on it?
<james_w> now to do it for several previous releases :-)
<mjg59> pitti: I'll look into it later today
<pitti> mjg59: thanks
<james_w> more eyes would be good, I'd especially like the preseed thing confirming
<pitti> james_w: that should just be changing the $fixed_version thing, right?
<mjg59> pitti: Though, argh. Why are people suspending machines with static networking configuration?
<mvo> pitti: I look at it again after lunch, sorry
<pitti> james_w: (and the previous debconf template fix, of course)
 * pitti hugs mvo, thanks
<james_w> pitti: yep, but it's the testing part that takes the time
<pitti> mjg59: :/
<james_w> does anyone know a way to make pbuilder run a script for "login"?
<pitti> mjg59: I do it myself, though, since my secondary ethernet is a static configuration (my desktop acts as a router for laptop, etc.)
<pitti> james_w: maybe you don't want --login then, but --execute?
 * james_w hugs pitti 
<james_w> perfect, thanks.
<Keybuk> pitti: mdz's follow-up seems reasonable
<pitti> Keybuk: hmkay; I find that pretty unexpected when opening the prefs dialog TBH, but *shrug*
<pitti> mdz: ^
<Keybuk> which bit?
<pitti> popping up a dialog about creating a directory
<pitti> when opening the podcasts tab
<Keybuk> well, I wouldn't do that
<Keybuk> why can't it just have a default directory that it makes the first time it downloads a podcast?
<tkamppeter> pitti, thanks.
<pitti> Keybuk: GTK file/dir selector widget can't do nonexisting directories
<pitti> (good thing IMHO)
<Keybuk> but it has a non-existing one as the default, no?
<pitti> that's what it breaks on, AFAIUI
<pitti> (for me it just shows my home dir, need to try on a fresh profile)
<james_w> mok0: https://bugs.edge.launchpad.net/ubuntu/+source/gcalctool/ doesn't look too bad, are there things that should be given higher severity?
<james_w> or are there just a lot of unreported bugs?
<Keybuk> pitti: hmm, it seems set to just HOME by default now?
<pitti> Keybuk: right, here too (for a fresh user)
<pitti> just tried it
<ogra_cmpc_> lamont, do you happen to have any say about the debian build queue priority of hppa ?
<seb128_> pitti: what bug are you working on?
<pitti> seb128_: bug 62400
<ubotu> Launchpad bug 62400 in rhythmbox "Podcasts directory should be created when required" [Low,In progress] https://launchpad.net/bugs/62400
<cjwatson> james_w: quote $pt_BR_fixed_version (not required, but good habit); use [ test ] && [ test ] rather than [ test -a test ] (likewise); I think it would be a good idea to set seen=true at the top, rather than it being uninitialised in a few cases
<cjwatson> james_w: also, I don't think the language test is quite right
<james_w> cjwatson: what do you think the language test should be?
<cjwatson> james_w: I'm just trying to work it out :)
<mdz> pitti: agreed, it shouldn't do anything when you first open the dialog (that's the real bug)
<james_w> LC_ALL=pt_BR.UTF-8 was the way I could trigger it, there may be non-UTF-8 ones affected I assume
<cjwatson> james_w: testing LC_ALL is definitely wrong; LC_ALL might not be set, and yet you could still have LC_MESSAGES set
<cjwatson> james_w: but to get it right you have to test LANGUAGE too, and as you mention there are non-UTF-8 locales affected too
<james_w> cjwatson: just LC_MESSAGES doesn't trigger the bug in the first place in my testing
<cjwatson> james_w: you might have something else set that overrides it
<cjwatson> james_w: I'm trying to work out an entirely different test
<cjwatson> ideally, we would check for the actual failure condition
<james_w> LANGUAGE on it's own does trigger it though.
<cjwatson> the override system there is rather complicated and best implemented by hand only where absolutely necessary
<cjwatson> urgh, unfortunately we can't do better because there has been an intervening version that had correct pt_BR templates
<james_w> that's my fault
<cjwatson> if that hadn't been the case, we could have shipped some code in the .config (or .preinst? haven't thought about it) that did db_metaget ca-certificates/enable_crts Choices && [ -z "$RET" ]
<james_w> we can do that for the SRU can we?
<cjwatson> oh, no, that isn't true either, because dpkg-preconfigure loads the new templates before calling any maintainer scripts
<cjwatson> drat
<cjwatson> ok, I guess we have to implement the environment variables in toto
<cjwatson> ideally, we would ask debconf for the language it thinks we're using, or have a shell binding for setlocale(), but I don't think either of those exist
<cjwatson> james_w: http://paste.ubuntu.com/6356/ is the best I can do
<cjwatson> james_w: it's still wrong in at least these situations: (1) you have LANGUAGE=ll:pt_BR but there's no translation of those templates in ll so debconf falls back to pt_BR (2) pt_BR<something> is set in the environment but that locale is not actually configured so is not used
<cjwatson> but AFAICS there's nothing we can do about (1), while (2) is not very important in this case
<james_w> cjwatson: is this normal? http://paste.ubuntu.com/6357/
<james_w> if it is then my previous testing of this was incorrect.
<cjwatson> james_w: yes, if you don't have the pt_BR.UTF-8 locale generated (run 'sudo locale-gen pt_BR.UTF-8')
<cjwatson> james_w: or if you have LC_ALL=C
<james_w> I have the locale
<cjwatson> in fact you must have LC_ALL=C because if it's unset then you would see LC_ALL=
<james_w> ah, ok, it's set by default to C, at least in my pbuilder environment
<james_w> ah, I get your function now, it seems right to me.
<mok0> james_w: It's the severity of the bugs I am concerned about. Last time I tested the app it didn't work correctly at all.
<james_w> mok0: well there's nothing High or above in the above source package list.
<mok0> james_w: why is that? I think it's severe if the calculator gives the wrong (or not-understandable) results
<dholbach> thekorn, bdmurray: is a new upload of pylpbugs planned anytime soon?
<james_w> cjwatson: as for the other comments I'll fix them, but seen is a variable I have re-used, so it is set further up.
<james_w> I realise it's not in the diff
<james_w> mok0: I'm not sure, maybe they just haven't been triaged?
<emgent> dholbach: i should complete anteater (tool for ubuntu-whitehat team) with pylbugs support. you have some docs about it ?
<james_w> mok0: although some where the summary suggests wrong results are set to Low.
<mok0> james_w: I am not at my Ubuntu desktop atm so I can't test it now
<dholbach> emgent: http://wiki.ubuntu.com/BugHelper has some and "pydoc launchpadbugs" should have some too
<cjwatson> james_w: oh, ok
<emgent> dholbach: ok thanks
<mok0> james_w: a desktop calculator is likely to be pulled out by casual and first time users. It is crucial that it works correctly. Imagine a reviewer getting wrong results, I would reflect badly on Hardy
<mok0> s/I would/it would/
<mok0> james_w: hehe, with my new-earned powers I can change the Importance of the bug :-)
<james_w> mok0: true. I was just reflecting that the bugs page didn't reflect the concerns that you were having, so it's hard to know what's going on.
<mok0> james_w: I am afraid many bugs get a superficial treatment partly as a result of karma-hunting members of the 5-a-day team (sorry dholbach)
<seb128_> mok0: do you have some examples?
<mok0> err... gcalctool?
<mok0> :)
<dholbach> mok0: that's a general bug triage problem we had with Launchpad Bug Karma before - I agree with you that it'd be good to have some kind of solution for it
<dholbach> maybe we should disucss it on ubuntu-bugsquad@
<seb128_> mok0: there is no abuse there, do you have a bug number where you had an issue?
<mok0> bug 208260
<ubotu> Launchpad bug 208260 in gcalctool "Too many commas in gcalctool" [Low,Triaged] https://launchpad.net/bugs/208260
<james_w> mok0: these don't appeared to have been triaged by 5-a-day people, and don't seem at all superficial.
<seb128_> mok0: I'm reading most of the desktop bugs and didn't notice wrong comments or triaging
<mok0> bug 198250
<ubotu> Launchpad bug 198250 in gcalctool "Calculator uses 06 in place of decimal" [Undecided,Fix released] https://launchpad.net/bugs/198250
<seb128_> that one has been sent upstream, fixed and the fix has been confirmed
<seb128_> what is wrong with the handling it got?
<mjg59> Yeah, 208260 really shouldn't be low
<mok0> seb128_: I don't see a fix has been issued?
<seb128_> mok0: 198250? It's closed
<mok0> seb128_: right, I see it now
<seb128_> mjg59: well, it's not high neither seems it seems to be specific to a locale
<seb128_> and that's not a major application
<mjg59> seb128_: Well, it seems to be failing in en_GB
<mjg59> seb128_: It may not be a major application, but it /does/ make the application basically unusable under common locales
<mok0> All this makes me feel gcalctool is a shoddy app
<seb128_> mok0: "all this" = 1 bug?
<seb128_> mjg59: agreed it should be fixed, but what it lacks now is not settings tweaking but somebody looking at the bug and writting a patch for the issue
<mok0> seb128_: I am looking at the number of serious bugs on gcalctools bug page
<asac> smurf: there?
<mjg59> seb128_: The point of priorities is surely to inform people as to which bugs need patches writing more urgently?
<seb128_> mok0: there is only 16 bugs on launchpad
<Keybuk> cjwatson: around?
<asac> smurf: could you approve me to the german translators team so i can approve firefox/xulrunner suggestions?
<cjwatson> Keybuk: yep
<mok0> seb128_: "calculator not working", "... problems with big sums", "too many commas" ... etc
<asac> smurf: i applied already. thanks
<seb128_> mjg59: right, but we have lot of other issues at the moment and as said that's only the calculator
<mok0> mjg59: But are the priorities always correctly set?
<mjg59> seb128_: I was under the impression that priorities related to the package, not to the distribution?
<seb128_> it's not clear to me
<mok0> mjg59: I interpret it as relating to the bug
<laga> smurf: while you're at it? can you please approve me to the german translators team as well? i'd like to translate some of my apps ;)
<mjg59> As in, this is a high priority bug for gcalctool (even if not a high priority bug for the distribution)
<seb128_> mjg59: I do concern the priority as being for ubuntu
<seb128_> s/concern/consider
<mok0> mjg59: a wrong result is clearly a more severe bug than no color or buttons
<mok0> s/or/on
<seb128_> mjg59: well, that's the ubuntu bug tracker not the upstream one
 * mvo wonders if adding a upstream task with high prioriy is the best solution for this and a distro task with e.g. medium
<mjg59> seb128_: But that renders the priority field effectively meaningless when relating to packages in universe
<seb128_> mjg59: I consider the importance of the issue for ubuntu as a whole, not for the specific package
<afflux> calc: may I ask why you closed bug 122976 some time ago? bug 198083 seems to be the same issue.
<ubotu> Launchpad bug 122976 in openoffice.org "package openoffice.org-style-human 2.2.1-2ubuntu1 failed to install/upgrade: dependency problems - leaving unconfigured" [Undecided,Invalid] https://launchpad.net/bugs/122976
<ubotu> Launchpad bug 198083 in ubuntu "Error on Update" [Medium,Incomplete] https://launchpad.net/bugs/198083
<seb128_> mjg59: I don't say I'm right there but that's how I use launchpad right now
<Keybuk> cjwatson: err, let's take this to a less busy channel? #udev ?
<Keybuk> mvo: could you pop in too
<seb128_> mjg59: otherwise we would have hundred of critical bugs and it would be hard to know what to fix in priority for hardy
<cjwatson> Keybuk: sure
<seb128_> mjg59: I consider gnome-settings-daemon crashing a higher priority that gcalcool being buggy for ubuntu
<mok0> seb128_: that's true
<mok0> seb128_: but still, the desktop calculator often gives the first impression for a casual users
<seb128_> mok0: well, as said if gnome-settings-daemon crash you will have a first impression before opening any calculator
<mok0> seb128_: I agree. Perhaps there should be an effect category too for bugs: "effects other programs", "effects usability", "effects user experience" etc.
<seb128_> mok0: the way we work for desktop bugs right now is to milestone things that should be considered for hardy
<mok0> seb128_: ... and the bug triager could click on one or several of those
<seb128_> so this one would be a low importance milestoned for hardy
<seb128_> ie, the world is not going to break if it's not fixed but it should be considered
<mok0> seb128_: ok, I understand
<seb128_> especially that I don't get this issue
<seb128_> so it's locale specific or something
<mok0> seb128_: yes that's very likely
<seb128_> and the bug has not been opened using apport so it lacks informations
<seb128_> ie, the locale used
<mjg59> seb128_: As I said, it's visible under en_GB
<seb128_> mjg59, mok0: did you guys activate the "show thousand separator" option?
<mjg59> seb128_: Does French even use a separator?
<mjg59> seb128_: I don't recall doing so deliberately, but yes, it is activated
<mok0> seb128_: I am not on my desktop atm, so I can't test the most recent version, but yes, I did try that some days ago
<seb128_> ok
<mok0> My locale is "C" :-)
<seb128_> so it's an issue for people activating this option under locales have a thousand separator apparently
<mjg59> seb128_: Unsurprisingly, without it there isn't an issue
<james_w> pitti, cjwatson: https://bugs.launchpad.net/ubuntu/+source/ca-certificates/+bug/153625 updated. Thanks for the comments.
<ubotu> Launchpad bug 153625 in ca-certificates "update-ca-certificates error. ca-certificates.crt empty (with pt_BR locale)" [High,In progress]
<lamont> ogra_cmpc_: I happen to have 2 buildds that I need to finish getting online...
<lamont> (re hppa/debian
<lamont> but I'm not planning to shuffle any build priorities
<ogra_cmpc_> lamont, ah, i rather meant in the debian infrastructure
<lamont> I run the debian buildds for hppa.  I have the ability to drag something into "next up" status
<ogra_cmpc_> ah
<ogra_cmpc_> thats what i wanted to know, but you gave a statement about shuffluing already :) thanks
<lamont> yeah - we had one die, and the priority for builds is to get -security done first once I get the two new ones online
<lamont> so what does it mean and how do I fix it when plugging in a USB drive gets me:  Cannot mount volume.  Error org.freedesktop.DBus.Error.AccessDenied ??
<ogra_cmpc_> you are not in the plugdev group ? or consolekit doesnt like you at all
<ogra_cmpc_> lamont, how did you start your x session ? DM or startx
<lamont> DM, I assume
<lamont> it's on vt7 or 9 or whereever hardy likes it
<ogra_cmpc_> what does ck-list-sessions show ?
<lamont> ck-list-sessions
<lamont> ** (ck-list-sessions:32282): WARNING **: Failed to get list of seats: Failed to execute program /usr/lib/dbus-1.0/dbus-daemon-launch-helper: Success
<lamont> I _LOVE_ that error
<pitti> james_w, cjwatson: language test> locale |grep LC_MESSAGES is the most robust test I can think of
<Riddell> pitti: could you give back qtnx?
<lamont> -rwsr-xr-- 1 root messagebus 228628 2008-02-29 02:23 /usr/lib/dbus-1.0/dbus-daemon-launch-helper
<pitti> Riddell: done
<lamont> ogra_cmpc_: I wonder if it being mode 4754 has anything to do with it...
<Riddell> thanks
<ogra_cmpc_> lamont, no, that looks about right
<lamont> OTOH, making it 4755 doesn't fix anything - it just makes ck-list-sessions successfully print nothing
<cjwatson> pitti: I looked at that but didn't feel like sedding it out
<cjwatson> but I guess that would work too; however, you still need the LANGUAGE check
<cjwatson> $ LANGUAGE=de locale | grep LC_MESSAGES
<cjwatson> LC_MESSAGES="en_GB.UTF-8"
<pitti> cjwatson: LANGUAGE is not related to gettext, it's a GNOMEism AFAICS
<pitti> so, LANG should work
<lamont> ogra_cmpc_: it's quite possible that I have gid/uid matching issues, although I expect not (nsswitch.conf used to point at ldap)
<ogra_cmpc_> lamont, hmm consolekit maintans all ACLs for the desktop nowadays
<ogra_cmpc_> if ck-list-sessions doesnt list anything thats your basic prob
<lamont> ogra_cmpc_: ah, ok.  so how do I fix0r that?
<ogra_cmpc_> http://paste.ubuntu.com/6359/
<ogra_cmpc_> you should see something like that
<ogra_cmpc_> lamont, gdm should have set the session for you in CK, is your gdm outdated ?
<\sh> lamont: hey...did you get the mail from loic because of adding lpia arch to p-a-s for wine? :) what do you think?
<lamont> gdm 2.20.4-0ubuntu2
<cjwatson> pitti: LANGUAGE is *not* a GNOMEIsm
<cjwatson> ism
<cjwatson> pitti: you'll find documentation on LANGUAGE in 'info gettext'; furthermore, even if it weren't in gettext, debconf cares about it
<lamont> cjwatson: man locale doesn't know about it
<ogra_cmpc_> lamont, hmm, mine here is even older ...
<cjwatson> lamont: *shrug*
<cjwatson> lamont: fact is, it's in gettext
<lamont> ogra_cmpc_: recent changes to the system: 1) upgrade-manager love to hardy-beta, 2) drop ldap from nsswitch.conf
<lamont> cjwatson: yeah.
<ogra_cmpc_> dpkg -l policykit|grep ii
<cjwatson> lamont: also in locale(7)
<cjwatson> "The GNU gettext family of functions also obey the environment variable LANGUAGE."
<lamont> ogra_cmpc_: 0.7-2ubuntu4
<ogra_cmpc_> hmm
<ogra_cmpc_> looks all fine
<ogra_cmpc_> weird
<afflux> does the live CD warn the user that he has not enough RAM (ie. 256mb)?
<cjwatson> no
<cjwatson> bug open
<afflux> cjwatson: was that targeted to me?
<cjwatson> sorry, I mean there already is a bug open somewhere about it
<cjwatson> afflux: yes
<afflux> ah, right. against ubiquity I guess? bug 162664 looks like it's a dup then.
<ubotu> Launchpad bug 162664 in vlc "no video output module play nice with Compiz" [Undecided,New] https://launchpad.net/bugs/162664
<afflux> err
<afflux> no
<cjwatson> afflux: ubiquity would be wrong; casper or gfxboot-theme-ubuntu
<afflux> okay
<afflux> I meant bug 208365
<ubotu> Launchpad bug 208365 in gnome-settings-daemon "There was an error starting the GNOME Settings Daemon (timeout?)" [Undecided,Confirmed] https://launchpad.net/bugs/208365
<lamont> ogra_cmpc_: so where do I go from here?
<ogra_cmpc_> lamont, there is a gui in System->Administration->Authorizations ... in the freedesktop/hal/strorage branch of that tree you can check the permissions
<cjwatson> afflux: having a warning at the boot menu level would not excuse applications from the responsibility of dealing correctly with out-of-memory errors
<ogra_cmpc_> usually mount and umount should be allowed for local users
<cjwatson> afflux: those could happen in situations other than the live CD
<ogra_cmpc_> oh, wait, your prob will lie deeper
<lamont> implicit auth: anyone = no.  explicit auth == $EMPTY
<ogra_cmpc_> pitti, any idea why lamont doesnt get a CK session ?
<ogra_cmpc_> (on a freshly upgraded system it seems)
<cjwatson> would anyone like to code-review http://paste.ubuntu.com/6360/ for me? This is an initial attempt at bug 8497, and will only work if you supply edd=on at boot
<pitti> re from phone call
<ogra_cmpc_> i dont see why it wouldnt register a session, all bits and pieces seem to be where they belong
<ubotu> Launchpad bug 8497 in grub "grub guessed BIOS disk order incorrectly" [Medium,Confirmed] https://launchpad.net/bugs/8497
<cjwatson> I haven't even compiled this yet, let alone tested it; just want to get some early eyes
<pitti> cjwatson: thanks for the review
<pitti> ogra_cmpc_: no?
<cjwatson> edd> the idea is that this won't affect normal installs at all (risky!), but if people have trouble getting grub to see their disks in the right order, they can try booting with edd=on and we'll opportunistically use the information
<cjwatson> in the knowledge that BIOSes can return partial or broken information, or that two identical disks out of the factory may well have identical MBR signatures, though, I had to program very defensively
<james_w> afflux: https://bugs.launchpad.net/ubuntu/+source/gnome-settings-daemon/+bug/204821 looks familiar
<ubotu> Launchpad bug 204821 in gnome-settings-daemon "[hardy beta 1] GNOME Settings Deamon gives error when starting live CD" [Undecided,Incomplete]
<seb128_> james_w: that's likely a "too slow to boot and goes in dbus timeout"
<james_w> ah, ok
<afflux> seb128_: see also bug 208365, that's a low ram system (128mb)
<ubotu> Launchpad bug 208365 in gnome-settings-daemon "error starting g-s-d on systems with low memory" [Medium,Triaged] https://launchpad.net/bugs/208365
<seb128_> afflux: this bug is no a g-s-d one, dunno who changed it to triaged
<afflux> seb128_: I did so
<lamont> dear gnome.  please use a firefox window in the current workspace, rather than dragging that other window across 3 workspaces just to use it. kthx
<seb128_> afflux: why?
 * lamont chuckles at the bug list for consolekit... I bet at least _some_ of those are dupes
<seb128_> afflux: we already have this dbus change
<seb128_>     - debian/patches/81-session.conf-timeout.patch: Raise the service startup
<seb128_>       timeout from 25 to 60 seconds. It may be too short on the live CD with
<seb128_>       slow machines.
<afflux> seb128_: so? I'm sorry, I'm not very much in g-s-d startup stuff
<afflux> seb128_: sorry for setting this to triaged, it was more like "looks complete to me, let the dev's look at it"
 * lamont considers reinstalling apport
<seb128_> afflux: that is "confirmed"
<seb128_> well not really
<seb128_> in this case it's rather incomplete or invalid
<afflux> seb128_: I don't get your point
<pitti> Keybuk: with my latest comment on bug 62400, would you agree to removing the milestone and setting to wishlist?
<ubotu> Launchpad bug 62400 in rhythmbox "Podcasts directory should be created when required" [Low,In progress] https://launchpad.net/bugs/62400
<seb128_> afflux: this bug is of no use, it has no useful informations, no description about how to trigger it, etc
<ogra_cmpc_> afflux, also note that running g-s-d as root might be a very bad idea
<ogra_cmpc_> (your .xsession-errors show it was run via sudo)
<afflux> ogra_cmpc_: hm, right. Seems like he did that on his own.
<afflux> seb128_: okay, then please close it or request information, as you like.
<seb128_> afflux: will do
<afflux> thanks!
<seb128_> thank *you* for your work on it
<seb128_> those bugs are not easy
<Keybuk> pitti: it's "good enough" for now I think
<pitti> Keybuk: right
<lamont> bug 210792
<ubotu> Launchpad bug 210792 in consolekit "no sessions after logging in" [Undecided,New] https://launchpad.net/bugs/210792
<lamont> ogra_cmpc_: I grew tired. :-)
<ogra_cmpc_> lamont, yeah, no idea what causes this
<ion_> Argh. :-) Away nicks for the lose.
<\sh> ion_: more likely a dying desktop where totem told me: no I don't like: strace totem example.flv ,->
<\sh> and that means..disconnecting from my proxy
<ogra_cmpc_> just stop using dd to create .flv movies :P
<cjwatson> \sh: it's your proxy, so you can tell it to stop doing /nick \sh_away
<lamont> \sh: please
<\sh> cjwatson: yes...I'll do it this evening :(
 * ogra_cmpc_ curses that kernel panics on a classmate always have to end up in his garage ...
<pitti> cjwatson, james_w: can't the is_pt_BR() function be replaced with something like CUR_LOC=$(eval `locale`; echo $LC_MESSAGES) ?
 * ogra_cmpc_ goes to dig for the screwdriver
<cjwatson> pitti: no. see my comment about LANGUAGE.
<cjwatson> pitti: that does NOT match debconf's behaviour
<pitti> ah, I see
<cjwatson> but you could certainly reduce the LC_ALL/LC_MESSAGES/LANG part of it with something like your example
<pitti> but it would at least avoid reimplementing the LC_ALL -> LANG -> LC_MESSAGES priority
<pitti> yeah
<james_w> so, we could use pitti's suggestion to get those three, and the if $LC_MESSAGES or $LANGUAGE start with pt_BR then assume the user would have been affected?
<james_w> s/LC_MESSAGES/CUR_LOC
<pitti> james_w: oh, btw, your $LANGUAGE test is wrong, too
<pitti> since it does not match if you have LANGUAGE=de_DE:pt_BR:en_US or so
<pitti> and don't actually have de_DE configured
<james_w> pitti: yeah, but I don't think that's detectable is it?
<cjwatson> pitti: yes, but there's no real way to do better. I noted that in my comments above
<pitti> if debconf really implements locale choosing different from /usr/bin/locale, then we need to reimplement debconf's algorithm
<cjwatson> pitti: which is what I did
<cjwatson> and gave to james_w
<pitti> cjwatson: I agree, it's a pathological case, but if we look at $LANGUAGE at all, it should at least be correct?
<cjwatson> and is what you're now busy arguing with ;-)
<pitti> ok, thanks
<james_w> so, another alternative would be to ask debconf, for instance by doing something hacky like adding a new template and then using two known strings, one for pt_BR and one for the rest.
<cjwatson> I did the best that I believed was possible
<pitti> james_w: "ugh" :)
<james_w> pitti: yeah, I'd need a shower after doing it :-)
<cjwatson> james_w: better to add debconf/language to debconf itself, but I doubt you want to depend on a new debconf feature for an SRU
<james_w> nope, but we can simulate it with a template.
<cjwatson> vomit. but yes, theoretically. :)
<lamont> so when we introduce a change to a package whose debian maintainer is an ubuntu maintainer, we change the maintainer field so that he doesn't get any notifications of the change.  nice.
<cjwatson> lamont: notifications can be had on request through the PTS
<lamont> yeah
<cjwatson> derivatives keyword, IIRC
<lamont> debian's pts?
<cjwatson> yes
<cjwatson> and the maintainer field change you mention was by voted request from Debian
<lamont> oh, I understand... I just found certain humor(?) in finding that postfix had been uploaded
<mvo> pitti: here is a first diff for the server upgrade http://people.ubuntu.com/~mvo/automatic-upgrade-testing/kvm/profile/server/
<pitti> mvo: ooh
<mvo> more to come, takes a bit to generate this stuff
<pitti> mvo: pkgs.diff looks reasonable, yay
<mvo> yeah, need to filter out the deinstall lines
<pitti> oh, it still has the gutsy apt sources?
<mvo> pitti: it shouldn't, you most likely see the backup of sources.list
<pitti> etc/apt/sources.list.distUpgrade
<pitti> ah, that's the backup
<mvo> odd that the UUID in the fstab changed
<pitti> etc/cron.daily/find should probably disappear on upgrade
<mvo> I think that is relatead to a incorrect compare-version (see #210699)
<pitti> mvo: well, you probably reformatted the disk on fresh install?
<mvo> a second opinion on #210699 would be nice
<mvo> pitti: of course, stupid me :)
<pitti> hm, no ipv6 stuff in /etc/hosts for fresh install?
<pitti> mvo: is /etc/init.d/makedev an orphan? I don't see a corresponding 'deinstall' package in pgk.diff
<pitti> Keybuk: is the /etc/udev/rules.d/70-persistent-net.rules diff (at the very bottom) in http://people.ubuntu.com/~mvo/automatic-upgrade-testing/kvm/profile/server/etc.diff something to be concerned about?
<pitti> mvo: except for that ^, #210699, and the orphaned makedev stuff it actually looks surprisingly good )
<mvo> no idea about the ipv6, both base-images are generated with jeos-builder
<pitti> mvo: I wonder how it looks like with dapper; I just recently fixed some bad upgrade bugs, there might be more lurking
<mvo> yeah, lets see what ubuntu-desktop looks like, let me check the makedev stuff
 * pitti reads your bug (210699)
<jdstrand> mvo: this is a bit of a drive-by commnet-- but doesn't jeos-builder create a really stripped down version? wouldn't ubuntu-vm-builder be better? (though I don't know why jeos-builder would strip out ipv6)
<lamont> W: postfix source: build-depends-on-1-revision build-depends: libdb-dev (>= 4.6.19-1)
<lamont> Dear lintian.  Yes, that's absolutely correct.  kthx.
<lamont> since build-depending on multiple versions leads to build failures on crackful buildds with polluted chroots.
<mvo> jdstrand: I don't know about ubuntu-vm-builder, I can have a look. please note that the generate image is only used to be able to login and do more stuff (like installing ubuntu-desktop etc)
<mvo> jdstrand: its not perfect, the best solution for this would be to have a non-interactive d-i install
<mvo> but my scripts can't do that (yet?)
<jdstrand> mvo: ubuntu-vm-builder may get you really close to that
<jdstrand> mvo: you may want to talk to mathiaz-- I think he has it completely automated for server installs
<mvo> jdstrand: oh, sounds nice
<jdstrand> mvo: I use ubuntu-vm-builder/kvm/virt-clone for security updates and can get i386 and amd64 vms with multple vcpus-- works great
<jdstrand> mvo: but I don't use mathiaz' scripts, so it's not *totally* automated for me (yet)
<jdstrand> (but it's darn close)
<lamont> why did rmadison switch to defaulting to ubuntu?
<StevenK> Because
<soren> lamont: YEah, what StevenK said.
<lamont> well then fix the manpage
<StevenK> Because Colin and Matt asked me
<lamont>             debian or qa http://qa.debian.org/madison.php (the default)
<mvo> jdstrand: the script looks almost identical to what I use, was it just renamed at some point?
<lamont> Lying!
<soren> Because we fixed the "rmadison defaults to Debian even on UBuntu" bug. :)
 * StevenK deals ramdison.1.gz a penalty card
<jdstrand> mvo: I am not sure of it's history-- I believe ubuntu-vm-builder grew out of jeos-builder.  talk to soren and/or nijaba
 * lamont adds an rmadison alias right above umadison in his .bashrc
 * Hobbsee did that months ago :)
<soren> mvo, jdstrand: jeos-builder was renamed to ubuntu-vm-builder just before feature freeze.
<jdstrand> oh ha, well, don't I feel silly
<Hobbsee> only confusion is which one is which, when i'm sometimes on gutsy, sometimes on hardy.
 * soren hugs jdstrand 
 * jdstrand has only ever used ubuntu-vm-builder
 * lamont files a bug against devscripts so people don't forget to fix0r the manpage to match reality.
<jdstrand> mvo: still, my comment about mathiaz' work stands, even if I don't know what I'm talking about with jeos-builder ;)
<mvo> :)
<mvo> thanks for the info, I'm too busy before the release, but its definitely something worth exploring
<lamont> there.  bug 152424 reopened. :-)
<ubotu> Launchpad bug 152424 in devscripts "rmadision should default to 'ubuntu' URL when under Ubuntu." [Wishlist,Confirmed] https://launchpad.net/bugs/152424
<lamont> interesting... it accepts short hand for the URL as well
 * lamont wonders if he should complain about dput being totally ugly in screen
<lamont> I mean, there is a certain amount of humor in lines starting at column -5 or so.
<lamont> as in 5 chars before end-of-line on the previous line
<mvo> pitti: makedev looks like it does not clean up the old /etc/init.d/makedev conffile
<pitti> ah, and update-rc.d -f
<pitti> is it only me, or do other people have a broken gnome-screensaver after suspend, too? (it doesn't accept my password, I have to "change user" and log in there)
<pitti> mvo: wow; for the first time ever, logging into my laptop (compiz) restored my terminals properly \o/
<wasabi> I've had similar things, but they were related to winbind dying on suspend (or randomlly as the day goes by)
<seb128> pitti: must be a bug
<seb128> ;-)
<pitti> seb128: the compiz session one? yeah, definitively
<pitti> don't you EVER touch that again!!!111!!! :)
<pitti> s/you//
<james_w> pitti, cjwatson: I've uploaded pitti's suggestion as well to the bug. If I can have an ack on one of the approaches then I will move forward with the SRU work. If you're busy please say so and I'll move on to something else.
<pitti> james_w: I have a phone call now, can do afterwards
<james_w> thanks
<pitti> james_w: thanks to you! (ugh, that turned out to be much harder than it seemed on first look)
<cjwatson> lamont: sounds like you misunderstood that lintian warning, from your description; did you read the lintian-info output for it?
<pitti> seb128, mvo: compiz session: ah, nevermind; I rebooted, it's broken again
<pitti> seems that a session start with hot cache gets it right, a cold start doesn't
<lamont> cjwatson: ah, ok.
<lamont> maybe I should fix that
<lamont> otoh, there would be great humor in a backport of libdb 4.6 :-)
<cjwatson> james_w: I'm OK with pitti's, though I'd suggest echo $LC_MESSAGES -> echo "$LC_MESSAGES" for style (doesn't actually make a difference in this case)
<jdong> lamont: you're a day late for backport humor ;-)
<lamont> jdong: that's in ref to W: postfix source: build-depends-on-1-revision build-depends: libdb-dev (>= 4.6.19-1)
<lamont> and the fact that lintian wants ">> 4.6.19" instead
<jdong> lamont: grumble am I too  loose or is that really pedantic of lintian?
<lamont> jdong: "breaks backports" :-)
<james_w> cjwatson: done, thanks.
<dneary> sabdfl: Ping?
<mvo> pitti: could you please have a quick look at http://paste.ubuntu.com/6361/
<pitti> mvo: ah, looks fine to me; thanks!
<mvo> great, uploading
<pitti> mvo: if that cleans it up properly, fine
<mvo> does so in my local tests at least :)
<mvo> I will run the upgrade test when it enter the archive again to verify the fix
<dneary> No sign of Jono today?
<jpatrick> dneary: he's in -locoteams right now
<jpatrick> dneary: ok, ~10 minutes ago, last message
<dneary> jpatrick: Thanks
<jpatrick> dneary: pinged him.
<dneary> Thanks
<lamont> jdstrand: what's this mean:
<lamont> Apr  2 08:01:45 mix kernel: [37412.728264] audit(1207144905.043:16): operation="file_mmap" request_mask="mr::" denied_mask="m::" name="/var/lib/misc/group.db" pid=7152 profile="/usr/sbin/cupsd" namespace="default"
<jdstrand> lamont: 'm' is for 'memory map as executable'.  this is usually only needed for binaries
<jdstrand> lamont: is this on i386 per chance?
<lamont> yep
<jdstrand> lamont: slapd had a similar problem on i386
 * jdstrand goes to find the bug
<pitti> james_w: latest patch looks good to me
<pitti> james_w: shall I sponsor it?
<lamont> cupsys 1.3.6-3ubuntu1
<jdong> jdstrand: why do many apps want m on files that seem like they should only be reading?
<jdstrand> lamont: bug #202161
<ubotu> Launchpad bug 202161 in apparmor "apparmor broken after reboot on i386" [Undecided,New] https://launchpad.net/bugs/202161
<james_w> pitti: that's your call :-)
<jdstrand> jdong: ^^
<pitti> james_w: ok, doing
<james_w> pitti: I didn't give it the thorough testing that the other one got, but I have tested a couple of the scenarios
<jdstrand> lamont: would you mind adding your log entry to that bug?
<james_w> pitti: thanks.
<pitti> james_w: uploaded; thanks a lot!
<lamont> jdstrand: added
<jdstrand> jdong: it *might* be an arch thing, but keescook is talking to upstream about it
<jdstrand> lamont: thanks
<jdong> jdstrand: interesting. I've just been noticing like, for example, it seems like Skype wants m on next to everything
<james_w> pitti: thanks for the help.
<jdong> jdstrand: does m carry any security implications that r does not?
 * lamont notes that bind9 and postfix will want syncs after today's dinstall run
<jdstrand> jdong: m is equivalent to 'ix'-- execute under the current profile
<jdstrand> jdong: when you specify 'm', you are really saying "yes, you can execute this file"
<jdstrand> jdong: so yes, there is a difference
<jdstrand> jdong: but remember that apparmor is supplemental to unix perms, so if the file isn't executable there, it won't be executable just cause 'm' was used in apparmor
<lamont> jdstrand: so WTH is it asking for exec perms?
<jdstrand> lamont: yes, that is the question
<jdstrand> lamont: keescook is talking to upstream about it
<jdstrand> so far it seems to be i386 only
<tkamppeter> pitti, hi
<tkamppeter> pitti, hi
<bryce> BenC: could you let amd know that colin and I are trying to connect to the conf call but it's not responding to the access code
<keescook> jdstrand, lamont, jdong: I'm lacking a bit of context, but the AppArmor "m" is for "mmap".
<keescook> for .so files this means it can load and run it.
<keescook> presently our executables aren't PIE so this won't work for running them.  :P
<lamont> keescook: and for /var/lib/misc/group.db, it would be executing it why?
<jdong> keescook: what lamont and I are seeing are apps seemingly requesting mmap on textual/data/config type files
<mvo> pitti: http://people.ubuntu.com/~mvo/automatic-upgrade-testing/kvm/profile/ubuntu/
<jdong> we're wondering why that happens
<pitti> hi tkamppeter
<pitti> hey keescook, good morning
<pitti> mvo: ooh
<pitti> argh, phone
<mvo> pitti: running lts-ubuntu next
<jdstrand> keescook: it is that slapd/i386 bug
<jdstrand> keescook: except lamont found it with cupsys/i386
<jdstrand> keescook: and updated the bug report
<lamont> keescook: oh, and good morning. :-)
<jdstrand> hi keescook!
<pitti> mvo: ugh, 1.5 MB /etc diff?
<keescook> morning!  :)
<keescook> pitti: yeah, saw the notes, the cupsys tests sound great :)
<keescook> jdong, lamont, jdstrand: it's not that it's trying to exec it -- it's just trying to mmap the file (generally to read it faster, etc)
<keescook> that said, it still may be a AA bug
<jdstrand> keescook: yes, but having 'm' means that it can exec it
<Keybuk> BenC: ping?
<keescook> that's true, but why is that a big problem?
<mvo> pitti: fun!
<jdstrand> it isn't a problem on it's own, but it is odd that it only happens on i386
<jdstrand> keescook: ^ and we may see these types of bug reports and failures on i386 when the profile is 'correct'
<keescook> jdstrand: yeah, I will re-ping upstream about it.  having a stand-alone test case would be nice, but I realize that's the _problem_.  :P
<lamont> and if it doesn't want to actually exec the file, it should be mounting it without exec, no?
<BenC> Keybuk: ?
<Keybuk> BenC: I did not realise you were going to do a udev upload
<Keybuk> so I think we just had a mid-air collision
<BenC> Keybuk: woops...how unlikely, hehe
<Keybuk> and without checking the debdiff, given you didn't get the version number right, I'm a little concerned you didn't get the rules file migration right
<Keybuk> what did you change to move that rules file?
<BenC> Keybuk: version number?
<BenC> I went from -4ubuntu1 to -4ubuntu2
<Keybuk> BenC: our udev packages aren't XubuntuY, we maintain them ourselves natively so they-re just -X
<Keybuk> yes, mvo mucked up the last one; yours should have been -5
<BenC> Keybuk: Oh, then blame dch and mvo for being misleading :)
<Keybuk> what did you change to move that rules file?
<BenC> Keybuk: I Changed the dh_install command to copy it to 66- instead of 65-
<BenC> in debian/rules
<keescook> lamont: it's trying to just call mmap() on it
<Keybuk> BenC: so now people will have two copies? :)
<lamont> keescook: ah, ok
<Keybuk> and will get update-initramfs errors because of the missing file? :)
<lamont> I thought mmap could specify
<BenC> Keybuk: true, but the first one wont cause any problems :)
<BenC> since it never gets run
<lamont> OTOH, it's not like I've actually looked at mmap() recently
<Keybuk> BenC: why doesn't it get run?
<BenC> Keybuk: it gets run, but it has to come _after_ persistent-storage.rules, else the env is setup enough
<BenC> Keybuk: udev initially has it right (60-persistent-storage and 61-persistent-storage-edd
<BenC> )
<Keybuk> persistent-storage-edd will come after persistent-storage
<BenC> Keybuk: it's been installed on Ubuntu as both 65
<Keybuk> it's alphabetically greater
<BenC> Keybuk: It doesn't seem to DTRT then...moving it to 66- makes it work, and I tested that
<Keybuk> that's worth knowing
<BenC> Keybuk: boot with edd=on and you will see nothing for /dev/disk/by-id/edd-*
<BenC> Keybuk: Unless you move that file
<BenC> Keybuk: considering udev upstream has it as 60/61, and we had it as 65/65(and it didn't work), I believe someone figured that out already :)
<Keybuk> heh
<Keybuk> yeah that's likely
<cjwatson> BenC: did you see the EDD grub hackery I was working on?
<Keybuk> it might be because it ends up between storage and storage-tape
<BenC> depending on alpha ordering makes little sense for this anyway
<Keybuk> wouldn't surprise me if a goto jumps from one to the other
<cjwatson> BenC: http://paste.ubuntu.com/6364/ is the current version
<Keybuk> BenC: err, by changing the number you're still depending on alpha ordering :p
<BenC> Keybuk: No, that's numeric ordering :P
<Keybuk> BenC: done by sort() :p
<Keybuk> udev is noway near intelligent enough to try and parse the filenames ;)
<BenC> Well the storage{-,.} sorting is a little ambiguous for me
<jdstrand> pitti: do you know off-hand of a way to test cups browsing via the command line or it's web interface?
<cjwatson> BenC: if you have a spare system with multiple disks that you've booted with edd=on, I could do with a run of an instrumented version to make sure I'm getting it right
<cjwatson> the reordering code is a bit hairy
<pitti> jdstrand: you need another cups on a second machine for that
<BenC> cjwatson: Hmm, I could check it out...but I don't know if I have a multi-disk setup to test
<pitti> jdstrand: you enable browsing on one, sharing on the other host (easiest with the web UI or system-config-printer, or change it in cupsd.conf and force-reload), then check with lpstat -p whether you see the printer
<jdstrand> pitti: ok thanks
<cjwatson> BenC: I've tested it on a single-disk system, but that's a bit trivial :)
<cjwatson> I have a two-disk system, but I don't know if it supports EDD and it's my server so I don't really want to reboot it to find out
<keescook> lamont: on reboot, does /var/lib/misc/group.db exist already?
<cjwatson> BenC: I'd welcome code review, at any rate
<soren> cjwatson: When I'm done with my meeting I can do a quick reboot. I have 3 disks in my workstations and it's fairly recent, so chances are good :)
<lamont> yes
<lamont> keescook: yes
<BenC> cjwatson: ok
<mvo> pitti: looks like most of the diff is bt* in /etc/alternative
<cjwatson> soren: let me come up with an instrumented version for you, then
<BenC> Keybuk: are you following up on udev?
<soren> cjwatson: Cool. I'm on amd64, by the way.
<cjwatson> I was going to give you source
<Keybuk> BenC: yup
<Keybuk> BenC: merged your changes with mine
<BenC> Keybuk: thanks
<keescook> ogasawara_: weather report> any way to split up the failed package builds metric by architecture?
<ogasawara_> keescook:  yup, I've got it on my todo list
<cjwatson> soren: OK, apply debdiff from http://paste.ubuntu.com/6365/plain/
<keescook> ogasawara_: sweet
<cjwatson> soren: with that grub installed, I'd like you to run 'rm -f device.map.test; echo quit | grub --batch --device-map=device.map.test; cat device.map.test' and send me the output
<cjwatson> should be some instrumentation on stderr
<soren> cjwatson: I still need to reboot with edd=on, right?
<cjwatson> soren: right
<soren> cjwatson: Or do you want before and after?
<cjwatson> no, I know what it'll do before
<cjwatson> well
<cjwatson> actually, I guess the ordering before is vaguely interesting
<soren> Alright.
<cjwatson> more interested in the instrumentation though
<soren> cjwatson: Er... It just has my (non-existing) floppy drive now.
<soren> That seems rather suboptimal :)
<cjwatson> anything on stderr?
<soren> Nope.
<soren> http://pastebin.com/m4b28b1ad
<soren> cjwatson: Er... The same happens with the grub that's in hardy right now.
<keescook> lamont, slangasek: what do you think of the patch in bug 120015?  I think it looks sane, but wanted some other opinions.
<ubotu> Launchpad bug 120015 in shadow "useradd too slow with LDAP nsswitch" [Wishlist,Triaged] https://launchpad.net/bugs/120015
 * soren blushes
<soren> cjwatson: Runing it as root helps :)
<soren> cjwatson: Sorry for the scare there. :)
<cjwatson> heh
<jdstrand> pitti: I had the bright idea to run two cupsd processes on the local machine, with different cupsd.conf (and browse.conf and ports.conf) files, but it seems that I can't configure cupsd to use something other than printers.conf-- do you know of a way to do this?
<pitti> jdstrand: the test suite runs the entire thing in /tmp/ as normal user; look at test/run-stp-tests.sh for how it configures that cupsd
<jdstrand> pitti: excellent, thanks
<cjwatson> seb128: I don't understand why you converted bug 210688 to a question; it seems like a legitimate bug report, and should either be addressed or marked invalid with an explanation, surely?
<ubotu> Launchpad bug 210688 in gcc-defaults "upgrade from feisty to gutsy tries to remove apt" [Undecided,Invalid] https://launchpad.net/bugs/210688
<seb128> cjwatson: I discussed with the submitter on #ubuntu-bugs this morning
<jdstrand> pitti: fyi, it'll take some finagling to get it going, but ServerRoot is what will do the trick
<jdstrand> pitti: this is all coming from writing a qa-regression-testing script for cupsys
<jdstrand> pitti: browsing is the last bit (for today). I'll let you know when I'm done and maybe you can comment on it sometime?
<seb128> cjwatson: but right, could have set the bug as incomplete or invalid rather
<jdstrand> (no rush)
<pitti> jdstrand: oh, rock; sure
<soren> cjwatson: http://pastebin.com/m70a3862a
<cjwatson> seb128: ah
<cjwatson> seb128: I didn't have that context, just getting the bugmail
<cjwatson> soren: whoopsie
<cjwatson> soren: can you gdb that and get me a backtace
<cjwatson> backtrace?
<soren> cjwatson: Yeah, working on it.
<seb128> cjwatson: I'll add a note saying that has been discussed on IRC next time ;-)
<cjwatson> soren: yours is an excellent test case since it actually does seem to need reordering
<cjwatson> and the BIOS doesn't seem to be able to get working EDD information for one of your drives, but two of them are fine
<cjwatson> which is actually OK, two out of three is all we need to construct a working ordering
<soren> cjwatson: http://pastebin.com/m64f740fc
<soren> cjwatson: I actually specifically bought this system for testing this. No kidding.
<soren> cjwatson: It had 2 SATA and 2 PATA disks in it to make it as error prone as possible.
<soren> (I've since yanked the one PATA disk for other purposes)
<cjwatson> ugh, well that's a horrible way for it to go wrong
<soren> cjwatson: Well, not for testing your patch, obviously, but for testing booting with interesting disk configurations.
<cjwatson> soren: 'print i' in gdb please?
<soren> print i
<soren> No symbol "i" in current context.
<soren> (gdb)
<cjwatson> soren: err, go up to frame 6 first
<soren> Erm.. how?
<cjwatson> 'up 6'
<soren> Heheh..
<soren> 135225248
<cjwatson> busted stakc
<cjwatson> stack
<cjwatson> could you try again, break on restore_device_map, and step through it?
<cjwatson> it might be easier if you did "make clean; sed -i 's/-O2/-O0/g' lib/Makefile; make" first
 * soren -> phone call
<cjwatson> oh, I have a guess
<cjwatson> soren: could you put this at the end of the move_device function? (sorry about the nested functions, seems to be grub style)
<cjwatson>         (*map)[0] = 0;
<cjwatson>         device_mbr_sig[0] = 0;
<cjwatson>         device_mbr_sig_avail[0] = 0;
<soren> Sure.
<cjwatson> that would cause a double free
<cjwatson> this code is rather "I have only proven it correct, not run it"
<Keybuk> cjwatson: I'd trust you've proven correct more than code I've run ;)
<soren> cjwatson: That didnt' seem to help.
<cjwatson> Keybuk: hmm, your confidence may be misplaced ;-)
<cjwatson> soren: OK, thanks; I'll get back to you tomorrow morning, have to go out now
<soren> cjwatson: Alrighty.
<soren> cjwatson: Ah, I think I know what's going on.
<soren> cjwatson: copy_device does a (*map)[dest] = (*map)[src];, so map has two indices pointing to the same memory chunk.
<soren> cjwatson: Simply adding a (*map)[src] = 0; after that line removes the double free, but only gives me (hd0) and (hd1) in my device.map.
<keescook> mvo, slangasek: is the "openssl prompts during upgrade" bug known already?
<keescook> (I see to remember seeing some discussion about it)
<keescook> *seem
<mvo> keescook: I'm not sure if we have a open bug about it, its not milestoned (but it should IMO)
<mvo> (its not milestoned if we have one)
<keescook> mvo: okay, I will open it
<keescook> mvo: ah, found it 182446
<keescook> bryce: say, the "Unknown" title in xrandrgui seems ominous.  What do you think of changing that to "Unnamed" or similar?
<bryce> it's Unknown in this case, because it's on a KVM switch which seems to be dropping the EDID info
<bryce> so 'Unknown' is indeed the correct terminology...  sorry if it sounds ominous
<bryce> fwiw, that's just my devel box; on all the other 9 systems I tested, it got the monitor's name correctly
<bryce> (of course, I cheated and made sure all my monitors were listed in the monitor database to begin with *grin*)
<slangasek> keescook: 120015> patch looks sane to me as well, so I'm surprised that's not already what adduser does
<keescook> slangasek: thanks for checking it.  I'll upload it.
<jeromeg> slangasek: hello
<slangasek> jeromeg: hi
<jeromeg> there seems to be a problem with the backported wesnoth in gutsy
<mario_limonciell> bryce, did you ping me at some point on something early this morning?
<bryce> ogasawara_: could you look into bug 151327?  It sounds like the kernel team fixed it, but we have one reporter saying it still does not work as of alpha 5.  It would be useful to have an update on that bug regarding what the kernel team did to fix it, and if it's still a known issue by them or believed to be fixed
<ubotu> Launchpad bug 151327 in linux-restricted-modules-2.6.24 "[Gutsy] binary graphics drivers don't load with Xen (2.6.22 and 2.6.24)" [Medium,Incomplete] https://launchpad.net/bugs/151327
<jeromeg> slangasek: the old version (1.2.8) is still in the repo
<bryce> mario_limonciell: I didn't ping you, but last night ogra_cmpc had some questions for you about openchrome
<slangasek> jeromeg: well, that indicates a build failure, then?
<ogasawara_> bryce:  I'll take a look
<mario_limonciell> bryce, ah.  ogra_cmpc what's up?
<jeromeg> slangasek: i seems to be a sync problem etween different repos, because everything is fine in some other repos
<jeromeg> *it
<slangasek> jeromeg: oh, no, it appears to be in NEW
<slangasek> jeromeg: er, everything should /not/ "be fine", the i386 binary hasn't been accepted out of NEW...
<jeromeg> oh ok
<jeromeg> slangasek: but i get :
<jeromeg>  wesnoth | 1:1.4-1~gutsy1 | http://archive.ubuntu.com gutsy-backports/universe Sources
<jeromeg> how can that be ?
<slangasek> are you not on i386?
<jeromeg> slangasek: i'm
<slangasek> oh, that's a sources line
<slangasek> the sources are there.  the binaries are not.
<jeromeg> oh right ;)
<jeromeg> sorry :)
<jeromeg> but this seems to have caused weird bugs for some persons
<bryce> brian, I'd love it if you could take another look at bug 181121.  Possibly the new driver fixes the crash for you
<ubotu> Launchpad bug 181121 in linux-restricted-modules-2.6.24 "[fglrx] glplanet crashed with SIGSEGV" [Undecided,Incomplete] https://launchpad.net/bugs/181121
<bryce> brian, no hurry, I'm just triaging through fglrx bugs (ATI has been asking about current ones)
<jeromeg> slangasek: it also seems that wesnoth-data has to be pushed
<slangasek> jeromeg: yes, that's all part of the i386 build.
<jeromeg> ok
<jeromeg> slangasek: you can do something to fix this ?
<slangasek> yes, it's already pushed out of NEW
<jeromeg> i think this would fix bug 209463
<ubotu> Launchpad bug 209463 in wesnoth "wesnoth in gutsy-backports does not have required dependency" [Undecided,Invalid] https://launchpad.net/bugs/209463
<jeromeg> slangasek: great, thank you !
<JohnPhys> If this is not the place to ask this question, I apologize.  Why does fontconfig now create symlinks in /etc/fonts/conf.d/ to some of the "10-*" files in /etc/fonts/conf.avail ?  This seems to cause issues such as bug # 190848 , and makes some apps (gnome-terminal, possibly qt apps) not respect the preferences set in the appearances -> fonts dialog.  On earlier installs (gutsy/feisty/etc) these links are not created, so
<mvo> pitti: http://people.ubuntu.com/~mvo/automatic-upgrade-testing/kvm/profile/lts-ubuntu/ (even bigger ./
<slangasek> fta: bug #192333 - the next obvious question is, when is beta 5 supposed to land? :)
<fta> bug 192333
<Keybuk> err
<Keybuk> my dpkg-fu must be waning
<Keybuk> if package A conflicts and replaces package B, doesn't that mean it can be installed and automatically remove the other
<Caesar> Err, the most recent nfs-utils upload seems to have dropped a pile of Ubuntu patches
<Caesar> Or should I be saying this in #ubuntu+1 ?
<fta> slangasek, soon. we have the branches ready, i'm checking a regression
<Caesar> I retract that, the Debian unstable upload that Ubuntu just merged has more patches removed than it should have
<elmo> Keybuk: I thought you need CRP for auto removal
<elmo> but my dpkg-fu is definitely waned
<Keybuk> apparently I did *and* --auto-deconfigure
<Keybuk> and maybe --force-everything --fuck-it --just-do-it-and-ill-pick-up-the-pieces-later
<Keybuk> we should just use rpm
<Mithrandir> Keybuk: C+R ought to be enough unless it's a virtual package in which P might be useful too.
<Keybuk> Mithrandir: it wasn't
<Mithrandir> Keybuk: paste?
<Keybuk> Mithrandir: lost the paste, will play again later
<slangasek> tjaalton: see Caesar's comments above?
<slangasek> Caesar: what patches went missing that hadn't been merged?
<Caesar> slangasek: at least 11-gssd-use-kernel-supported-enctypes.diff
<Caesar> Spectacular breakage for Kerberized NFS here
<Caesar> But the problem is the Debian package, although I will say a pile of Ubuntu changelogs fell out from the merge, not sure if that's supposed to happen or not when you merge from unstable
<slangasek> no, it's not
<Caesar> I didn't think so
<slangasek> was 11-gssd-use-kernel-supported-enctypes.diff ever in Debian? It's not mentioned in the changelog at all
<Caesar> Let me just check my facts
<Caesar> Okay, so 11-gssd-use-kernel-supported-enctypes.diff was in 1.1.1-12ubuntu4
<slangasek> tjaalton: where did all of the Ubuntu package history go when you merged nfs-utils?
<Caesar> It's not in 1.1.2-2ubuntu1
 * slangasek nods
<Caesar> slangasek: and there was no such patch in 1:1.1.1-14 in Debian
<Caesar> So I'm pretty sure that was an Ubuntu-specific patch, which got dropped
<Caesar> (it'd be nice to get it upstream, I suspect we've already filed it there though)
<slangasek> right; when tjaalton pops up, we should be able to have that sorted
<Caesar> I can provide a debdiff it'll help
<slangasek> that may, if you can file it in LP against nfs-utils
<Caesar> slangasek: yep
<Caesar> I'll look at doing that after I get my home directory back :-)
<slangasek> ok :)
<Caesar> hooray for downgrading
<Caesar> seb128: can we talk about #191512 in a little bit?
<seb128> bug #191512
<ubotu> Launchpad bug 191512 in gvfs "gnome displays nfs mounts on the desktop" [Low,New] https://launchpad.net/bugs/191512
<seb128> Caesar: sure
<Caesar> seb128: cool, let me fix nfs-utils, then pawalls and I can talk to you about that bug
<seb128> ok
<tjaalton> slangasek: dpkg-genchanges segfaulst
<tjaalton> -ts
<tjaalton> if there's something missing I'll add it back
<Mithrandir> tjaalton: dpkg-genchanges is written in perl, so that's thepthul.
<slangasek> tjaalton: see Caesar's comments above; at least one patch went missing, and it's hard to know what else might have regressed because none of the previous Ubuntu changelog entries were carried over
<tjaalton> slangasek: right, I'll check it out
<bryce> bdmurray: hey, how do you attach upstream bug reports to a package which has multiple upstreams?  I.e., I want to hook one of the fglrx bugs to its upstream ati bug tracker in linux-restricted-modules-2.6.24 (bug #196617)
<bdmurray> bryce: is the ati bug tracker registered in Launchpad?
<bryce> bdmurray, no
<tjaalton> slangasek: duh, that patch is from upstream but apparently not merged in 1.1.2 :/
<tjaalton> so I'll add it back. it's the only one that was added by us (me)
<bryce> heya tjaalton
<bdmurray> bryce: What's the bug tracker url?
<tjaalton> hi bryce
<bryce> e.g. http://ati.cchtml.com/show_bug.cgi?id=902
<bdmurray> Okay so that seems to be know to launchpad - https://launchpad.net/bugs/bugtrackers/ati-linux-bugs
<bryce> ahh there it is.  odd name
<bryce> hmm, I had searched for "ati" "amd" and "fglrx" but it didn't present that
<bdmurray> Well looking at it that tracker doesn't seem to have a project which might be required to add the bug watch now.
<bryce> could you set it to project 'fglrx'?
<bdmurray> bryce: do you mean an exisiting project?  I don't see one.
<Caesar> seb128: okay, we've got our act together
<Caesar> seb128: so we really need a solution to #191512
<Caesar> seb128: in an environment with autofs mounted NFS home directories, Nautilus is behaving really retardedly
<bryce> bdmurray: no...  well don't worry about it, I've closed the bug as invalid anyway
 * bryce shudders at the autofs mention
<Caesar> seb128: what happens is autofs will periodically try to unmount the user's home directory, and succeeds from time to time
<Caesar> seb128: then some user-process will cause it to be remounted
<Caesar> seb128: that unmount/remount cycle causes a *new* Nautilus window to pop up
<Caesar> seb128: so if that happens say a hundred times in a 24 hour period (or even overnight), the user comes back the next morning to a gazillion Nautilus windows for their $HOME
 * Caesar wonders if he was just talking to the wall
<Caesar> seb128_: how much of what I just said did you catch?
<seb128_> Caesar: nothing
 * Caesar sighs. Deeply.
<norsetto> LOL
<seb128_> Caesar: either you didn't use highlight or that was after the disconnect
<Caesar> seb128_: see PM
<seb128_> are you register?
<seb128_> I didn't get any query
<Caesar> seb128_: just pasted it
<seb128_> got it now
<seb128_> I don't know how automount works and how to configure it easily
<Caesar> seb128_: so I don't think you need to care
<seb128_> the mount issue could be https://bugs.launchpad.net/ubuntu/+source/gvfs/+bug/210468
<Caesar> seb128_: the problem from my ignorant point of view is not autofs/automount, it's gvfs
<tjaalton> Caesar: sorry for the nfs-utils goof, a new version on the way
<Caesar> tjaalton: thanks
<seb128_> Caesar: well, your description seems to describe several issues
<Caesar> seb128_: autofs unmounting idle automounts is normal behaviour as far as I know
<slangasek> seb128_: "unmounted again when not in use" is normal behavior for autofs.
<seb128_> Caesar: you could try to remove the trash applet and move gvfsd-trash somewhere else and see if you still get those incorrectly mounted
<Caesar> seb128_: that bug is not mine
<Caesar> Mine is the nautilus windows popping up ad nauseum
<seb128_> Caesar: well, you are saying that something is triggering the mount though no?
<Caesar> seb128_: IMO, there shouldn't even be a volume icon on the desktop for an NFS mounted $HOME
<slangasek> seb128_: no, he's saying that /when/ the homedir is mounted, it opens a new window and shouldn't
<Caesar> slangasek: thanks
<slangasek> homedir mounts coming and going is totally normal in an autofs env
<seb128_> slangasek:  13:10 < Caesar> seb128: then some user-process will cause it to be remounted
<seb128_> slangasek: he copied that to query
<slangasek> seb128_: yes - which it's perfectly well allowed to do :)
<Caesar> seb128_: I'm not complaining about the remount
<seb128_> ah ok, I though it was part of the issue
<seb128_> https://bugs.launchpad.net/ubuntu/+source/gvfs/+bug/210468 does
<Caesar> I'm complaining about the *behaviour* when it remounts
<seb128_> and seems to be valid as well
<slangasek> the only time the homedir is mounted is when it's being used; lots of things might use it periodically
<seb128_> weird that you don't get it
<Caesar> seb128_: you're conflating two bugs
<seb128_> no I'm not
<seb128_> I'm trying to have a view of all the issues we need to fix
<pawalls> seb128_, Here's the problem. /home/$USER gets shown as a new mount on the desktop by gvfs and it shouldn't.
<Caesar> seb128_: I'm not aware of us experiencing the problems described in #210468
<seb128_> I read about this bug and I'm surprised it doesn't happen in your case
<seb128_> well, all the media and home mounts are listed
<Caesar> seb128_: I've just grepped for "Trash" in a few days worth of syslog and can't find a mention
<seb128_> all the mounts in those directories rather
<Caesar> The problem in #210468 appears to be that it's looking in /net for stuff?
<seb128_> no
<seb128_> the trash code is using mtab to list mounts and not doing filtering
<seb128_> which is an another issue
<Caesar> ok
<seb128_> and those mounts are likely in mtab
<seb128_> though I've no such setup to confimr
<pawalls> seb128_, That's fine that things *relative* to /home/$USER are shown, but /home/$USER itself shouldn't be.
<pawalls> seb128_, Is that an unreasonable request?
<seb128_> pawalls: I don't think so, I need to talk to upstream about it though
<seb128_> pawalls: they might be usecase where you want to list other nfs mounts there
<pawalls> seb128_, Great! The problem also will make people sad if they use encrypted /home
<seb128_> why?
<pawalls> seb128_, Because they get an icon for their home directory on their desktop and it pops up a window.
<pawalls> also, if /home/$USER is a separate partition (eg. nfs, this happens)
<seb128_> well, you have different issues there
<seb128_> is the icon an issue
<pawalls> Is there a compelling reason to have a separate mount on the desktop for the user's home dir?
<Caesar> seb128_: I think the icon is a symptom of the issue
<pawalls> seb128_, It's a regression.
<seb128_> or only nautilus opening a view on it ?
<Caesar> I'd personally prefer not to see it
<pawalls> seb128_, And the regression *also* causes a separate window to pop up.
<pawalls> seb128_, Making the problem even worse.
<seb128_> if people could stop using "regression" every time there is a behaviour change
<seb128> that's not a regression
<seb128> that's a completly new stack
<seb128> and it has different design decisions
<pawalls> seb128, It's a change in behavior that introduces a poor user experience.
<Caesar> It's a behaviour change. Call it what you will.
<pawalls> Regression is shorter to type.
<seb128> no it's not
<seb128> it's a new stack behaving differently
<Caesar> Let's not debate semantics
<seb128> it's not a change in something which was used before
<pawalls> seb128, It's a change in user experience. Users with their home dir on a separate partition now get nautilus popping up and an icon on their desktop when they did not before.
<pawalls> It doesn't matter what underlying code has changed.
<pawalls> The end result is the same.
<Caesar> seb128: if it'll help, I can try to work on giving you a configuration so you can locally reproduce the behaviour, but it might require a fair bit of work and infrastructure on your side
<seb128> ok, let's not debate semantic
<seb128> but I start being annoyed about people calling behaviour change regression and argumenting that regression should be fixed right now
<seb128> anyway not the topic there
<pawalls> seb128, Sorry if I gave that impression.
<Caesar> seb128: I think that comes down to personal opinion/perception
<Caesar> seb128: let's not get bogged down on that
<pawalls> seb128, I thought I was pretty relaxed in our previous conversations via launchpad.
<seb128> pawalls: it is, don't worry ;-)
<pawalls> seb128, Recommended some possible solutions, offered to talk to you in real time if you liked.
<Caesar> seb128: I think you agree that having zillions of Nautilus windows for your $HOME is not a good user experience though, yes?
<seb128> just don't use regression as an argument
<seb128> though I agree we have an issue to fix there
<pawalls> seb128, Fair enough. Now the question is.. is it reasonable to keep the old behavior.
<pawalls> or is there a compelling reason to not revert to the old behavior.
<seb128> I'm not sure what the old behaviour is
<seb128> I'm rather looking for what we should change now in gvfs
<pawalls> seb128, Create a separate partition (any type) at /home/$USER
<seb128> rather than copying the old stack
<Caesar> seb128: the old behaviour is no volume icons on the desktop for NFS mounts, and no Nautilus windows popping up
<pawalls> seb128, And then log into gnome.
<pawalls> seb128, You will see an icon on your desktop named "$USER" and nautilus will pop up a window on login.
<pawalls> seb128, You resolved the problems with /auto and other /home volumes not appearing.. but this one remains.
<seb128> I'm looking at the code, a min
<pawalls> seb128, Thanks.
<pawalls> seb128, I'd be happy actually to provide a patch if it's still not clear. I actually haven't looked at the code personally. I didn't report the original bug, so I didn't feel compelled to provide a patch. I was originally just trying to give a 'me too' ;-)
<seb128> ok, I think your usecase is a corner case
<seb128> in the code
<seb128> the code does
<seb128>       if (g_str_has_prefix (mount_path, "/media/"))
<seb128>         return TRUE;
<seb128>       
<seb128>       if (g_str_has_prefix (mount_path, g_get_home_dir ()))
<seb128>         return TRUE;
<seb128>     }
<seb128>   
<seb128>   return FALSE;
<seb128> which means it consider only mounts in the current user directory
<seb128> but doesn't filter out the user dir though
<seb128> so likely a && !strcmp(mount_path, g_get_home_dir ()) would fix your issue there
<Caesar> seb128: cool
<seb128> Caesar, pawalls: does any of you know how to build a package to try a change?
<pawalls> seb128, Yes.
<Caesar> seb128: is the Pope Catholic? ;-)
<slangasek> seb128: ... Caesar is a DD..:)
<seb128> pawalls: in glib2.0, gio/gunixmounts.c g_unix_mount_guess_should_display()
<seb128> could you change the
<pawalls> seb128, I'm happy to see that it's explicit instead of implicit :)
<seb128>      if (g_str_has_prefix (mount_path, g_get_home_dir ()))
<seb128>         return TRUE;
<seb128> to also check than the mount_path is not the user directory
<pawalls> seb128, Yes.. that should work fine.
<seb128> add a && !strcmp(mount_path, g_get_home_dir ()) or similar
<pawalls> seb128, Ceaser or myself will test it.
<seb128> thanks
<seb128> I'll talk to upstream about the issue
<seb128> let me know if that solves your bug
<Caesar> seb128: okay, will do, thanks
<seb128> thank you
<seb128> slangasek: hey
<seb128> slangasek: I changed gnome-panel to use time-admin again rather than the new dialog
<seb128> slangasek: that workaround the fix milestoned issues about the new dialog and users asked to get the time-admin dialog which let sync on ntp and change timezone rather than the one
<seb128> let me know if you think the change is not appropriate
<seb128> but I think that should be no issue
<Caesar> seb128: unsatisfiable build dependencies :-(
<seb128> s/the one/the new one
<seb128> Caesar: for?
<Caesar> glib2.0
<slangasek> seb128: right, saw your comment about that in one of the bugs, was waiting for it to show up on my mirror so I could test
<seb128> slangasek: ok
<Caesar> seb128: The following packages have unmet dependencies: libfam-dev: Depends: libfam0 (= 2.7.0-13)
<slangasek> seb128: but time-admin certainly should be an improvement over the current behavior, I think
<seb128> Caesar: which one? that is weird because hardy is sort of stable now and glib2.0 has not a lot of build-depends
<seb128> Caesar: install libgamin rather
<Caesar> seb128: ok
<seb128> slangasek: ok, then we agree, good ;-)
<slangasek> seb128: ah, and I'll wait a bit longer, it's on my mirror now but the upgrade wants to break both the kernel and OOo due to packages still being in the process of building :)
<seb128> no hurry ;-)
<tedg> How do I ignore the "maintainer isn't @ubuntu.com" error in debuild?
<tedg> (or more correctly, how do I make debuild ignore it)
<seb128> tedg: it's not a blocker, just ignore it ;-)
<Lamego> close your eyes :P
<slangasek> tedg: don't use "ubuntu" in the version number if you're not uploading to Ubuntu?
<tedg> seb128: No, it does seem to be fatal.
<slangasek> and if you are uploading to Ubuntu, comply with the DebianMaintainer spec instead of ignoring the error
<tedg> slangasek: The problem is that I'm just trying to do this security patch, so I'm trying to avoid changing as much as possible...  the previous packager (on dapper) didn't do it.
<slangasek> tedg: I would argue that the DebianMaintainer spec should be applied to security updates to dapper, the same as to any other new uploads
<Caesar> tedg: changing the maintainer isn't changing functional behaviour
<slangasek> tedg: update-maintainer --section=[main|universe] will DTRT to the changelog
<slangasek> er, control file
<slangasek> anyway, your other option would be to use a dapper version of debuild... :)
<tedg> Okay, I'll change it.  If keescook rejects it I'm coming back after you guys ;)
<seb128> thinking about this automount issue
<seb128> how come that the current logged user directory is unmounted?
<seb128> there is usually files used there
<slangasek> if keescook rejects it, I'm going to tease him mercilessly about his glib2.0 version numberb ug
<slangasek> >:)
<Caesar> heh
<slangasek> seb128: evidently, there are no open file descriptors associated with the mount, so it idle unmounts?
<ogra_cmpc> i think the maintainer spec was not in place in dapper, we should have a clear rule for handling such cases
<Caesar> slangasek: which surprises me somewhat
<Caesar> I've asked someone to keep a terminal window open with their $CWD == $HOME overnight and see what happens
<slangasek> oh, $CWD alone should trip it, shouldn't it, hmm
<slangasek> that is odd, then
<Caesar> Unless automount is doing a lazy unmount?
<slangasek> that would be... an error
<slangasek> :)
<Caesar> I'll be intrigued to see what keeping a terminal window open does
<slangasek> anyway, I would consider it a bug for nautilus to auto-open a window for /any/ autofs mount
<Caesar> slangasek: previously it was doing it for everything in /auto
<Caesar> That was just awesome when slocate went berko and tried to index /auto
<slangasek> heh
<Caesar> But I believe both those problems have been fixed
<slangasek> wonder what it does with /afs
<seb128> gvfs only lists shares in media and in the user directory nowadays
<slangasek> ok
<seb128> the user directory which is the issue there being a corner case
<Caesar> seb128: will you proposed glib-2.0 modification stop $HOME appearing on the desktop, or just fix the Nautilus window popping issue?
<Caesar> s/you/your/
<james_w> what should be the version number of an SRU to http://packages.ubuntu.com/ca-certificates in feisty?
<james_w> i.e. a native package with a different version to every other release.
<cjwatson> soren: (*map)[src] = 0 in copy_device is definitely wrong - it really is supposed to just copy. Obviously it's being used wrong since the intent (a logical assertion, indeed) at the end of move_device is that there should be only one reference to each device.
<soren> cjwatson: Makes sense.
<infinity> james_w: 20061027.1
<cjwatson> gutsy is the hard one
<cjwatson> ca-certificates |   20061027 |        feisty | source, all
<cjwatson> ca-certificates |   20070303 |         gutsy | source, all
<cjwatson> ca-certificates | 20070303-0ubuntu1 |         hardy | source, all
<infinity> james_w: Or 20061027feisty1 (or some variant)
<slangasek> mathiaz: muhaha, my runes in this samba upload are going to be SO much more crackful than yours
<cjwatson> 20070303-0gutsy1 would be OK, I guess
<infinity> cjwatson: Is the hardy one still native?  I hate native packages with seemingly non-native version numbers. :/
<Ward1983> i found a annoyance when installing ubuntu for the first time on my laptop, and its still in 7.10, so i would like to file a bug but have no clue how or what to write, so i thought i'd come explain it here
<cjwatson> infinity: probably
<Caesar> seb128: So a modified glib2.0 doesn't prevent the $HOME volume appearing on the desktop
<mathiaz> slangasek: which bug are you trying to fix ?
<cjwatson> infinity: note the version number in Debian, though ...
<cjwatson> ca-certificates |   20070303 |        stable | source, all
<cjwatson> ca-certificates | 20070303-0.1 |       testing | source, all
<cjwatson> ca-certificates | 20070303-0.1 |      unstable | source, all
<Caesar> seb128: won't be able to say about the Nautilus thing for a bit
<infinity> cjwatson: Yeah, which is also a policy no-no, that should have been $date.0.1
<Ward1983> when i install i just get virtical random colored lines and the rest of the LCD slowly turns white
<infinity> cjwatson: Oh well.
<slangasek> mathiaz: bug #206036
<ubotu> Launchpad bug 206036 in samba "package samba 3.0.28a-0ubuntu3 failed to install/upgrade: " [Undecided,Incomplete] https://launchpad.net/bugs/206036
<Ward1983> now the only problem was Option "UseDisplayDevice" "DFP" was missing
<slangasek> mathiaz: the fix is " || ! getent passwd "$USER" >/dev/null"
<Ward1983> so every new user with a similar laptop just doesnt get anything on their screen
<Ward1983> at least for the 2 last releases
<infinity> slangasek: I'd comment on how vile that looks if I wasn't sure I that I have almost that precise test in one of my own maintainer scripts.
<slangasek> heh
<seb128_> re
<seb128_> need to give some kicking to my isp tomorrow
<seb128_> <seb128> Caesar: both
<seb128_>  Caesar: it'll make it stop being listed as an user visible mount
<seb128_>  Caesar: ie, be a standard directory on the disk
<james_w> infinity: yes it is still native.
<james_w> cjwatson: pitti recommended 20070303-0ubuntu0.7.10 for gutsy
<Caesar> seb128: well it didn't work then
<Caesar> I'm also trying to forcible reproduce the problem by SIGUSR1ing automount, which should force an expire of mounts
<Caesar> s/forcible/forcibly/
<Caesar> seb128: let me just give it a reboot to make sure everything cops a restart
<infinity> james_w: There's no right answer, really, just many wrong ones (ie: ones that don't eval >> or << the versions in previous/later releases, or versions which are just plain unparseable to the human eye)
<seb128_> Caesar: ok
<infinity> james_w: pitti's suggestion maps to what he and I decided on for Mozilla security backports years ago, and now seems to be used by much of the security team.
<slangasek> #define right !wrong
<infinity> james_w: And it is readable, I'll give it that.
<james_w> infinity: I'm using 20061027-0ubuntu0.1 at the moment, but I don't want to steal a security number, is there a danger of doing that?
<infinity> james_w: The security folk are good at reading.
<infinity> james_w: (And they pretty much have to anyway)
<james_w> :-)
<james_w> I had a look at the packages in gutsy-updates, and there didn't seem to be scheme that was discernible to my feeble mind
<Caesar> seb128_: no, definitely didn't work
<infinity> james_w: No matter what you pick, the security team still needs to look it up and make sure not to clash, so don't worry too much.
<james_w> I'll submit it like that, pitti can ask for a different one if he likes.
<james_w> a second question, does the SRU team handle sponsored SRUs, or would I still subscribe u-m-s?
<infinity> james_w: $ver.0.1, $ver-0ubuntu0.1, $ver-0ubuntu0.7.10, $ver.gutsy.1, $ver.yomamma.1... They all "work".
<Ward1983> anyone?
<james_w> thanks infinity
<slangasek> james_w: it appears that pitti will just upload any of these packages for you directly, before I have a chance to blink twice, so I'd go with that :)
<seb128_> Caesar: ok, something else to try for you
<seb128_> Caesar: get the gvfs source
<james_w> slangasek: thanks, I'll make sure he does it while you're asleep tonight :-)
<infinity> james_w: Usually, I'd suggest finding a sponsor, but vorlon seems to be implying that in your case you already have one with pitti. :)
<seb128_> Caesar: hal/ghalvolumemonitor.c _g_unix_mount_point_guess_should_display
<seb128_> Caesar: similar change
<Caesar> seb128_: ok, getting
<james_w> infinity: pitti sponsored the fix in to hardy, and was helping with the SRUs, so I think he'll be willing to do it.
<keescook> james_w: -updates and -security tend to follow the same conventions.  I've outlined the versioning styles here: https://wiki.ubuntu.com/SecurityUpdateProcedures under "Preparing an update"
<james_w> keescook: thanks
<emgent> hi kees :)
<keescook> heya emgent
<keescook> james_w: and, as infinity says, we're good about making sure we don't step on something.  (or rather, soyuz is perfect at it, and we can't)
<soren> cjwatson: Anything else you want me to try this evening? I just remembered I won't be around tomorrow and the day after.
<Caesar> So, ah, when is there going to be a linux-restricted-modules-2.6.24-14-generic package to go with the kernel?
<Caesar> seb128: that mod to gvfs didn't get rid of the $HOME volume on the desktop
<seb128> Caesar: ok, so you have a weird config I've no idea about
<seb128> the easier would be to describe how to config easily a similar setup so it can be debugged
<Caesar> seb128: s/weird/large enterprise or academic institution/
<Caesar> seb128: how much infrastructure do you have at your disposal
<seb128> none
<seb128> a compuiter
<Caesar> Then we've got a problem
<seb128> computer
<seb128> well, a desktop and laptop so I can do networking between those
<Caesar> You'll need an NFS server
<Caesar> So you'll have to use one as an NFS server for your home directory and automount it on the other one
<Caesar> I'll update the bug with specifics once I've figured them out for you
<seb128> ok, weird though that the gvfs change didn't work
<Caesar> Yeah
<Caesar> Sounded promising
<seb128> is your nfs mount listed in gvfs-mount -li ?
<seb128> Caesar: and is the nfs thing in fstab?
<Caesar> seb128: no, that's the point of autofs
<Caesar> seb128: and yes, my home directory is listed in the output of gvfs-mount -li
<pawalls> seb128, I'll try to hack together a patch for this.
<pawalls> seb128, Thanks for the pointers and for being available.
<Caesar> Yeah, thanks seb128
<seb128> Caesar: do you still get the icon listed and the mount in gvfs-mount -li with the glib and gvfs changes?
<Caesar> seb128: yes
<seb128> Caesar: speaking with on of the upstream guy
<seb128> he did recommend doing the same changes that I suggested
<seb128>  if (strcmp (mount_path, g_get_home_dir()) == 0) return FALSE;
<seb128> " if (strcmp (mount_path, g_get_home_dir()) == 0) return FALSE;" is what he suggested
<seb128> Caesar: maybe you could try to make sure the function in gvfs returns false as expected?
<seb128> Caesar: are those mounts listed in mtab?
<cjwatson> soren: just figuring it out now with a reduced harness; I'll see if I can get you something before I crash
<seb128> pawalls: still around?
<soren> cjwatson: Ok, I'll be around for a little bit more, but I'm getting sleepy eyed, too.
<cjwatson> fortunately I think I've just seen the bug
<cjwatson> soren: ok, on top of the change you've already made, find the bit in move_device that looks like this:
<cjwatson>             if (walk == limit || next == dest)
<cjwatson>               break;
<cjwatson>             copy_device (next, cur);
<cjwatson> ... and change it to this:
<cjwatson>             if (walk == limit)
<cjwatson>               break;
<cjwatson>             copy_device (next, cur);
<cjwatson>             if (next == dest)
<cjwatson>               break;
<cjwatson> that fixes my test harness at least
<Dossy> Hi.  What team is responsible for VNC?  the X Swat team?
<cjwatson> soren: any luck?
<soren> Trying right now.
<cjwatson> cool
<soren> Sorry, got stuck in an e-mail.
<soren> That seems to have done it.
<soren> I'll pastebin the results.
<soren> http://pastebin.com/m2c5e2894
<pawalls> seb128, yessir
<seb128> pawalls: could you try editing gvfs hal/ghalmount.c g_hal_mount_new()
<seb128> and change the && in
<seb128>   if (volume == NULL && !g_unix_mount_guess_should_display (mount_entry))
<seb128> to ||
<seb128> pawalls: just a random try, not sure it'll work
<cjwatson> soren: awesome. Thanks!
<soren> cjwatson: Any time.
 * soren crashes
#ubuntu-devel 2008-04-03
<seb128> Caesar, pawalls: doh, I'm not awake, the glib and gvfs I pointed before, it should not use a ! before the strcmp comparaison
<pawalls> seb128, *nods*
<seb128> Caesar, pawalls: could you remove the ! in the glib change and try again?
<pawalls> seb128, That was what I was going to do :-P
<pawalls> seb128, However I'm wrapped up with another bug at the moment. Was hoping to get to it within the next 30 mins.
<seb128> pawalls: ok, it's 1am here so I'll not be around for a while but I'll try to wait a bit, I would like to know if that fixes the issue
<pawalls> seb128, Ok.. give me just a second then.
<seb128> pawalls: thanks!
<infinity> Unpacking mktemp (from .../mktemp_1.5-5ubuntu1_i386.deb) ...
<infinity> dpkg: error processing /var/cache/apt/archives/mktemp_1.5-5ubuntu1_i386.deb (--unpack):
<infinity>  trying to overwrite `/bin/mktemp', which is also in package debianutils
 * infinity boggles that this hasn't been fixed yet...
<infinity> Wait..
<infinity> slangasek: Dude, your changelog claims to have fixed the above bug, but I see no Replaces in the control info...
<pawalls> seb128, FYI.. g_get_home_dir returns the exact entry from passwd, which (generally) doesn't have a '/' at the end.
<infinity> slangasek: Another case of "write the changelog before the fix, get distracted, upload"? :)
<slangasek> hmm, odd
<pawalls> So if you had two users (pawalls and pawalls2 let's say), they one user would get the mounts of the other.
<pawalls> seb128, My understanding based on looking at the glib code.
<slangasek> infinity: well first of all, it hasn't "been fixed yet" because it was un-fixed post-etch in the Debian package
<pawalls> so we might want to change that to "%s/", g_get_home_dir()
<slangasek> as for how I missed it in the upload, ... no idea
<seb128> pawalls: well, neither the mount_point nor the user directory should have it no?
<pawalls> seb128, You're using 'has_prefix'
<pawalls> Which means.. if someone mounted /home/pawalls2/something it would show up for pawalls
<infinity> slangasek: Yeah, I know it was unfixed, I assumed mvo's upgrade testing would have caught it eons ago, that's all. :)
<pawalls> Which is why the trailing / is important.
<seb128> pawalls: ah, that's a good point
 * pawalls nods.
<infinity> ... and now all my postinst scripts are segfaulting.
<pawalls> seb128, Of course it is ;-)
<seb128> pawalls: so it's working better now?
<pawalls> seb128, compiling.
<seb128> ok
<pawalls> seb128, Appears to have worked.. let me confirm on my other box so I can log completely out/into gnome
<seb128> pawalls: excellent, thanks
<slangasek> infinity: mktemp fixed some more
<infinity> slangasek: "Slightly more fixed"? :)
<infinity> slangasek: (Thanks!)
<pawalls> seb128, Looks good.
<pawalls> seb128, Thanks again.
<pawalls> seb128, I do recommend also adding the '/' onto the end of that comparison though.
<seb128> Caesar, pawalls: ok, so nothing weird about the config you are using, that was just a typo in the suggested changed ;-) Sorry for the extra rebuilds, etc
<seb128> pawalls: thanks
<pawalls> seb128, Yeah.. I wasn't really paying much attention earlier.
<pawalls> seb128, I told Ceasar I would hack up a patch and then kinda drifted onto other things.
<seb128> pawalls: http://bugzilla.gnome.org/show_bug.cgi?id=525866 btw
<ubotu> Gnome bug 525866 in gio "the user directory should not be considered as a mount to display" [Normal,Unconfirmed]
<seb128> pawalls: both issues are described there
<seb128> pawalls: I'll get the fix in hardy tomorrow
<pawalls> seb128, Great!
<pawalls> seb128, Thanks again for your help.
<seb128> pawalls: you are welcome! and thanks for pointing the issue and testing the change ;-)
<seb128> enough for today
<seb128> good night everybody, see you tomorrow
<infinity> slangasek: I'll be your VERY BEST FRIEND, if you do NEW processing for LRM (I fiddled with queues to make sure it built everywhere, should be good to go)
 * keescook slaps himself
* runur changed the topic of #ubuntu-devel to: asdas
* runur changed the topic of #ubuntu-devel to: Archive: Feature Freeze, DocumentationStringFreeze | Ubuntu 8.04 LTS Beta released | Development of Ubuntu (not support, not application development on Ubuntu) | #ubuntu for support and general discussion for dapper/edgy/feisty/gutsy, #ubuntu+1 for hardy | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki
<slangasek> BFF-infinity: done
<Khajavi> I want to install codeblock (C++ IDE)
<Khajavi> dpkg -i libcodeblocks0_8.02-0ubuntu1_i386.deb
<Khajavi> libcodeblocks0 depends on libwxgtk2.8-0 (>= 2.8.7); however:
<Khajavi> what do I do?
<Khajavi> :-X:-(
<protonchris> Khajavi: try apt-get -f install
<Khajavi> protonchris: this command didn't work
<genii> Are there any plans to incorporate some incremental apt system? (zsync or similar)
<genii> There seems someone made a start on it ~7.04    https://blueprints.launchpad.net/ubuntu/+spec/apt-sync  but it looks stalled
<userone> best mobo for linux?
 * RAOF fails to see how that's a question relating to the development of Ubuntu.
<rhineheart_m> any plans to include webmin back to the repo since it has been maintained already?
<LaserJock> rhineheart_m: I doubt it, we have ebox
<rhineheart_m> LaserJock, but ebox has limited features.. and I guess it is still immature
<pwnguin> so LP provides openID -- is it going to consume it?
<LaserJock> pwnguin: "not at this time"
<LaserJock> rhineheart_m: well, if webmin's getting maintained in Debian it might come back. We dropped it when Debian did
<pwnguin> LaserJock: so now it's a game of which is the longer timeline "eventually" (as in, eventually we see LP being open sourced) or "not at this time"
<LaserJock> pwnguin: I don't think it really matters either way
<rhineheart_m> can you recommend the use of ISPConfig for ubuntu-server ed?
<genii> rhineheart_m: I've set it up and used it under 6.06 but it was a headache to get operating correctly
<LaserJock> the point of the openID stuff was to allow various things (like forums, wiki, Fridge) to authenticat using LP
<pwnguin> what about QA?
<rhineheart_m> genii, uhuh. really? but have you tried it with gutsy? or anybody here uses ISPConfig and has something to share too?
<genii> rhineheart_m: I go from LTS to LTS so not bothering with 7.10 server. When 8.04 release comes I'll attempt it again if you want a review later
<LaserJock> pwnguin: the Ubuntu QA sites?
<rhineheart_m> genii, is that a server? are you using it for server?
<genii> rhineheart_m: Yes
<rhineheart_m> genii, is there something wrong with 7.10?
<pwnguin> LaserJock: yea
<genii> rhineheart_m: Probably not anything the matter with 7.10 server, just a matter of personal preference for me to stay with 6.06 until next LTS (8.04)
<rhineheart_m> genii, okay.. I got you.. so the next stable LTS version of ubuntu is 8.04 (Hardy)... any idea when it will be made available?
<genii> rhineheart_m: April 24 apparently
<rhineheart_m> okay.. so I will wait for its release.. I am actually to try debian..
<rhineheart_m> genii, have you tried debian/?
<genii> rhineheart_m: Not on any of my personal boxes but I have to minimally deal with it on two servers
<rhineheart_m> genii, are you hosing several domains in your box?
<genii> rhineheart_m: There were previously 3 domains for those two machines, it's since been reduced to one
<rhineheart_m> okay.. how do you manage multiple domains in one box?
<genii> rhineheart_m: Primary and scondary DNS answering to those domain name lookups, virtual hosts in apache and postfix
<LaserJock> pwnguin: yeah, I imagine that would be a big part to. Anything we can get an openID module/plugin for.
<rhineheart_m> genii, okay.. I used actually webmin to do the task. I thought you're using something different..
<genii> rhineheart_m: We ssh in and do everything in CLI
<genii> Since we are drifting OT and there seems no answer to my original question I'll leave you all to be
<dholbach> good morning
<kagou> Good morning
<warp10> Good morning
<hunger> When will bzrzools become installable again? It always fails to install here (it keeps failing in "Preparing to replace bzrtools 1.0-1ubuntu3)
<hunger> make that 1.2.0, not 1.0.
<dholbach> bug 201978
<ubotu> Launchpad bug 201978 in python-central "pycentral crashed with OSError in prepare()" [Medium,Triaged] https://launchpad.net/bugs/201978
<kagou> hey seb128
<seb128> lut kagou
<tkamppeter> Riddell, ping
<\sh> moins...
<\sh> did anyone saw a break in d-i kernels and broadcom netextreme bcm5704 gbit nics on yesterdays daily (ubuntu-server flavour)
<\sh> s/saw/see/
<pitti> Good morning
<ion_> Howdy
<\sh> hey pitti
<ogra_cmpc> hey pitti
<\sh> ogra_cmpc, do you need somehow the debian-edu package?
<ogra_cmpc> no
<\sh> ogra_cmpc, well, it ftbfs on lpia and amd64...
<\sh> ogra_cmpc, that's why I'm asking
<ogra_cmpc> \sh, nothing to do with me, its the defaults for the debian-edu cd/distro
<\sh> cjwatson, where can I find the udeb for the NIC drivers which are loaded from d-i during install? I thought they were under pool/main/l/linux/
<pitti> calc: any chance to fix bug 114503 before you upload o-l10n?
<ubotu> Launchpad bug 114503 in ubuntu-meta "language-support-* packages depend on Firefox, Thunderbird and Open Office Writer on Ubuntu and Kubuntu" [Undecided,Invalid] https://launchpad.net/bugs/114503
<pitti> it's trivial, but serious
<pitti> trivial to fix, I mean
<mantiena-baltix> hello all
<pitti> calc: ah, you uploaded already
<mantiena-baltix> doko_: hi
<dholbach> Keybuk: can you say a bit more about your "answer" in bug 211159? :)
<ubotu> Launchpad bug 211159 in udev "prevent create_devices in postinst from failing" [Low,Won't fix] https://launchpad.net/bugs/211159
<\sh> damn...looks like yesterdays iso of ubuntu-server is borked
<Fujitsu> Why did this morning's upgrade throw me back to ubuntulooks, and apparently remove the option to go back to the much nicer Human/Murrine?
<seb128> Fujitsu: because ubuntulooks looks better and the other themes were buggy
<\sh> Fujitsu, that was announced...
<seb128> Fujitsu: and it has been decided to roll back
<seb128> though I agree that could have kept the corresponding gtkrc variants, didn't hurt
<seb128> you need to ask to kwwii and mvo about that
<Fujitsu> I knew the default was being changed, but I didn't think it'd remove the option.
<Fujitsu> ubuntulooks looks a whole lot worse, IMO.
<seb128> Fujitsu: that's a joke, right? the other theme had blue tooltips and some very visible bugs
<Fujitsu> Erm? My tooltips were a pleasant orange.
<seb128> I had blue at some places
<seb128> that was not tooltips I think
<seb128> but the nautilus bars at the top of the burn location for example
<Fujitsu> Hmm, that was orange too.
<dholbach> I didn't have anything in blue either
<seb128> maybe you used an another theme than me
<Keybuk> dholbach: ?
<Keybuk> dholbach: vserver prevents the postinst from creating device nodes
<seb128> anyway I'm not the one who decided
<Keybuk> udev cannot work without those device nodes
<Keybuk> therefore the postinst has to fail
<seb128> and I think ubuntulooks looks better
<Keybuk> ah
<Keybuk> it looks like Launchpad rudely discarded my comment
<pitti> mvo: lts-ubuntu> eww
<dholbach> Keybuk: ok, thanks
<mvo> pitti: yeah :(
<pitti> mvo: does it get much better if removed packages get purged?
<mvo> pitti: interessting questions, I can test that in a bit
<Keybuk> dholbach: sometimes I think I put the comment under the add a comment bit, and then change the status
<Keybuk> LP UI bug :-/
<dholbach> Keybuk: np
<Keybuk> dholbach: if postinst fails in create_devices, you won't have /dev/null, /dev/console and other useful things ;)
<dholbach> Keybuk: I just purged udev - I just thought it'd be useful if udev didn't break in postinst - but I agree it's a special case where it probably doesn't make sense
<mantiena-baltix> calc: hi, are you online ? I'm backporting OpenOffice 2.4 to Ubuntu 7.10 (Gutsy), maybe you already did this job ?
<Keybuk> that would mask failures on legitimate systems, e.g. disk full
<dholbach> *nod* fine with me
<ogra_cmpc> Fujitsu, orange ? do you have edubuntu-artwork installed ? that uses orange and a dark red by default
<Fujitsu> ogra_cmpc: It was the correct Ubuntu orange. No, I don't have it installed.
<ogra_cmpc> ah, k
<mantiena-baltix> doko_: or maybe you can tell me something about OOo 2.4 backport to Gutsy ?
<doko_> mantiena-baltix: no, do you want to make one?
<mantiena-baltix> doko_: I'm backporting OpenOffice 2.4 to Ubuntu 7.10 (Gutsy) now :) (firsty try was unsuccessful because of incorrect build-deps - mono-1.0-dev doesn't exist in gutsy). I'm wondering maybe someone already did this job and I don't need to backport openoffice 2.4 ?
<doko_> mantiena-baltix: no, don't know of anybody who did it
<\sh> cjwatson, it seems, something went wrong with the ubuntu-server daily cd building yesterday...
<mantiena-baltix> doko_: ok, then I will replace mono-1.0-devel and mono-2.0-devel dependancies with ones from gutsy and try again :)
<Ng> mjg59: I think that in conjunction with doing the network module unload on suspend, we should do an init.d/networking restart on resume, otherwise some things get very confused
<Ng> mjg59: i.e. the manual network configurmatron sees no devices on resume without restarting networking
<cjwatson> \sh: they are. nic-modules
<cjwatson> \sh: I imagine it's just kernel version out of sync with d-i
<cjwatson> happens
* cjwatson changed the topic of #ubuntu-devel to: Archive: Feature Freeze, DocumentationStringFreeze | Ubuntu 8.04 LTS Beta released | Development of Ubuntu (not support, not application development on Ubuntu) | #ubuntu for support and general discussion for dapper/edgy/feisty/gutsy, #ubuntu+1 for hardy | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs
<\sh> cjwatson, yep..looks like...
<mantiena-baltix> doko_: btw, maybe you know when calc will be online ?
<ogra_cmpc> mantiena-baltix, US timezone ... rather in your afternoon
<\sh> cjwatson, the nic-modules packages are missing (well more then 3/4 of the packages in this dir are missing...) I think it was really the -14 upload which bugged ... coincidence
<cjwatson> \sh: it's not buggy.
<mantiena-baltix> ogra_cmpc: thanks
<cjwatson> \sh: it's just that we haven't uploaded d-i to match it yet.
<cjwatson> \sh: please don't file a bug about this - this always happens if we don't get the timing just right.
<\sh> cjwatson, won't do that anyhow...that's why I was pinging you :)
<cjwatson> \sh: I'll bring things back into sync today
<\sh> cjwatson, ok..because right now, I'm unable to test the >2TB patch :)
<Ivshti> Hi
<Ivshti> Why dont we include graphical configuration tools in Ubuntu?
<Ivshti> Like the tools in Mandrake/Mandriva?
<Ivshti> I mean tools like drakconf, so the user can easly configure the system.
<seb128> Ivshti: to configure what?
<seb128> Ivshti: ubuntu has graphical configuration tools
<ogra_cmpc> seb128, mandrake indeed, else it wouldnt be called drakconf :P
<seb128> ogra_cmpc: ah, right ;-)
<ogra_cmpc> Ivshti, what are you missing from the shipped tools ?
<Ivshti> Test Mandriva and you will see
<Ivshti> everything is in one control panel
<pwnguin> well thats constructive., lets just take a break from the final strech in an LTS to install mandriva
<seb128> Ivshti: that's not the question
<Ivshti> you start drakeconf, and from there you can configure all the things, while in ubuntu you must search for the needed tool
<seb128> Ivshti: the question is what option is lacking in the current ubuntu tools
<mantiena-baltix> Ivshti: Ubuntu has control panel, just install gnome-main-menu package and add "Start" menu applet to your panel
<seb128> Ivshti: that's a design decision, a zillion options in one dialog is not something easier to use
<seb128> Ivshti: run gnome-control-center?
<Ivshti> for example I want to resise a partition... In Mandrake/Mandriva I just start drakeconf (one way or another) and I click on "manage disk partitions"
<Ivshti> in ubuntu I must search for Gparted
<Ivshti> and what if I dont know what is Gparted :D
<Ivshti> A user will search for "configure computer" or "configure partitions" or something like this
<ogra_cmpc> so you are missing a partition editor in the default install, what else ?
<seb128> Ivshti: it's called partition manager in the menu, it's as easy to search for it there than in a dialog which has zillion options
<Ivshti> hmm, the control panel must be build-in
<seb128> Ivshti: no thanks
<Ivshti> sorry, It was "Gparted" in the version I've tested :D
<mantiena-baltix> Ivshti: control panel is already build-in since Ubuntu 7.10
<mantiena-baltix> Ivshti: which Ubuntu version you use ?
<Ivshti> 7.10?!
<Ivshti> No, I mean "7.10", I am 100 % sure
<ogra_cmpc> mantiena-baltix, its not set as default, we disaabled it because it had usability issues vs the menu structure
<Amaranth> mantiena-baltix: it is disabled
<Ivshti> I will take a look next time I start Ubuntu
<ogra_cmpc> (takes about three times as long to get to any option that way ... you have to wait until teh panel started and then search your optionn)
<ogra_cmpc> Ivshti, alt+f2 and run gnome-control-center
<Ivshti> Yes, of cource
<Ivshti> I saw that
<pwnguin> personally, i'd call the presence of keyring-manager in both prefs and administration a usability bug
<Ivshti> (I am not running ubuntu, but I am runnning gnome)
<Ivshti> thanks, a tip: just put this in the "System" Gnome menu
<Amaranth> Ivshti: No
<Amaranth> Read what was just said about that
<mantiena-baltix> Ivshti: look at the contents of /etc/lsb-release file - Ubuntu version should be mentioned there
<ogra_cmpc> Ivshti, we diliberately dont
<ogra_cmpc> *deliberately
<Amaranth> gnomecc also takes some time to load
<ogra_cmpc> until the usability of such integrated stuff is on par with the meu system used curretly
<ogra_cmpc> *meu
<ogra_cmpc> gah
<ogra_cmpc> *menu
<Amaranth> i can view the menu and load the thing i want by the time gnomecc starts
<ogra_cmpc> right
<mantiena-baltix> Ivshti: you could report a wishlist bug about putting gnome-control-center launcher in the System menu
<ogra_cmpc> mantiena-baltix, ugh
<Amaranth> The main problem I have with it is that it pretends to be something special when it's really just a weird display of a menu
<Ivshti> This gnome-control-center is very good.
<ogra_cmpc> seb128, btw, what about movig baobab ad the printer thingie from accesoires to system tools as well if we keep system tools
<seb128> ogra_cmpc: we are getting ride of system tools again I think
<Ivshti> But how will one new user know about it
<Amaranth> Ivshti: They won't, that's why it is hidden
<seb128> ogra_cmpc: users reactions on the list show they prefer not having it in the default install
<ogra_cmpc> seb128, ah, good ...
<mantiena-baltix> ogra_cmpc: lots of users feels better when they have "control center" - why don't allow them to use  it ?
<ogra_cmpc> yeah, understandable
<Ivshti> And... that is a  very bad idea.
<ogra_cmpc> mantiena-baltix, because itsd totally confusing :)
<Amaranth> Ivshti: If you like it you can use it, don't force your choice on others
<Amaranth> Ivshti: There are serious problems with it
<Ivshti> okay
<mantiena-baltix> Ivshti: I support you, so you could report a wishlist bug about putting gnome-control-center launcher in the System menu
<Ivshti> And... here is the question... why dont the ubuntu developers put a tool like drakeconf
<\sh> da pitti is blogging :) wow :)
<Ivshti> Like gnome-control-center but without bugs
<mantiena-baltix> Ivshti: some Linux distributions already uses this, for example Novell (Suse) Linux, Baltix Linux and others
<ogra_cmpc> Ivshti, what bugs ?
<Amaranth> As soon as it starts as fast as clicking the menu and does something more useful than the menu I'm all for it
<Ivshti> I just want easyer ubuntu :D
<seb128> Ivshti: because it's not better than what we have now
<seb128> Ivshti: ubuntu is easy
<pwnguin> Ivshti: because Ubuntu chooses to support upstream developers instead of starting yet another project?
<Ivshti> yes, I know is easy
<Amaranth> Right now the gnomecc is just a slower way to access the same thing the menu gives you
<Ivshti> I've tryed Slackware, that means I know Ubuntu is easy (if you get the idea)
<seb128> Ivshti: how hard is it to read labels in a menu rather than on an canvas?
<seb128> Ivshti: gnome-control-center just lists the menu items in a grid
<Ivshti> Yes, but it's litle bit better when all things are in one grid
<seb128> no it's not
<mantiena-baltix> Amaranth: gnomecc is slow for you, but lots of users feels better when they have "control center" - why don't allow them to use  it ?
<Ivshti> because some tools are in the applications menu ;)
<ogra_cmpc> Ivshti, beyond telling us we miss gparted in the default install and that gcc has bugs you didnt specify with any details you didnt really tell anything that could convince yet
<seb128> you have to search in 2 dimensions
<Amaranth> mantiena-baltix: you can enable it in alacarte
<Silicium> hi
<seb128> Ivshti: you don't want to remove all the menu and put 80 items in a canvas
<Ivshti> Okay, you are right...
<seb128> Ivshti: gnome-control-center doesn't list applications tools
<mantiena-baltix> Amaranth: I already did this in Baltix distro :)
<ogra_cmpc> Ivshti, if you can make convincing points i'm sure nobody would object changes, buut i didnt see anything that wo8uld convince me personally to do anything different to what ubuntu does atm
<Ivshti> (But drakeconfig does list the applications tools)
<seb128> Ivshti: so basically the gnome-control-center is an another view listing the same content as the system menu, not easier to use, just slower to load
<Silicium> how i can change the font color of the ubuntu isolinux bootmenu? i dont want to hack the source if is possible
<cjwatson> Silicium: which version?
<Silicium> 8.04
<ogra_cmpc> Ivshti, how about making a real comparison with pro and con lists and send that to the ubuntu-devel-discuss mailinglist ? :)
<seb128> Ivshti:  you can use kubuntu it you want complicated interface listing zillion options
<Amaranth> eep
<pwnguin> zing!
 * Amaranth hides
<ogra_cmpc> seb128, !
<Silicium> cjwatson: u 8.04 isolinux 3.53
<mantiena-baltix> seb128: gnomecc is easier for newbies, because it has search entry, also it's easier for Windows OS users
<ion_> Awesome bug. :-D gdm played the login sound, like, twenty times and then played the end of the sample again probably as many times.
<cjwatson> Silicium: play with 'foreground' and 'background' in /isolinux/gfxboot.cfg
<seb128> mantiena-baltix: I'm not convinced
<cjwatson> Silicium: the names are actually sort of backwards, sorry
<Silicium> there are any documentations about?
<ogra_cmpc> ion_, it just wants to tell you its *really* there now
<cjwatson> Silicium: afraid not, as far as I know
<cjwatson> Silicium: Ubuntu uses 'background=0xB6875A', for example
<ion_> ogra: Yeah, "why don't you login already?!?!!"
<cjwatson> which is actually the foreground font colour *cough*
<Silicium> so i use a Background splash.pcx
<Silicium> and the font color is blue
<cjwatson> right, so set background=
<Amaranth> mantiena-baltix: That's the problem with most of the SLED stuff. It makes it somewhat easier for new users but doesn't grow with you as you become a more advanced user
<mantiena-baltix> Ivshti: If you wanna to have some applications listed in gnome-control-center you could report a wishlist bug about that in launchpad or gnome bugzilla ;)
<Silicium> cjwatson: ok
<Silicium> cjwatson: i will try, thanks :)
<pwnguin> ion:  cant get gdm to even let me log in. i wonder if it's just playing nothing twenty times
<Amaranth> mantiena-baltix: With a menu a new user can scan it slowly reading for the thing they need, the more advanced user has muscle memory built up for where in the menu the thing they want is and just fly right to it
<ogra_cmpc> pwnguin, do you use a facebrowser ? someone had probs here yesterday with that
<mantiena-baltix> Amaranth:  you shouldn't tell this to me - I'm advanced user
<pwnguin> ogra_cmpc: yea =/
<Ivshti> Oh yes, is it legal to include wine in ubuntu?
<ogra_cmpc> pwnguin, switch it off until its fixed then :)
<mantiena-baltix> Ivshti: yes, why not ?
<Ivshti> (Yeah, It's legal)
<cjwatson> we aren't aware of legal problems with wine
<Ivshti> But why dont you include it?
<pwnguin> Ivshti: legal, but do you really want novices running random windows programs they find?
<cjwatson> right, the biggest problem with wine is that it can end up being an automatic spyware vector if you're not careful
<Lamego> Ivshti, because most people don't need it ?
<mantiena-baltix> Ivshti: Baltix distro already includes wine in default CD ;)
<Amaranth> Ivshti: Ubuntu is not a Windows replacement, it is a Windows alternative
<pwnguin> or filing bugs against ubuntu when windows software doesn't work?
<Ivshti> Hmm... windows programs can crash ubuntu too.
<pwnguin> i mean, no offense to the wine people who work on ubuntu, but i imagine it'd be a hell of a triage load
<Amaranth> Ivshti: I mean it isn't supposed to be a drop-in replacement for Windows, installing WINE by default would make it seem that way
<Ivshti> Yeah, I know you are NOT trying to replace Windows...
<seb128> mantiena-baltix: what do you remove from the baltix cd to ship wine?
<Amaranth> probably mono stuff
<Ivshti> And, when speaking about mono...
<Ivshti> Why dont you include mono in Ubuntu
<Amaranth> No
<pwnguin> what?
<Amaranth> Ivshti: f-spot and tomboy are installed by default
<Ivshti> .NET replacement in uBuntu? Why not?
<mantiena-baltix> Amaranth: btw, my view is slightly different from SLED - I think operating system should be easy to use for newbies and for advanced users. That's why Baltix has both ways to access system configuration - gnome-control-center and traditional System->Administration and System->Preferences menus ;)
<pwnguin> Ivshti: do you actually run ubuntu?
<Ivshti> That wont make Ubuntu to look like Windows replacement
<Silicium> cjwatson: nope, does not work
<Ivshti> Yes, of coure, I had it installed but... I've installed Mandriva
<mantiena-baltix> seb128: you are asking what I removed from Ubuntu CD to have space for wine ?
<Amaranth> trying to remember how long ago mono stuff was added
<cjwatson> Silicium: it's what we do to make the text brown in Ubuntu menus, so I know it works
<Amaranth> 6.10?
<pwnguin> so right now, you cant check to see if your claims about what ubuntu does or doesn't do, etc, you can't actually check?
<Silicium> so if u use the original isolinux.bin, i have the old ubuntu 6.x menu
<ogra_cmpc> Amaranth, yeah, around that
<Silicium> and in the 8.04 is the color also blue
<cjwatson> "Ubuntu 6.x" isn't something that makes sense
<seb128> mantiena-baltix: yes
<cjwatson> the 6 is a year, not a series
<ion_> Ok, audio is not the only problem. Ethernet doesn't work properly either. Dhcpdiscover goes out but it never gets the response, and there are errors about eth0 in dmesg.
<cjwatson> Silicium: no, the Ubuntu boot menu has brownish text in 8.04
<Ivshti> Ubuntu CD is... 695 MB... It has space for a litle bit more software
<ion_> (After today's kernel upgrade)
<pwnguin> hahaha
<cjwatson> Ivshti: *we do include mono in Ubuntu".
<Silicium> cjwatson: oO on my beta image not :D
<pwnguin> oh poor seb
<pitti> seb128: hm, seems your --language=python fix in apport now broke the pot, it does not have the glade strings any more
 * ogra_cmpc wonders which CD Ivshti is looking at
<Silicium> beta-server
<pitti> seb128: what's the syntax again for setting a particular format for a POTFILES.in entry?
<pwnguin> Ivshti: misstatement of the year
<seb128> pitti: doh
<cjwatson> Ivshti: the hard limit is 700MB, though
<Ivshti> I am looking at 7.10!!
<Ivshti> You have 5 MB space!
<cjwatson> Ivshti: which we intend to use for more localisation
<ogra_cmpc> which we would fill with translations
<ogra_cmpc> snap :)
<cjwatson> Silicium: oh, right, server is wrong
<Silicium> .S
<cjwatson> I'll fix that
<Ivshti> At least for installed Macromedia Flash player! :D That's very, very important!!
<Keybuk> if only stackable filesystems worked properly :-/
<pwnguin> Ivshti: there's plenty of consternation every release about what does or doesn't make the cut for space concerns
<Fujitsu> .......
<Silicium> can i use the isolinux.bin from the desktop version to fix it for me?
<cjwatson> Silicium: no, isolinux.bin is the same
<Ivshti> NTFS in Ubuntu works perfectly, what is the problem about filesystems?
<cjwatson> Silicium: I told you what to put in gfxboot.cfg already
<cjwatson> background=0xB6875A
<Silicium> cjwatson: ya, but does not work :)
<pitti> seb128: if I drop the option from Makevars, a "cd po/; intltool-update -p --verbose" works fine, hm
<cjwatson> Silicium: I am quite certain it does, because we use exactly that for Ubuntu (desktop)
<seb128> pitti: how fine?
<Amaranth> Ivshti: adobe's flash will never be installed by default, it is closed source
<Silicium> cjwatson: i will try again
<cjwatson> Silicium: I'm afraid you must be doing it wrong somehow. Perhaps you have DOS line endings?
<pwnguin> Amaranth: how soon till gnash is in?
<cjwatson> anyway, committed a fix for server
<Silicium> noe, i have tried background=0x000000 (black) so no i try with exactly you line
<Amaranth> pwnguin: i'm pulling for swfdec
<cjwatson> I expect background=0x000000 would make all the text go black
<cjwatson> like I say, the naming is unfortunately reversed
<Silicium> you line does also not work :D
<Silicium> mhm can you paste me the whole isolinux.cfg?
<cjwatson> isolinux.cfg is not involved
<Ivshti> Amaranth: Okay, but I think there is an open-source flash player. There are alot of flash players that have nothing to do with Adobe's flash player!
<cjwatson> I said gfxboot.cfg
<Silicium> ooh
<Silicium> iam sorry
<Amaranth> Ivshti: they are...not ready
<Amaranth> to put it kindly
<Amaranth> getting better all the time though, so i'm still hoping
<pwnguin> fun
<ion_> Ok, getting rid of kexec and rebooting fixed the problem. :-)
<cjwatson> Ivshti: Keybuk was talking about something else with regard to stackable filesystems
<cjwatson> not NTFS
<pwnguin> ogra_cmpc: so how do i turn off facebrowser without running gdm?
<mantiena-baltix> seb128: Ubuntu CD has lots of unneeded stuff, for example unneeded help files, look at bug #80978 for example
<ubotu> Launchpad bug 80978 in baltix "[Suggest] Help *.deb packages for each languages" [Undecided,New] https://launchpad.net/bugs/80978
<ogra_cmpc> pwnguin, use startx and sudo gdmsetup or so ...
<pwnguin> ogra_cmpc: it just tells me that gdm is running.,
<Lamego> mantiena-baltix, still those split languages files would need to be available on the Ubuntu cd
<Amaranth> Lamego: well, no
<mantiena-baltix> Lamego: not all - Ubuntu CD contains support for only most popular languages, while help files are shipper for all languages, even for not supported in CD
<Silicium> is it works :DD
<Silicium> cjwatson: thanks
<pwnguin> ogra_cmpc: or rather, it tells me that gdm isnt running, then closes
<Amaranth> but i doubt that would free up much space
<pwnguin> which is... not helpful
<ogra_cmpc> pwnguin, indeed
<mantiena-baltix> Amaranth, Lamego: look how big is /usr/share/gnome/help folder in your system and you see
<cjwatson> Silicium: great
<ogra_cmpc> might be that you cant get around ediuting the config manually
<pwnguin> nuts
<ogra_cmpc> pwnguin, well, you are using unreleased software ....
<mantiena-baltix> Amaranth, Lamego: in default edubuntu CD (which I currently use) help files uses 140 MB !
<cjwatson> mantiena-baltix: I think we probably should look at doing something about it, but not for 8.04; getting it right (e.g. not inadvertently shipping systems without any help) will take a bit of effort
<pwnguin> yea, its just annoying to have to dig into gdm.conf when ive not done that before, this close to release
<cjwatson> mantiena-baltix: it compresses quite well, so it's not quite that bad
<ogra_cmpc> mantiena-baltix, define "default edubuntu CD" :) edubuntu is an addon to ubuntu with hardy
<Amaranth> ogra_cmpc: wait, what?
<ogra_cmpc> (with about 200M spare space atm, so who cares about size :) )
 * Amaranth missed that one
<mantiena-baltix> cjwatson: only XML part of help files compesses well, but in /usr/share/gnome/help there are a lot of .png files, which doesn't compress at all
<cjwatson> mantiena-baltix: they are often identical across languages, so in terms of a tarball containing all of them they do in fact compress rather well
<mantiena-baltix> ogra_cmpc: I'm use Edubuntu 7.10 LiveCD now
<ogra_cmpc> ah, k
<mantiena-baltix> cjwatson: it's a pitty, but png files are different for several languages, like zh, jp or ko
<cjwatson> mantiena-baltix: sure, I didn't say "always identical".
<ogra_cmpc> Amaranth, we had the edu software on a separate cd anyway .... so it was cleverer to move over completely and put the core bits only edubuntu had (ltsp) inot ubuntu
<cjwatson> and I said "compresses quite well" (i.e. significantly less than the 140 MB you cited), not "compresses brilliantly"
<cjwatson> so please stop nitpicking :)
<mantiena-baltix> cjwatson: :-P
<ogra_cmpc> mantiena-baltix, the sad thing is that svg supports localization since years (2003 or so) and that still pngs are used
<ogra_cmpc> but thats not in our hands and requires upstream to do the switch
<mantiena-baltix> ogra_cmpc: I think png are used in help because most of them are screenshots
<ogra_cmpc> with text on them ;)
<ogra_cmpc> menus, toolbars ....
<mantiena-baltix> ogra_cmpc: yea, but do you know a way how to make vectorized screenshot ? ;)
<Amaranth> OS X screenshots are pdfs
<pwnguin> cairo?
<ogra_cmpc> that surely would requirre some thinking, but there are ways
<pwnguin> Amaranth: are they bitmaps embedded in pdfs?
<ogra_cmpc> even potracing a png can work ...
<Amaranth> pwnguin: i don't think so, the display server uses something similar to pdf internally
<Amaranth> btw, my help folder is 176M and compresses (bz2) to 65M
<ogra_cmpc> mantiena-baltix, i didnt say its easy or straghtforward but the capabnility is there since ages, someone needs to write software to make use of it
 * cjwatson uploads GRUB with EDD support; please let me know about any device ordering regressions
<cjwatson> it won't activate unless you boot with edd=on, so I'm not too concerned about migrating people's menu.lst files
<ogra_cmpc> what does it do ? alter the device.map ?
<cjwatson> yes
<mantiena-baltix> Amaranth: I quess you need only about 50 Mb of help files (quess you know not more than 5 languages :) )
<cjwatson> well
<cjwatson> it alters the way device.map is constructed if there is none
<ogra_cmpc> ah
<cjwatson> if device.map is already there, it won't do anything, so definitely no migration problem
<ogra_cmpc> so it cant affect the existing one
<cjwatson> right
<mantiena-baltix> Amaranth: how big are OS X screenshots' ? I mean are they real vector PDF's or only bitmap inside PDF ?
<Amaranth> *shrug*
<pitti> mvo: http://people.ubuntu.com/~mvo/bzr/hwdb--mvo/po/POTFILES.in -- did those type: fields ever work for you? I just tried to use them in apport, but they seem to be entirely ignored
<pitti> mvo: I just get some weird perl warnings
 * ogra_cmpc guesses thats for old hwdb
<pitti> right, it's ancient, but it's utterly hard to find a documentation about POTFILES.in format
<pitti> /usr/bin/intltool-update still has code to process it AFAICS
<cjwatson> Keybuk: it just occurred to me (again) that device.map has device names not UUIDs, and so can break on upgrade when devices get moved around; we should do something about that for 8.10
<ogra_cmpc> ++
<mvo> pitti: I think this stuff worked once, but I was struggling recently with it too and I think it stopped :/
<pitti> meh
<pitti> mvo: ok, thanks
<seb128> we should get danilo to fix it
<seb128> he's upstream for intltool
<pitti>     foreach (@buf_potfiles) {
<pitti>         s/^\[.*]\s*//;
<pitti>     }
<pitti> seb128: ^ no wonder that [...] doesn't do anything; WTF??
<ion_> Heh
<seb128> pitti: weird
<cjwatson> pitti: what's weird?
<pitti> seb128: hm, seems the main flaw is that it tries to put it all into just one xgettext call, which just doesn't work if you mix glade and python files
<pitti> cjwatson: I'm trying to figure out why the [type: gettext/glade] etc. syntax does not work in POTFILES.in
<cjwatson> pitti: I know, but I was wondering what specifically you were commenting on in the above code
<pitti> cjwatson: that seems to be the bit which throws out all the [...] tags
<cjwatson> oh, you mean the way it's explicitly stripped off, right :)
<seb128> pitti: maybe ask danilo about the issue, as said he's upstream for intltool and might have an idea about the issue
<pitti> right, I'll do that
<seb128> cool
<seb128> I already pinged him about that before doing the apport changes
<seb128> that's him who suggested the change I did
<phoenix_> About a month ago, I reported a bug, and alas I know I'm not the only one that reports bugs, but this one causes a kernel panic in the raid controller device driver - and I was wondering why the bug is still "undecided".... and I'm a little bit puzzled how bugs are being "decided" to be fixed...
<cjwatson> phoenix_: that's the priority; don't stress too much about the priority; some people don't do all the paperwork
<cjwatson> phoenix_: about kernel bugs, #ubuntu-kernel is the best place to ask
<phoenix_> cjwatson: AFAICS I can't give any hints about the priority, I think that's something the being set by the person that does the triage...
<phoenix_> cjwatson: thanks for the channel hint, I'll go ask them about it
<pitti> seb128: ok, h4ck1sh, but works: http://bazaar.launchpad.net/~ubuntu-core-dev/apport/ubuntu/revision/1092
<Silicium> cjwatson: how works the language selection in isolinux? in isolinux.cfg is the english version written but when i use "german" the menu entries goes german, where are saved the german version of the menu entrie?
<davmor2> evand: ping
<tkamppeter> Riddell, hi
<emgent> heya
<cjwatson> Silicium: they're in /isolinux/de.tr
<cjwatson> Silicium: that's in a weird compiled format, though - the version in the gfxboot-theme-ubuntu source package is probably more comprehensible, though
<cjwatson> s/, though$//
<mantiena-baltix> doko_ , calc: maybe you know if I should set BUILD_JARS_NATIVE=n in OOo2.4 Gutsy backport ?
<mantiena-baltix> doko_: in gutsy's (OOo 2.3) debian/rules file BUILD_JARS_NATIVE was set to 'n', while in OOo 2.4 from Hardy it's set to 'y'
<Riddell> hi tkamppeter
<Silicium> cjwatson: how i can create/compile that file?
<Silicium> anyway
<cjwatson> Silicium: build the gfxboot-theme-ubuntu source package in the usual way for Debian-format source packages
<Silicium> ok
<Silicium> thx
<lool> soren: Hmm I wanted to have a look at ubuntu-vm-builder again, but I don't see the rewrite branch anymore and I don't see its merge in the trunk branch
<twi_> ping on https://bugs.edge.launchpad.net/ubuntu/+source/elisa/+bug/201133 ?
<ubotu> Launchpad bug 201133 in elisa "Elisa doesn't start" [Undecided,Confirmed]
<twi_> it's quite trivial it's only a dep issue
<Silicium> includes the actual beta desktop cd a live environment?
<cjwatson> Silicium: yes, please try it
<Silicium> cjwatson: thanks :)
<Riddell> seb128: starting today's Ubuntu Desktop live CD I get "There was an error starting the GNOME Settings Daemon"
<Keybuk> cjwatson: just been reading the glibc incident report
<Keybuk> it occurs to me that we still haven't fixed the initramfs-tools bug that Mark ran into
<Keybuk> which is also my fault, since I've known about that bug for about two years ;)
<lamont> hrm... I suspect that hardy-alternate-ia64.iso needs some pruning... 741M is slightly larger than my largest CD-R media...
 * lamont wonders if the daily-live dvd for ia64 (830MB) stands a chance of working, or if ia64/hppa should really just have server isos
<cjwatson> Keybuk: could you add that to the report?
<Riddell> pitti: bug 197819 can be fixed with making jockey use DEBIAN_PRIORITY to high, shall I change that in bzr?
<ubotu> Launchpad bug 197819 in jockey "[Hardy]b43-fwcutter install script fails to fetch firmware in first run" [Undecided,Confirmed] https://launchpad.net/bugs/197819
<pitti> Riddell: ooh
<pitti> Riddell: but isn't that the default priority anyway?
<Riddell> pitti: it's currently "critical"
<pitti> Riddell: hm, still weird; the question should default to 'true'
<cjwatson> debconf's default priority is high, for the record
<pitti> cjwatson: right, jockey overrides it to critical, so that the question isn't askd
<pitti> asked
<cjwatson> ok
<cjwatson> why do you say the question should default to true
<cjwatson> ?
<cjwatson> there's no Default in the .templates
<pitti> cjwatson: that code is still from bcm43xx-fwcutter, where that was the case
<cjwatson>         db_get bcm43xx-fwcutter/cut_firmware || true
<cjwatson>         if [ "$RET" = "true" -o "$RET" = "false" ]; then
<cjwatson>                 db_set b43-fwcutter/cut_firmware $RET
<cjwatson> unrelated, but that's just bizarre code
<cjwatson> "let's put it back, just in case cosmic rays hit it"
<pitti> when I apt-get install b43-fwcutter, the dialog defaults to true at least
<ion_> Hehe
<cjwatson> that's probably chance
<cjwatson> I don't think it's defined what happens
<pitti> hah, indeed
<pitti> sudo DEBIAN_PRIORITY=critical apt-get install b43-fwcutter
<cjwatson> and also depends on whether you had previously purged b43-fwcutter or just removed it
<pitti> Riddell: hm, then let's ask the debconf question; at least it's explicit then
<cjwatson> I assume the reason it should be asked is that you might not have network access
<cjwatson> BTW, I was wondering if we should promote b43-fwcutter to main and put it on the CD
<pitti> which you need most of the time anyway to get b43-fwcutter itself
<cjwatson> because you might be able to use it without network access if you have Mac OS installed
<pitti> yeah, in that case it makes sense
<seb128> Riddell: do you get it every time? does running gnome-settings-daemon manually does the same?
<pitti> Size: 16418
<cjwatson> (real case, this came up with a friend yesterday)
<cjwatson> seems pretty much the same as ndiswrapper to me
<Riddell> calc: today's livefs didn't get built with "The following packages have unmet dependencies:  openoffice.org-help-en-gb: Depends: openoffice.org-writer but it is not going to be installed" (curious since openoffice.org-writer is installed already)
<Riddell> seb128: I'm afraid I've rebooted into other things
<seb128> Riddell: ok, that's alright
<seb128> Riddell: if there is an issue we will figure soon enough
<Riddell> evand: recent live CDs won't launch ubiquity from the desktop icon, .xsession-errors has 'error: g_spawn_command_line_sync: Failed to execute child process "/usr/lib/ubiquity/bin/ubiquity kde_ui" (No such file or directory)'
<Riddell> evand: strangely starting ubiquity on a command line works fine
<pitti> Riddell: I'll upload a fix now, ok?
<Riddell> pitti: sure
<Riddell> pitti: what are you changing?
<pitti> Riddell: I think I'll just drop the DEBIAN_PRIORITY setting altogether
<Riddell> ok
<pitti> Riddell: b43cutter is the only package so far where we actually wanted it, and now we don't any more
<cjwatson> Riddell: that sounds like it genuinely is quoted
<cjwatson> as in, the file "/usr/lib/ubiquity/bin/ubiquity kde_ui" does not exist
<Riddell> ah hah
<Riddell> command line "ubiquity" is fine but "ubiquity kde_ui" as used in the .desktop file gives me that error
<cjwatson> hmm, I wonder if hal-lock changed
<cjwatson> (see /usr/bin/ubiquity for why I'm wondering this)
<mjg59> cjwatson: Hrm. I just tried to create a partition flagged as "dont_use" in ubiquity, got some CD access and now it's hung
<mjg59> (yesterday's daily)
<cjwatson> mjg59: yes, there's a bug about that
<mjg59> cjwatson: It's, uh, running du?
<cjwatson> er
<cjwatson> bug 132611 is the one I know about
<ubotu> Launchpad bug 132611 in ubiquity "Crash of installer when partitioning - "dont_use" filesystem" [Medium,Confirmed] https://launchpad.net/bugs/132611
<mjg59> du -s --block-size=1 /rofs
<cjwatson> it's probably looping through check.d
<mjg59> Ah, yeah, that could be it
<mjg59> Yes, pid count is rising rapidly
<mjg59> Anything I can save you before starting again?
<cjwatson> I bet "PartmanOptionError: partman-target/choose_method should have None (dont_use) option" is in /var/log/installer/debug?
<mjg59> Yes
<cjwatson> right, in that case no need
<mjg59> That's the final line
<mjg59> Cool
<mjg59> Any workaround?
<cjwatson> I'll see if we can figure out what's going on, sorry about that
<mjg59> No problem
<_MMA_> Not sure if I should ask here or in -devel but has anyone see the "Failed to mount /" issue on the resent Alt disks?
<_MMA_> After partitioning that is.
<cjwatson> I think you can create it outside ubiquity and then just delete any automatic mountpoint that gets added
<mjg59> cjwatson: Hm. Doing sudo killall ubiquity results in me being launched into a full desktop session
<cjwatson> mjg59: that's a sort of awkward not-sure-what-to-do thing
<mjg59> I appreciate that this is not obviously a bug :)
<pitti> Keybuk: if I wanted a command ("rm -f /media/.hal-mtab") to be executed on boot, but *not* on /etc/init.d/hal restart, could I write an upstart script for that?
<cjwatson> at least in a desktop you can maybe do something about it
<kagou> who does the update of language/translations packages ?
<Keybuk> pitti: what about on runlevel changes?
<pitti> kagou: me, and in the future, ArneGoetje
<ion_> How about putting hal-mtab to a tmpfs?
<pitti> Keybuk: preferably not
<Keybuk> pitti: does it have to be in /media ?
<pitti> ion_: I thought about moving it to /var/run/hal-mtab, but that requires a large upstream patch
<Keybuk> pitti: isn't that precisely what /var/run is for?
<pitti> Keybuk: right; currently pondering what's easier (remove on boot, or introduce a huge patch to hal to move it)
<Keybuk> pitti: you could add it to bootmisc
<ion_> ln -s? :-)
<pitti> ^ which would go along with a postinst snippet to move it, and maybe a compatibiliyt symlink in /media in case other programs read hal-mtab as well
<kagou> oh nice pitti, many changes are done (installer/kernel image) can you do a recent sync for these package, as this, next daily-iso will be a good piece for tests
<pitti> kagou: they are automatically updated in hardy twice a week
<kagou> oh sorry, i didn't know
<pitti> Keybuk: in fact I faintly remember adding that code in the past to bootclean or bootmisc, but it's not ATM; might got droped in a merge, not sure
<Keybuk> pitti: it could arguably just go in mtab.sh
<Keybuk> since it's related
<pitti> Keybuk: I just thought it would be cleaner to ship an upstart script for hal instead of cluttering other standard init scripts with hal stuff
<seb128> Keybuk, pitti: meeting? ;-)
<pitti> Keybuk: I can live with that :)
<pitti> meeting, sure
<Keybuk> clutter - meh, HAL is essential ;P
<Keybuk> (and will be increasingly so as davidz increasingly merges it with udev)
<Keybuk> pedro_: did you want to join #ubuntu-meeting for the desktop team meeting?
<pedro_> Keybuk: going now
<pedro_> thanks
<lamont> Keybuk: does hal know it is? :)
<cjwatson> mjg59: ok, apply http://paste.ubuntu.com/6426/ to /usr/lib/ubiquity/ubiquity/components/partman.py and restart the installer
<cjwatson> the result is ugly (it should use translated text rather than 'dontuse') but at least it works
<james_w> Amaranth: hi, I made some comments in bug 118936, do they make sense? Do you know of a good way we can fix this?
<ubotu> Launchpad bug 118936 in alacarte "Alacarte does not recover deleted menu items" [High,Triaged] https://launchpad.net/bugs/118936
<mjg59> cjwatson: Rebooted, I'm afraid :(
<cjwatson> mjg59: ok, well it works in my tests, so committed
<elmo> is anyone else getting messages from SANE on resume?
 * ogra_cmpc wishes he could resume first place :P
<ogra_cmpc> i'd appreciate any messages ... sane or not :P
<mjg59> cjwatson: Do you know what the conclusion was about dealing with the usplash configuration?
<cjwatson> mjg59: yeah, I need to arrange for xauth to be passed through when ubiquity reconfigures usplash
<cjwatson> so usplash.postinst can get at the display
<mjg59> cjwatson: Wurgh. I'm really not convinced that's the best way of doing this.
<mjg59> I guess there are issues with getting ubiquity to write it, then?
<cjwatson> mjg59: it's usually not good for ubiquity to have excessive package-specific code
<cjwatson> much better for it to go in the package where at all possible
<cjwatson> it's technically possible to do it in ubiquity, but I'd really rather not unless all other avenues have been exhausted
<cjwatson> ubiquity ends up ridiculously big and unmaintainable, and there are problems when packages change their configuration file formats, as they have a habit of doing
<mjg59> cjwatson: Hrm. Yeah.
<cjwatson> I realise passing through DISPLAY and xauth is nasty as well, but
<kirkland> james_w: ping
<james_w> kirkland: hi
<kirkland> james_w: hi, see https://bugs.edge.launchpad.net/ubuntu/+source/gnome-system-tools/+bug/206198
<ubotu> Launchpad bug 206198 in gnome-system-tools "network manager cannot authenticate" [Undecided,Confirmed]
<kirkland> james_w: i noticed you were the last one to upload to it, i think there's a missing dependency, debdiff attached
<james_w> kirkland: yeah, I don't think I touched anything that would cause that, but the analysis seems sane
<james_w> seb128: what do you think? ^
<kirkland> james_w: oh, yeah, sure, i'm not pointing the finger :-)
<kirkland> james_w: i'm just remarking that you seem to be close enough to the package to sponsor the diff :-)
<seb128> james_w: that I hate g-s-t, looking at the bug ;-)
<james_w> seb128: :-)
<james_w> kirkland: I can't sponsor I'm afraid, seb128 sponsored my fix.
<seb128> hum
<kirkland> james_w: ah, okay.  keescook pointed me to seb128 anyway :-P
<seb128> I'm not sure policykit-gnome is really required
<kirkland> seb128: i can't unlock network-admin with out it
<seb128> kirkland: you could use the command line policykit interface to grant your rights and then run the tool no?
<Silicium> i.e when i have installed fooapp.deb on my local machine, and then i create a live dist with remastersys, the foo application is on the image, or or only the base system?
<kirkland> seb128: there's an "unlock" button at the bottom of the gui presented by network-admin.  how would the command line polkit-* help that?
<seb128> kirkland: if you already have the credential it doesn't need to open the password dialog, it'll just unlock for you
<james_w> so a recommends would be appropriate?
<kirkland> james_w: i think there's already a recommends
<seb128> well, I'm pondering since we don't install recommends
 * seb128 looks at mvo
<mvo> hu?
<seb128> that's really mvo's fault then ;-)
<mvo> not really, it was a joint fault of me and a missing seeds review
<seb128> mvo: right, just teasing you, but not installing recommends is bad, it forces us to abuse depends or to have broken situations for users
<kirkland> seb128: so to use the command line polkit-auth, at least some code would be required to acquire that credential if using the gui and not having policykit-gnome
<seb128> kirkland: ?
<seb128> kirkland: polkit-auth
<kirkland> seb128: polkit-* ?  which one?
<seb128> I don't understand your question
<mvo> seb128: first thing I will upload in intrepid is a new apt
 * seb128 hugs mvo
<kirkland> seb128: here's the use case....
<seb128> kirkland: I understand the usecase thanks
<kirkland> seb128: install a very, very minimal xubuntu system
<kirkland> seb128: click on networking
<kirkland> seb128: click on unlock
<kirkland> seb128: go boom
<seb128> kirkland: I'm pointing that xubuntu should have a recommends on policykit-gnome as ubuntu-desktop do if it's required
<\sh> woot...ubuntu certified for sun hardware, certified by sun...that's a big shot..
<kirkland> seb128: ah, okay
<seb128> kirkland: gnome-system-tools should recommends it too
<kirkland> seb128: okay, i see it recommends gksu
<seb128> yes, that's wrong, I though I changed it when I did other changes this week but I didn't clean the changes and forgot that one or something
<kirkland> seb128: okay, you want another debdiff, or do you have it?
<seb128> attach a debdiff to the bug and subscribe the sponsors
<kirkland> seb128:  sponsors being...
<kirkland> seb128: yourself?
<kirkland> seb128: and move the policykit-gnome from Required to Recommends?
<seb128> no
<seb128> ubuntu-main-sponsors
<kirkland> seb128: okay, and I'm moving policykit-gnome from Depends to Recommends, and removing gksu from Recommends?
<seb128> kirkland: https://wiki.ubuntu.com/SponsorshipProcess
<seb128> kirkland: right
<james_w> does anyone have a dapper vm image anywhere that I could get a copy of?
<kirkland> seb128: done.  thanks for your help.
<seb128> kirkland: you are welcome, thank you for your work
<james_w> or alternatively and help on installing a dapper kernel on hardy?
<Keybuk> james_w: let me know if that works ;)
<kirkland> james_w: /me shudders
<james_w> it won't boot by default because it refuse to generate an initramfs
<Keybuk> ahh
<Keybuk> thought it might do that
<james_w> I've tried stopping udev from preventing it, but the organisation of /lib/modules has apparently changed as well
<kirkland> james_w: i have one, but it's 4G, and it'll be tuesday before you finish downloading it from me
<Keybuk> what kernel did we ship with dapper?
<james_w> .15
<Keybuk> ah right
<Keybuk> yeah
<Keybuk> I really don't think the hardy udev can work on that
<james_w> no, it requires .17 IIRC
<Keybuk> uevent wasn't even introduced to .17 iirc
<elmo> err?  doesn't that some implications for upgrades?
<Keybuk> elmo: in the sense that you have to upgrade your kernel?
<Keybuk> (from the supported one for the previous release, to the supported one for the current release)
<elmo> Keybuk: well the current procedure doesn't upgrade it first
<Keybuk> it doesn't have to upgrade it *first*
<elmo> Keybuk: so you run hardy udev on dapper kernel, at least for whle
<Keybuk> the important thing is to upgrade it before you reboot ;)
<Keybuk> no you don't
<Keybuk> udev's upgrade leaves the existing one running
<elmo> ah, ok
<Keybuk> one of the major ways we differ from Debian
<cjwatson> the existing daemon, but presumably new rules files
<cjwatson> any new uevent will go through those, right?
<Keybuk> cjwatson: right, but that's generally ok
<cjwatson> I thought there was some new syntax
<Keybuk> the worst that happens is hotplugging breaks a little bit
<Keybuk> but since you have a big "RESTART NOW!" thingy, that's ok :p
<cjwatson> Riddell: could you (get somebody to) try out my changes in ubiquity r2600? You'd need to test the "Use as:" bit in both partition creation and partition editing
<Keybuk> "I just upgraded from dapper to hardy, haven't rebooted yet, but now my digital camera doesn't work" ... "reboot then"
<cjwatson> Riddell: the code is nasty at the moment because it isn't using a model/view design - I wasn't confident in doing that untested!
<cjwatson> but should really be fixed at some point
<kirkland> heno: ping
<kirkland> heno: i see that you commented on https://bugs.edge.launchpad.net/ubuntu/+source/hplip/+bug/187403/
<ubotu> Launchpad bug 187403 in hplip "hplip or dependencies/dependents should explicitly depend on foomatic-filters" [Undecided,Triaged]
<Keybuk> I actually thought for a while about adding a udevcontrol command to tell it to stop reloading new rules
<Riddell> cjwatson: let me look
<Keybuk> but then everything that shipped a new udev rule would have to pre-depend on the new udev, etc.
<Keybuk> that was messy
<kirkland> heno: I think the same missing dependency needs to be added for hpijs.  looking for a sanity check......
<heno> kirkland: looking
<Riddell> cjwatson, evand: I tracked down the g_spawn issue to a difference in the way gksudo and kdesu parse arguments, kdesu really work with quotes.  one workaround is to include a single line shell script to launch hal-lock and have kdesu run that
<heno> tkamppeter: will you update hpjis re bug 187403 ?
<ubotu> Launchpad bug 187403 in hplip "hplip or dependencies/dependents should explicitly depend on foomatic-filters" [Undecided,Triaged] https://launchpad.net/bugs/187403
<kirkland> heno: thanks, should I subscribe anyone else to this bug?
<kirkland> heno: ie, i have a debdiff attached to it
<heno> kirkland: no, Till is the maintainer, just add a hpjis task
<kirkland> heno: ;-)  thanks
<cjwatson> Riddell: shouldn't be necessary, we can control argument passing
<cjwatson> Riddell: so what does kdesu need when called from the shell?
<Riddell> cjwatson: I can't find a way to make it happy.  it either passes it as one file, or it splits everything up (in which case hal-lock just runs "ubiquity" which is mostly ok but will run the wrong frontend if the gtk one is installed)
<Riddell> kdesu doesn't really work with quotes, is what I ment above
<cjwatson> there aren't any quotes, though ...
<cjwatson> oh, I think I see what you mean
<cjwatson> that's awful
<cjwatson> is kdesudo less badly broken?
<cjwatson> (and/or usable here at all)
<Riddell> cjwatson: our kdesu is kdesudo (it's a dpkg-divert) and we made it work in this way to match kdesu's ugly behaviour
<cjwatson> does it work differently if called as kdesudo?
<Riddell> cjwatson: no
<cjwatson> that sounds like it might be a plan ...
<cjwatson> adverbial commands shouldn't muck with spaces like that - that sort of shenanigans can end up being a security hole
<cjwatson> and at the very least tends to cause knock-on bugs like this
<emgent> heya people
<cjwatson> Riddell: I'm looking at a workaround that doesn't involve yet another script, though
<cjwatson> Riddell: (and instead involves self-execing)
<cjwatson> anyway, phone ...
<tkamppeter> heno, I will do so, hpijs contains a PPD generator now and this one generates foomatic-rip-based PPDs.
<heno> tkamppeter: thanks
<tkamppeter> Riddell, hi
<cjwatson> Riddell: could you try http://paste.ubuntu.com/6429/ applied to /usr/bin/ubiquity? I don't have kdesudo installed here at the moment, but I think that will work
<Riddell> cjwatson: yes, that works fine
<cjwatson> great, will commit that
<Riddell> tkamppeter: I'll add back hpijs-ppds to the Kubuntu CDs
<tkamppeter> Riddell, thanks, and check whether the Hp inkjets really appear in the KDE Printing Manager, as in bug 209220 they say that the package was already installed and the printer still not listed.
<ubotu> Launchpad bug 209220 in system-config-printer-kde "HP DeskJet 5550 not supported in Hardy" [High,New] https://launchpad.net/bugs/209220
<Riddell> tkamppeter: ok.  a shame I wasn't able to fix it properly for this release, hopefully next time
<Tonio_> cjwatson: I'll try to add a gksu cmdline compatibility layer for kdesudo in the future
<Tonio_> cjwatson: probably a -g option or something
<Tonio_> cjwatson: unfortunately we can't get rid of the kdesu compatibility by default in order not to break everything...
<Keybuk> random QoTD: does anyone know who we can complain to about Google Calendar?
<ogra_cmpc> Keybuk, ask leslie ?
<Keybuk> I never seem to find her online
<ogra_cmpc> she might have a googlemail account *g*
<Keybuk> heh
<Keybuk> I don't
<Keybuk> tbh, I'm after immediate gratification with my problem :p
<Keybuk> since it's fixed, or I stop using it entirely
<Robot101> Keybuk: any XMPP account will do...
<Keybuk> Robot101: ?
<Robot101> to talk to people on google talk
<Robot101> you don't need a gmail account
<Keybuk> does anyone have an address for her?
<keescook> Keybuk: have you looked much at process personality settings for upstart?  I think I might need to tweak one...
<Keybuk> process personality?
<keescook> ("man personality")  the kernel process personality bits: ADDR_NO_RANDOMIZE, ADDR_COMPAT_LAYOUT, READ_IMPLIES_EXEC, etc
<keescook> Keybuk: basically, i think, i have to prove it fully, but READ_IMPLIES_EXEC is set by default for process 1 on ia32.
<keescook> as a result, until a setuid process is hit (like, say "sudo"), it stays active.
<keescook> this causes mmap PROT_READ to get PROT_EXEC included.  and this causes AppArmor to think a process is requesting an executable region of memory.
<keescook> AFAICT, READ_IMPLIES_EXEC is no longer needed (it was for old ELF binaries: http://lwn.net/Articles/94068/)
<Keybuk> set by default _just_ for process 1?
<keescook> well, it's passed from parent to child.
<cjwatson> it's a legacy binary; you haven't built it since 12:15 this afternoon
<Keybuk> cjwatson: damn, dude
<keescook> the point being that we've see mmap PROT_EXEC at boot, but after we sudo to root, it's gone.
<Keybuk> keescook: ?
<Keybuk> pretend that this baffled look means you have to explain things to me ;)
<keescook> Keybuk: I'm working on it.
<keescook> :
<keescook> er :)
<keescook> Keybuk: rewinding -- we have been seeing issues with AppArmor profiles (only on ia32)
<keescook> when we generated the profile originally, mmap-opening of regular files (with only PROT_READ) happen, and get flagged as "r" (read access)
<keescook> on a reboot, that same process suddenly needs "m" (mmap with PROT_EXEC) access, so the service fails (usually)
<asac> bryce: Option      "XAANoOffscreenPixmaps" "true" ... can we have that by default in hardy?
<Keybuk> ok
<Keybuk> just mmap?
<Keybuk> or any kind of file access (like ld.so)
<keescook> right.  this was a way to work around the addition of the non-executable memory stuff that was added to the kernel (see lwn URL above)
<Keybuk> not sure I follow
<Keybuk> the LWN link was a bit "since you know what I'm talking about" :)
<keescook> it seems that old ELF didn't have a "mark this region as executable" flag.
<keescook> oh, I didn't mean it that way, I meant it as "here's this thing I found that helped me understand"
<mjg59> Keybuk: Where has my sub-pixel anti-aliasing gone?
<keescook> to work around the need for the PROT_EXEC on hardware that didn't support the non-exec CPU bit, the kernel added READ_IMPLIES_EXEC, so that "old" mmap calls that were missing PROT_EXEC would get it added automatically.
<mjg59> Keybuk: Metacity and gnomepanel seem to be managing it, gnome-terminal is greyscale
<Keybuk> mjg59: didn't you want gnome-terminal to be greyscale?
<mjg59> Keybuk: No?
<Keybuk> s/greyscale/differently filtered/
<mjg59> I wanted it not to have obvious colour fringing, which is rather different :)
<Keybuk> ArneGoetje: changed fontconfig, xft or cairo recently?
<Keybuk> keescook: I meant that the author clearly assumed readers knew what he was talking about
<Keybuk> keescook: I see
<Keybuk> so if you do mmap (PROT_READ) you automatically gain PROT_EXEC
<keescook> if the READ_IMPLIES_EXEC personality bit is set, yes.
<asac> bryce: thats for #182038
<Keybuk> ok
<keescook> and READ_IMPLIES_EXEC vanishes once you pass through a setuid process.  (like, sudo)
<keescook> my understanding is that READ_IMPLIES_EXEC is totally unneeded for modern distros.
<Keybuk> how does a process's personality work?
<Keybuk> is a personality inherited from a parent?
<Keybuk> is it initialised to a default on fork() or is it initialised on exec() ?
<keescook> yes, though masked with a "is-it-setuid?" filter
<keescook> exec, it seems
<Keybuk> "yes" to a 3-choice question
<Keybuk> ah
<Keybuk> so when you exec(), the process gains a personality?
<keescook> it just gets the parent personality
<Keybuk> ?
<Keybuk> that kinda just contradicts what you said <g> ?
<Keybuk> personalities, iirc, were so you could run BSD binaries on Linux, right?
<keescook> we're probably talking past eachother on some subtle symantic point.
<keescook> no, I don't think so.
<keescook> they're for various internal kernel thingies (see the top of /usr/include/linux/personality.h for the list)
<Keybuk> yeah, and below that is the list of system types
 * ogra_cmpc wonders if there is also a schizophrenia.h then
<keescook> ah-ha!  okay, then that part is true.  (this is a relatively new area for me too...)
<Keybuk> so what I'm trying to understand is
<keescook> though I see none include READ_IMPLIES_EXEC.  :)
<Keybuk> 1) is Upstart's personality wrong?
<Keybuk> Upstart makes use of mmap(), so I could understand why this flags your apparmor profiler
<Keybuk> I don't need EXEC, so I could do without it
<keescook> 1) perhaps -- I'm suspecting so (it gets the kernel default, which includes READ_IMPLIES_EXEC on ia32 only)
<Keybuk> that implies Upstart needs to call personality() which is a bit odd really
<Keybuk> especially since this is working around people who didn't read the mmap() manpage properly
<keescook> it's not a problem with upstart directly, it's that it's children (i.e. init.d services) get that personality flag too
<Keybuk> right
<Keybuk> so that's the next bit
<Keybuk> 2) if I change Upstart's personality, is that change inherited by Upstart's children (ie. everything)
<Keybuk> signal masks, settings, resources, etc. are *all* inherited
<keescook> it's not a workaround for mis-use of mmap -- the kernel adds PROT_EXEC against the will of a process calling mmap if READ_IMPLIES_EXEC is in the personality.
<keescook> 2) yes.
<Keybuk> 3) when is the personality changed?
<cjwatson> 2) but the linker will put it back if necessary, if I understood Kees' link correctly
<keescook> It is my theory that upstart's personality on x86 is only READ_IMPLIES_EXEC, and 0 on amd64.
<Keybuk> 3b) should Upstart support setting the personality in the job description
<Keybuk> 3c) if Upstart sets the personality, is it pointless because the link-loader resets it
<Keybuk> if so, how does the link-loader know what it should be? :p
<keescook> 3) personality is changed either via a call to personality(), or during exec, with PER_CLEAR_ON_SETID is removed from the personality.  (currently (READ_IMPLIES_EXEC|ADDR_NO_RANDOMIZE))
<keescook> 3b) no clue, but this is one of the many reasons I wanted to discuss it before diving in any further.  :)
<Keybuk> which all pretty much sums up with
<Keybuk> - if the link loader sets the personality
<keescook> 3c) what I want upstart to do is UNset READ_IMPLIES_EXEC.  the linker won't re-add that.
<Keybuk> - what do we need to change to make Upstart have the right personality?
<Keybuk> - why not just change the default in the kernel?
<keescook> pers = personality(0xffffffff); pers |= ~READ_IMPLIES_EXEC; personality(pers);
<Keybuk> &=
<keescook> sorry, yes
<Keybuk> yeah
<keescook> getting kernel changes in this late is Hard(tm)
<Keybuk> but if Upstart's personality is inherited by everything else
<Keybuk> then that's basically the same
 * lamont adds sync requests for bind9 (to make jdstrand happy) and postfix (to make scottk happy)
<keescook> and the kernel vs upstart is the other main reason I wanted to discuss it with you.  :)
<Keybuk> there's a lot of implications here I'd like to understand first
<Keybuk> I tend to assume that deliberately overriding kernel defaults in userspace in ways that are hard to un-override is silly
<Keybuk> if the kernel default is wrong, fix the kernel :p
<Keybuk> (which is why I campaign against any modprobe options -- just change the default in the damned module)
<keescook> heh
<Keybuk> I guess I'm thinking:
<Keybuk> If personalities are inherited from the parent, changing the personality in Upstart is identical to changing the default personality in the kernel
<keescook> upstream kernel is notoriously conservative.  while I would agree this makes more sense to fix in the kernel, I'm trying to a) minimize the number of kernel changes, and b) make the change somewhere that if we've overlooked something, we can quickly and easily fix it
<Keybuk> If personalities are set on exec by the link-loader, then we should fix the link-loader to not set that for binaries that don't need it (which may be as simple as rebuilding the binary, no?)
<Keybuk> what's so bad about kernel changes?
<Keybuk> the patch will be the same size no matter where it's applied <g>
<elmo> Keybuk: people not using ubuntu kernel lose
<keescook> :)
<keescook> ah, there's that.
<Keybuk> elmo: they probably lose anyway
<Keybuk> they certainly don't deserve to win :p
<cjwatson> (don't you have people using upstart on non-Ubuntu ...?)
<elmo> Keybuk: err, I thought you wanted upstart to be used by non-Ubuntu folks?
<keescook> nah -- upstream kernels boot okay.  the kernel team even advocates using them to test for driver issues, etc.
<Keybuk> cjwatson, elmo: I don't see that this is a problem unique to Upstart?
<ogra_cmpc> cjwatson, fedora uses it by default in the next release
<Keybuk> it's not doing anything weird here, no?
<cjwatson> Keybuk: FWIW (a) I haven't understood the problem enough to say where it should be fixed (b) I'm just saying that "fix it in the Ubuntu kernel, screw upstream" is wrong - I agree in general that fixing things in the kernel when they belong there is correct
<cjwatson> does sysvinit have the same problem?
<Keybuk> cjwatson: I don't mean "screw upstream", "push" would be abetter verb :p
<cjwatson> heh
<Keybuk> it worked with SELinux <g>
<keescook> cjwatson: I haven't checked, but AppArmor upstream had mentioned they'd seen similar bugs, and he was going to check on it in SuSE
<Keybuk> I finally got them to agree that initramfs was the right way to set the policy, not by patching init <g>
<Keybuk> sysvinit itself doesn't use mmap()
<Keybuk> Upstart does
<Keybuk> but that should only affect that process, not its children
<Keybuk> (since sysvinit doesn't change any personality flags)
<cjwatson> unless the linker does magic, like the PT_GNU_STACK thing
<Keybuk> like adding the flag if you use mmap? :p[
<Keybuk> eww
<keescook> it's just the passing of the personality READ_IMPLIES_EXEC bit to children that I care about.  none of our distro needs it (but until now it did no harm)
<cjwatson> well, PT_GNU_STACK gets added if the toolchain thinks you need an executable stack. In theory this could be something similar. (I'm not saying it's PT_GNU_STACK BTW, it's just an analogy)
<keescook> cjwatson: AFAIU, it's directly related to PT_GNU_STACK, actually.
<keescook> kernel loader:
<cjwatson> aha. but upstart does not seem to have the relevant ELF section
<keescook>         if (elf_read_implies_exec(loc->elf_ex, executable_stack))
<keescook>                 current->personality |= READ_IMPLIES_EXEC;
<keescook> default:
<keescook> ./include/linux/elf.h:# define elf_read_implies_exec(ex, have_pt_gnu_stack)     0
<keescook> ia32:
<keescook> ./arch/x86/ia32/ia32_binfmt.c:#define elf_read_implies_exec(ex, executable_stack)     (executable_stack != EXSTACK_DISABLE_X)
<cjwatson> where does 'executable_stack' come from?
<keescook> tracking it now, it's related to PT_GNU_STACK in fs/binfmt_elf.c
<keescook> ./include/linux/binfmts.h:#define EXSTACK_DEFAULT   0   /* Whatever the arch defaults to */
<Ng> tkamppeter: thanks for your reply about the Xerox and poppler
<cjwatson> 'objdump -x /sbin/init | grep -i gnu' doesn't show it
<keescook> ./fs/binfmt_elf.c:      int executable_stack = EXSTACK_DEFAULT;
<keescook> then there's a chunk that looks for PT_GNU_STACK
<Ng> tkamppeter: I'm curious if the distro team is aware of the apparent poppler madness :)
<keescook> cjwatson: see line 774 of fs/binfmt_elf.c
<Ng> which branch of distro is poppler under? desktop or platform?
<Ng> specifically I care about bug #207776, which tkamppeter suggests is the result of broken postscript, and that it is by no means alone
<ubotu> Launchpad bug 207776 in poppler "[hardy] printing some PDFs from evince is crashing our Xerox printer" [Undecided,New] https://launchpad.net/bugs/207776
<keescook> hm, the more I follow the implies-exec code, the less sane I feel.
<cjwatson> keescook: right, but only if there is such a section - I don't think there is here
<cjwatson> unless it's in the initramfs
<cjwatson> which execs upstart later
<keescook> well, I'm really starting to scratch my head since it seems like this should get set for amd64 too
<ArneGoetje> Keybuk: please define "recently" :P
<keescook> instead of wasting everyone's time more, I'll go poke at this a bit more.  I feel like I have a better idea what to look for now.
<seb128> Ng: does gs opens the ps correctly?
<tkamppeter> Ng, Poppler needs really to be fixed. It does not only crash Xerox prnters with its PostScript, the output quality on printers which do not crash is very bad, a lot of unreadable small fonts.
<elmo> seb128: yes, but it looks terrible
<elmo> seb128: (but neither ghostscript nor the kernel crash, so we're one up on Xerox ;-)
 * Ng adds the above question and answer to the bug
<Keybuk> keescook: back
<seb128> well, I would argue that the printer should not crash on incorrect ps or that cupsys should not send a broken ps to the printer
<Keybuk> the kernel stuff certainly implies to me that personalities *aren't* inherited
<seb128> but right, would be nice to fix
<keescook> Keybuk: no problem, I'm still reading kernel code... well, they are, but the linker also sets some.
<Ng> seb128: absolutely the printer should not crash, and I have asked xerox to make it so
<keescook> i.e. if I set ADDR_NO_RANDOMIZE and exec cat /proc/self/maps, randomization is clearly disabled.
<lamont> hrm... why is it that right after I minimize firefox 3.0, it unminimizes itself?
<keescook> I'm still following the per-arch paths for elf_read_implies_exec.  the way I read it, everything should exec with READ_IMPLIES_EXEC, but since that's clearly not true, I'm scratching my head.
<Keybuk> it's not copied in fork though?
<seb128> Ng: thanks
<keescook> I assume it's copied in fork, yes.  but then the loader does stuff to it on exec.
<Keybuk> keescook: I don't see where
 * Keybuk is reading copy_process()
<keescook> Keybuk: I haven't looked at kernel code, I did that test experimentally.
<Keybuk> ah, no, it is
<Keybuk> personality is directly in task_struct, so it will be
<Keybuk> ok, so personality is inherited unless otherwise overridden
 * keescook boots a 32bit vm
<Keybuk> on x86 READ_IMPLIES_EXEC is always removed
<keescook> where do you see that?
<Keybuk> set_personality_64bit()
<Keybuk>         current->personality &= ~READ_IMPLIES_EXEC;
<Keybuk> mmmm, hacky
<keescook> hah
<Keybuk> it just always masks it out when setting it ;)
<keescook> durrr
<keescook> the code says what it _should_ do is define the elf_read_implies_exec macro to '0'.  oh well.
<keescook> that at least explains my confusion then.
<Keybuk> ok
<Keybuk> so the kernel can chose to _add_ the read_implies_exec flag
<Keybuk> and it will inherit down to any other proces that removes it
<Keybuk> it's never cleared by the kernel
 * keescook beats head on wall.
<keescook> 32bit doesn't have it set either.
<keescook> (based on a call to personality())
<Keybuk> ?
<keescook> from the code I see in the kernel for binfmt_elf.c, it looks like READ_IMPLIES_EXEC gets set if PT_GNU_STACK is missing.
<keescook> you found where it gets cleared for 64bit.
<keescook> I don't see how it stays cleared for 32bit.
<Keybuk> ?
<Keybuk> it doesn't
<keescook> when I call personality(0xffffffff) on 32bit, it comes back 0.  I would expect READ_IMPLIES_EXEC.
<Keybuk> (gdb) p personality(0xffffffff)
<Keybuk> $1 = 0
<Keybuk> right]
<keescook> I'm curious how that's possible, given the logic in binfmt_elf.c
<Keybuk> #define elf_read_implies_exec(ex, executable_stack)     (executable_stack != EXSTACK_DISABLE_X)
<Keybuk> so the read_implies_exec flag is added if executable_stack *is not* EXSTACK_DISABLE_X ?
<keescook> right, and executable_stack == EXSTACK_DEFAULT
<keescook> which != EXSTACK_DISABLE_X
<keescook> aw, I can't ptrace init.  ;)
<Keybuk> init=/bin/bash :)
<keescook> but I can ptrace a child, and it does have it...
<Keybuk> ok
<Keybuk> so something is removing that personality()
<keescook> right... *scratch head*
<keescook> the PER_CLEAR_ON_SETID happens during exec for a setid process.
<keescook> but it seems like non-setid children would get the flag back.
<Keybuk> what sets that executable stack bit?
<Keybuk> ie how would it get set to EXSTACK_DISABLE_X ?
<keescook> afaict, via a PT_GNU_STACK entry with NX in it
<mdz> pitti: I took advantage of the kernel update to test your fsck/usplash fix, and it worked fine this time (with /forcefsck)
<jdstrand> lamont: \o/
<keescook> sorry, PF_X
<pitti> mdz: yay
<Keybuk> keescook: what would one of those look like?
<mdz> pitti: that is, usplash is still broken for me, but fsck displays progress bars correctly
<pitti> mdz: I usually test with tune2fs -C 50 /dev/..., but force should work as well
<mdz> so it was tested in the same case AFAICT
<mdz> now to figure out why usplash is broken
<pitti> mdz: broken in what way?
<pitti> stopping prematurely?
<keescook> Keybuk: going on what cjwatson showed, we'd see it in objdump -x
<mdz> pitti: it only displays during initramfs
<Keybuk>   GNU_HASH    0x4023c8
<Keybuk> like that?
<mdz> and seems to dispappear instantly when init starts
<keescook> Keybuk: unsure, let me see what I can find.
<Keybuk> quest scott% objdump -x /sbin/init | grep -i gnu
<Keybuk>   GNU_HASH    0x400678
<Keybuk>   3 .gnu.hash     00000038  0000000000400678  0000000000400678  00000678  2**3
<Keybuk>   6 .gnu.version  000000c8  000000000040133e  000000000040133e  0000133e  2**1
<Keybuk>   7 .gnu.version_r 00000030  0000000000401408  0000000000401408  00001408  2**3
<Keybuk>  25 .gnu_debuglink 0000000c  0000000000000000  0000000000000000  0001b9d0  2**0
<keescook> http://sourceware.org/ml/binutils/2003-05/msg00741.html
<cjwatson> Keybuk: gnu.stack or gnu.attr, I believe
<cjwatson> the sections above are (afaik) innocuous for this purpose
<Keybuk> cjwatson: I don't see any binaries with that
<mdz> I also noticed I was unable to ^C fsck; I'm pretty sure that used to work ages ago
<Keybuk> do you have an example of one?
<cjwatson> the names have gone through an iteration or two
<mdz> Keybuk: did that change with upstart?
<cjwatson> not offhand; maybe wine or mono?
<Keybuk> mdz: yes
<mdz> Keybuk: is it a bug?
<cjwatson> it's a long time since I last looked at this
<cjwatson> warty or thereabouts
<Keybuk> mdz: it was kinda deliberate ;)
<Keybuk> cjwatson: mono hasn't
<mdz> Keybuk: I don't understand
<Keybuk> mdz: there is an unexplained difference in behaviour between Upstart and sysvinit when it comes to the ownership of /dev/consoe
<Keybuk> unexplained in that the code is identical, but produces different behaviour
<bryce> asac, I'll see if that may have some side effects
<ogra_cmpc> bryce, qfunk poked me about bug 211385
<ubotu> Launchpad bug 211385 in xserver-xorg-video-amd "please sync xserver-xorg-video-geode (main) from Debian (main)" [Undecided,New] https://launchpad.net/bugs/211385
<Keybuk> mdz: if Upstart gives sys-rc "ownership" of the console, then X will crash
<Keybuk> so "telinit 3" while running X becomes disasterous
<bryce> ogra_cmpc: me too
<ogra_cmpc> heh
<Keybuk> the identical code in sysvinit appears to be fine
<mdz> Keybuk: I don't see a bug open about it
<Keybuk> so to work around that, we don't give sysv-rc ownership of the console, instead we just put output to it
<ogra_cmpc> bryce, well, at least we'll always have his latest code that way :P
<Keybuk> mdz: I find filing bugs and assigning them to myself slightly eerie
<Keybuk> especially when I end up replying to my own comments
<mdz> Keybuk: I find a bug report a good place to record my thinking about a bug so that it's around for reference
<bryce> ogra_cmpc: do you have any issues with including it?
<ogra_cmpc> mdz, usplash breakage -> is your /etc/usplash.conf ok ?
<ogra_cmpc> bryce, not from my side, but i dont have the HW to test
<pitti> doko_: a dapper->hardy install has /etc/skel/.bash_profile, a fresh hardy install doesn't; is that deliberate?
<Keybuk> mdz: I use TODO lists for that
<mdz> ogra_cmpc: 1600x1200
<mdz> that's the same as my X session
<Keybuk> trouble is, it's a damned annoying bug to play with
<Keybuk> because the only way to test it is to repeatedly kill X :p
<Keybuk> (which is usually where one is editing the code)
<ogra_cmpc> mdz, ah, k, i recently saw it not working where someone had an empty file
<bryce> ogra_cmpc: thanks
<ogra_cmpc> Keybuk, thats what god lets grow virtual machines for :)
<ogra_cmpc> (or soren ...)
<Amaranth> i was gonna say screen plus vim/emacs (no wars here)
<mdz> Keybuk: ok to copy your remarks to the bug I'm filing?
<Keybuk> mdz: sure
<doko_> pitti: yes, that's .profile now
<pitti> doko_: ok, so that should be cleaned up on upgrade, I figure; I'll file a bug
<doko_> pitti: really, not only if it's unmodified?
<pitti> sure, only unmodified
<pitti> otherwise it shuold be renamed in preinst, then the user will get a proper dpkg conffile prompt
<doko_> ugly
<mdz> the default usplash timeout is 15 seconds, yes?
<mdz> it doesn't seem to be running for that long in total, much less between commands
 * ogra_cmpc has systems where it runs 90sec
<pitti> mdz: hm, hard to say; too many init scripts change the value
<mdz> pitti: but I'm talking about initramfs
<mdz> it's dead already when S01readahead is running
<tjaalton> bryce, asac: it would break 2D performance
<pitti> mdz: but yeah, the defautl is 15
<mdz> but it's running before that
<asac> tjaalton: for whom?
<tjaalton> asac: those who don't run compiz
<asac> tjaalton: for those that currently see black rectangles in firefox?
<asac> tjaalton: yeah. i think only those that don't use compiz see black rectangles where images should be
<Spads> and since ATI gets no more compiz...
<asac> i think every ati user except those running EXA have black rectangles without that option
<asac> but EXA wouldn't be hit by that i guess
<mjg59> asac: Given that we didn't have that as default in gutsy, what's changed?
<pitti> mvo: so, I reduced the dapper->hardy /etc diff to 173 KB
<asac> mjg59: images are scaled by X
<pitti> mvo: I'm through
<bryce> asac, -ati only, or also -fglrx or -radeonhd?
<asac> mjg59: at least thats what i understand (in cairo=
<ogra_cmpc> mjg59, firefox not only scales fonts alone anymore
<asac> bryce: fglrx as well
<asac> bryce: i think everything that uses normal XAA code
<keescook> Keybuk, cjwatson: we want readelf -l $EXEC | grep GNU_STACK not objdump.
<pitti> mvo: http://people.ubuntu.com/~pitti/tmp/dapper-hardy-etc.diff FYI; those are the bits which need to be fixed, but I didn't report bugs for yet
<keescook> actually, grep -A1
<asac> ogra_cmpc: it also scaled images in the past (just not the complete website) ... the difference is that cairo lets X do all the ground work
<ogra_cmpc> ah, i didnt know that
<mjg59> Ah, ok
<asac> we already have a hack because of that in cairo for this behaviour: http://people.ubuntu.com/~asac/corrupted1.png ... but i don't think that we can do something similar for normal images.
<bryce> hmm, my main desktop is -ati w/ XAA and no compiz, running current Hardy, and I'm not seeing that issue
<asac> bryce: really?
<ogra_cmpc> i saw it for a while, but havent seen any non classmate desktop since weeks ... i can go checking though
<asac> bryce: http://www.ubuntu.com/files/u3/desktop-tn.png
<asac> if i zoom that image in and out
<bryce> asac, ah yes
<asac> you see it?
<bryce> yep
<asac> good ;)
<mvo> pitti: thanks, I need to leave now, but will have a look later
<bryce> asac, ok, so I can reproduce the behavior, but I don't think this has impacted my day-to-day use of the machine very much ;-)
<asac> bryce: maybe you don't look closely
<asac> bryce: http://www.ubuntu.com/products/WhatIsUbuntu/desktopedition
<asac> the page has a black image for me (the one from above)
<asac> and thats just one click from ubuntu.com away ;)
<bryce> still, I don't think it's so serious that we should adopt a solution that isn't side-effect free
<asac> bryce: well. its a serious blocker for sure. you see black images on every second page out there
<asac> and performance looks not that bad ... in fact for me scrolling in ffox became faster now :)
<asac> bryce: i'd really like to try this and see what the response is ... except of doing nothing
<bryce> I've not seen that many black pages to be honest.  Maybe I overlooked them but I don't think so ;-)
<tjaalton> there's a reason we have the patch from fedora that is more clever than this option.. if I only could remember it
<asac> tjaalton: maybe the patch is what breaks it here?
<tjaalton> asac: could be, but dropping it would mean no compiz
<asac> bryce: you as me are probably not really the ones that care. but there are a lot of users that look more closely
<tjaalton> the upstream bug is marked as a blocker for X.org 7.4, so there should be a solution soon
<asac> i don't see those issues, but others are and if you cannot see the image you want to see you have a problem
<asac> tjaalton: which upstream bug?
<tjaalton> https://bugs.freedesktop.org/show_bug.cgi?id=13795
<ubotu> Freedesktop bug 13795 in Acceleration/XAA "RenderComposite with XAA renders at wrong position if vertically scaled." [Critical,New]
<tjaalton> the one that is attached to the bug :)
<asac> tjaalton: can you prod around to see what the state is?
<Keybuk> keescook: with the response being non-zero?
<Keybuk> ie. we should expect GNU_STACK in the output, but with all zeros ?
<Keybuk> (to mean not present)
<keescook> Keybuk: IIUC, it's the "RWX" at the end.  "RW" is non-executable.  I'm totally baffled at the moment.
<bryce> asac, the risk with these options is that sometimes flipping them on across the board can cause unexpected (sometimes major) issues on some chipsets
<Keybuk> wing-commander scott% readelf -l /sbin/init | grep -A 1 GNU_STACK
<Keybuk>   GNU_STACK      0x000000 0x00000000 0x00000000 0x00000 0x00000 RW  0x4
<keescook> sorry "E".  look at /usr/bin/gpg
<tjaalton> asac: pinged ssp
<asac> thx
<Keybuk> so gpg means "won't get read implies exec" ?
<keescook> right, I cannot understand how these processes have READ_IMPLIES_EXEC set.
<Keybuk> or means "read implies exec" ?
<keescook> gpg's means it WILL get read_implies_exec
<Keybuk> ok
<Keybuk> from this, it looks like Upstart *won't* get read_implies_exec
<keescook> right!  *bang head on desk*
 * Keybuk checks the shells ;)
<asac> bryce: thats true, but we will never know if we don't enable that by default ;)
<Keybuk> nope, no E there
<Keybuk> that would have been an obvious answer
<keescook> or things like acpid which I can gdb-attach to and see the r-i-e pers flag
<keescook> yet the executable doesn't have "E" in gnu_stack.
<asac> bryce: and from what i understand it removes logic that depends on chipset and does it in software with that option
<Keybuk> (gdb) p personality(0xffffffff)
<Keybuk> $1 = 4194304
<Keybuk> ?
<Keybuk> (gdb) printf "%x\n", personality(0xffffffff)
<Keybuk> 400000
<Keybuk> I see
<keescook> Keybuk: however, the kernel doesn't _clear_ that flag.  it only ever sets it.
<keescook> if GNU_STACK lacks "E", the kernel does _nothing_ to the flag.
<Keybuk> (gdb) printf "%x\n", personality(0xffffffff)
<Keybuk> [Switching to Thread 0xb7dd86b0 (LWP 8920)]
<Keybuk> 400000
<keescook> if GNU_STACK *has* E, the kernel *sets* it.
<Keybuk> that was a sleep inf spawned from upstart
<Keybuk> yes
<Keybuk> which is pretty conclusive that upstart has flag
<Keybuk> (while running)
<keescook> so if the kernel spawns init with READ_IMPLIES_EXEC, upstart will have it.
<Keybuk> indeed
<keescook> okay.  I feel sane again.
<Keybuk> wing-commander scott# readelf -l /usr/lib/klibc/bin/run-init | grep GNU_STACK
<Keybuk>   GNU_STACK      0x000000 0x00000000 0x00000000 0x00000 0x00000 RWE 0x4
<Keybuk> :-)
<Keybuk> there's your E
<keescook> \o/
<Keybuk> looks like all of klibc has it
<Keybuk> initramfs busybox *doesn't*
<Keybuk> so it comes from the klibc run-init that runs /sbin/init (which doesn't)
<keescook> okay, we need to fix that.  it's likely due to it have assembly routines that lack:
<keescook> .section .note.GNU-stack, ""
<keescook> in their .S
<Keybuk> sweet
<Keybuk> I'll leave that with you :)
<Keybuk> I have to leave an hour ago <g>
<keescook> okay, sounds good.  thanks for digging into this with me.
<Keybuk> no worries
<keescook> Keybuk: yay full circle.  klibc's author is hpa -- my fellow kernel.org admin.  *slap forehead*
<slangasek> tjaalton: why is  bug #120834 marked as 'invalid' for xserver-xorg-video-intel?  this appears to be a driver-specific X server crash?
<ubotu> Launchpad bug 120834 in mesa "intel gm965 freezes with 3d applications" [High,Confirmed] https://launchpad.net/bugs/120834
<mantiena-baltix> calc: hi, are you online ?
<tjaalton> slangasek: the dri driver is in mesa
<tjaalton> *from
<tjaalton> slangasek: btw, there's a mesa 7.0.3rc3 available ;)
<tjaalton> we have rc2
<tjaalton> +some fixes from the 7.0.3 branch
<slangasek> needs to go through the process, of course...
<calc> mantiena-baltix: yea
<tjaalton> slangasek: sure
<mantiena-baltix> calc: I'm backporting OpenOffice 2.4 to Ubuntu 7.10 (Gutsy), maybe you already did this job or maybe you already know someone, who are backporting ?
<calc> mantiena-baltix: haven't done it and don't know anyone working on it
<calc> mantiena-baltix: i still have lots of work to do on hardy's version in the next couple weeks
<calc> mantiena-baltix: plus i will be gone for about 5 days to a conference
<calc> mantiena-baltix: if you get it working if you want you can send me a debdiff and i will try to get the changes integrated
<blueyed> pitti: can you release virtualbox-ose-modules from NEW, or is there a problem with it?
<keescook> when did the dpkg FLAG changes go in?  I am nervous about klibc.  :P
<infinity> keescook: Do a local test build and boot with it?
<keescook> infinity: yup, going to shortly
<infinity> keescook: It builds in a matter of seconds on fast hardware. :P
<keescook> yeah, doing so now... was just wondering out "loud".  :P
<mantiena-baltix> calc: I almost finished the backport - look at https://edge.launchpad.net/~mantas/+archive/+builds?build_text=&build_state=all
<calc> 1:2.4.0-3baltix0 ?
<calc> looks like the build segfault on i386
<calc> in sbuild(?)
<mantiena-baltix> calc: yes, there was only one problem with hsqlsb amd64 build (it seems we should backport java-gcj-compat-dev) and also there are i386 ppa builder problems :(
<calc> ah ok
<calc> yea and mono package split is what is affecting lpia
 * calc notes backporting is fun :-\
<infinity> Okay, update-grub(8) spawning ucf just seems terribly broken...
<ogra_cmpc> hmm, why dont i have write access to devices i have mounted myself ... (or hal on behalf of me at least)
<jdstrand> pitti, tkamppeter: I was just testing the cupsys package on hardy, and found that /usr/share/cups/enable_browsing and enable_sharing are missing.  I don't see in the changelog why this happened.  Is this intentional, and if so is there an alternative I can use?
<lamont> infinity++
<slangasek> why bother, infinity++ == infinity
<lamont> meh.  let's just rename him aleph2
<infinity> slangasek: Thus proving that the only thing more awesome than me is... Me?
<slangasek> lamont: now you're thinking :-)
<slangasek> infinity: it just means that you're immune to scalar math :)
<ogra_cmpc> slangasek, that really depends who says it ... in a poetic way infinity++ is more :)
<slangasek> ogra_cmpc: try it with IEEE fp math ;)
<ogra_cmpc> :)
<mantiena-baltix> calc: maybe you know how I could solve i386 builder bug ? cprov told me, that I should remove the stuff in [] from the B-d - then i386 builder has a chance to work.
<infinity> slangasek: An odd immunity, to be sure, but I suppose things like chicken pox and the measels are passe.
<infinity> mantiena-baltix: I'm looking into the bug later today, but it's not going to be a quick fix.  Your best bet is the pare down a bunch of the build-deps that you don't actually need, yes.
<Mithrandir> lamont: renaming him aleph1 (or aleph2) would mean he was multiplied by himself.  I'm not sure I want to know about such things.
 * infinity makes a note to put "immune to scalar math" on his resume.
<lamont> Mithrandir: and there are anatomical challenges there
<slangasek> haha
<Mithrandir> lamont: LALALALALA
<Mithrandir> lamont: I see your lips move, but I can't hear what you're saying.
<lamont> Mithrandir: but if we made him aleph2, wouldn't that mean we'd cubed him?
 * lamont thinks of bullion.
<lamont> or would that be aleph3?
<infinity> I'm not entirely sure what being cubed entails, but it doesn't sound pleasant.
<lamont> slangasek: for giggles, do your next dput inside of a screen session on hardy, then figure out whether that's a dput bug or a screen bug...
<slangasek> I think I may have had enough giggles for one workday
<infinity> lamont: The suspense is killing me; what's it do?
<lamont> Uploading to mmj (via ftp to archive.mmjgroup.com):
<lamont>   postfix_2.5.1-2~gutsy1.dsc: done.
<lamont>   postfix_2.5.1.orig.tar.gz: done.                                     postfix_2.5.1-2~gutsy1.diff.gz: done.                                             postfix
<lamont> hrm.. that kinda cleaned up
<lamont> the dsc is indented 2 chars, the orig.tar.gz, 2 chars, the diff.gz?  -9 chars
<calc> mantiena-baltix: eh, that stuff is in the regular build so if that is causing the buildd to fails is really broken
<calc> mantiena-baltix: er i mean the buildd is really broken
<lamont> and the bottom of things says "... Succe\nfully uploadeded packages.\nNot running dinstall."
<calc> mantiena-baltix: buildds have supported foo [arch] build-deps for 8yr+ (afaik)
<lamont> calc: since forever, yeah
<elmo> calc: that's not the point
<calc> elmo: maybe i am missing something about the failure then?
<elmo> calc: oo.o's build-depends are a ridiculous size and between that and all the arch conditionals, it causes either a bug in sbuild or a bug in perl itself to trigger and segfault
<calc> elmo: ah
<elmo> debian's been seeing this for a while now on various arches (arms/mips)
<elmo> and now we're seeing it
<calc> mantiena-baltix: well you could manually edit the control file (its generated) to remove the parts not needed in build-depends
<calc> elmo: ah ok, i didn't know what he meant due to just removing the [] stuff
<calc> elmo: a too long string issue?
<calc> nice build-dep line is 6920 characters long
<slangasek> an unknown issue that causes perl to segfault
<mantiena-baltix> calc: btw, maybe you have a i386 gutsy system to build my backported ooo 2.4 ?
<slangasek> also, perl segfaulting because a string is too long == perl isn't good for much anymore, is it? :)
<calc> mantiena-baltix: nope, don't have a gutsy system here
<lamont> calc: and the binaries line length crossed with the log file size is it's own form of painful
<calc> mantiena-baltix: i have to make a chroot anytime i work with older releases
<calc> lamont: yea build log is a bit huge :)
<lamont> oo.o really needs to separate into more sensibly sized pieces...
<lamont> I mean, it makes KDE's packages look small
<lamont> and _they're_ rediculously large
<calc> a large chunk of it is translations
<calc> actually a very large chunk of it
<calc> 87MB of the diff, plus 81MB of the orig
<lamont> Build needed 15:22:23, 8080476k disk space
<lamont> 42MB of log
<calc> ah kde finally split up their i18n source package (it used to be fairly huge as well)
<slangasek> lamont: well, yes - there's a reason we have precisely one person each in Debian and Ubuntu who ever dare to build the damn thing
<lamont> yes.  and they still have a long way to go before they approach "sensibily packaged"
<lamont> slangasek: I think more than one person each builds kde.... :)
<slangasek> lamont: I meant OOo
<lamont> geg
<lamont> heh
 * lamont glares at the keyboard
<calc> hell OOo doesn't even follow the FHS
<lamont> or rational build process design
<slangasek> "hmm, let me think. I could spend 3 hours downloading the orig.tar.gz and 12 hours for each build iteration, or... I could let calc do it."
<calc> or choice of language *cough*
<slangasek> pythOOon
<calc> lets write lots of a already bloated app in java, yipee :\
<calc> especially when there is no free stable java available
<slangasek> now don't say that, you'll only encourage them to think what they're doing with OOo will be reasonable once there *is* free stable java available :)
<calc> 8 years after starting on OOo they may finally have a stable free java in the next year or so
<calc> its still crazy but at least might stop crashing every few minutes
<elmo> was my fstab meant to be converted to uuids?
<ogra_cmpc> elmo, in edgy, yes
<elmo> dapper -> hardy upgrade didn't
<ogra_cmpc> ouch, sounds like a bug
<elmo> it left me a nice fstab.pre-uuid file.  which err, is the same as fstab
<slangasek> yes, there's a bug on that
<elmo> \o/
<slangasek> er, or maybe not, that detail wasn't present in the bug I saw described
<elmo> slangasek: what package, if you know?
<slangasek> elmo: I think that's 209347 though
<slangasek> (from https://launchpad.net/ubuntu/+milestone/ubuntu-8.04
<slangasek> )
<elmo> thanks
<elmo> hmm, on second thoughts, I guess leaving the pre-uuid file around is probably considered a feature
<LaserJock> yeah, that would be handy if stuff blows up
<slangasek> maybe - but not switching to uuid is still a bug, and one that can render systems unbootable since dapper->hardy also crosses the libata transition
<slangasek> (for many controllers, at least)
<elmo> sure
<lamont> slangasek: "transition" is such a pretty word for "cluster" :-)
<elmo> I just don't use ATA in my servers ;-)
<slangasek> heh :)
<elmo> and whatever code that does this, loses the final newline on fstab </nitpick>
<seb128> pawalls: around?
<pawalls> seb128, yessir
<pitti> jdstrand: it's intentional indeed, since we do not need them any more
<pawalls> seb128, how can I help?
<jdstrand> pitti: can you elaborate?
<jdstrand> pitti: why not needed?
<pitti> jdstrand: if you still need the functionality, you need to do the conf file changes yourself
<pitti> jdstrand: system-config-printer and the cups webui do that in a much better way, without the need to restart the daemon, etc.
<seb128> pawalls: have you seen the patch I attached upstream today for the glib issue?
<seb128> pawalls: http://bugzilla.gnome.org/attachment.cgi?id=108556&action=view
<jdstrand> pitti: ok-- but is there no use case for cli only?
<jdstrand> (other than my testing script :)
<seb128> pawalls: it's the same idea than yours done in an easier way (no need to duplicate string and your code doesn't leak the string)
<pitti> jdstrand: they were not even in $PATH...
<pitti> jdstrand: originally I wrote them as backend for a gnome-cups-manager patch
<pawalls> seb128, Cool. Did you see what I mentioned about /.gvfs/ though?
<seb128> pawalls: s/doesn't//
<jdstrand> pitti: you thought a little thing like that would keep them from me?
<pitti> but we don't use that any more
<seb128> pawalls: right, looks to that now
<pitti> jdstrand: :)
<pawalls> seb128, Yeah.. I mentioned in a second comment that there would be memory leak with the g_strconcat unless you free it later :)
<seb128> pawalls: could you try my variant to make sure it's ok? I've a package ready to upload to hardy using it
<pitti> jdstrand: so, if you really need them back, I can add them again, but it's not an interface I want to keep forever, so I better wanted to drop them in hardy
<pitti> jdstrand: of course you are welcome to copy them into the qa-test branch :)
<jdstrand> pitti: yes, I was just thinking about that
<pitti> blueyed: certainly no problem
<jdstrand> pitti: ok thanks!
<pawalls> seb128, Sure, I will give it a go.
<seb128> pawalls: thanks
<pawalls> seb128, I think the gvfs line can just be removed entirely
<seb128> pawalls: which one?
<seb128> ah .gvfs
<pawalls> seb128, The one 4 lines above the one you patched.
<seb128> right
<pawalls> It's redundant and actually will show other users' mount on everyone's desktop
<pitti> blueyed: done
<blueyed> pitti: Thanks.. I was just wondering, because it was staying there the whole day, while other packages got processed.
<Riddell> calc: Debian still insist on packaging kde l10n as one huge tar, I've always refused to do so
<corevette> Who is the webmaster for Ubuntu.com?
 * ogra_cmpc wonders if its gvfs's fault that he cant cheat update-manager anymore with loopmounting isos under /cdrom
<ogra_cmpc> hrm
<pawalls> seb128, building and will get back to you shortly.
<seb128> pawalls: thanks
<LaserJock> corevette: kinda depends on what you're looking for but https://launchpad.net/~ubuntu-website
<calc> Riddell: oh
<tkamppeter> jdstrand, the /usr/share/cups/enable_browsing and enable_sharing are intendedly removed as system-config-printer and CUPS do this job by themselves now. KDE Printing Manager is patched to use these tools. The patch has to be changed to use the cupsctl command.
<calc> OOo source isn't that big ;-) 1.8G - OOH680_m12
<jdstrand> tkamppeter: ah cupsctl-- didn't know about that
<jdstrand> tkamppeter: so --[no-]share-printers is obviously for sharing, --[no-]remote-printers is for browsing?
<jdstrand> (I'm thinking so...)
<pawalls> seb128, Appears to work.
<pawalls> seb128, I also tested with removing the if /.gvfs/ conditional and that also worked.
<seb128> pawalls: well, .gvfs mounts should never be showed, so the if is wrong
<pawalls> seb128, Ahh.. I see.
<seb128> pawalls: but the g_unix_mount_is_system_internal (mount_entry) call before filter those out
<pawalls> Maybe all dirs beginning with a "." shouldn't be shown?
<pawalls> eg.. /home/$USER/.something
<seb128> I think there is some discussions upstream about that
<pawalls> Cool :)
<pawalls> seb128, It actually affects us now, but it's not nearly as big a problem as the home itself being shown.
<seb128> pawalls: you have automounts in the user directory too?
<pawalls> seb128, :)
<pawalls> seb128, snapshots
<seb128> pawalls: an another way would be to ignore autofs
<jdstrand> tkamppeter: thanks!
<pawalls> seb128, *nods*
<seb128> pawalls: do you think there is cases where autofs mounts should be displayed?
<pawalls> seb128, Not sure how we'd do that though
<pawalls> seb128, I can't think of any.
<pawalls> seb128, But I'm not sure how you'd find out if it was mounted by autofs.
<seb128> pawalls: what is the mtab line for a such mount?
<seb128> anything mentioning autofs?
<pawalls> seb128, Nothing in /etc/mtab or /proc/mounts makes it obvious.
<seb128> hum, k
<seb128> ok, one issue at time
<seb128> I'll upload this fix for now
<pawalls> seb128, Yeah
<pawalls> seb128, This patch already makes it heaps better.. and also that we're not showing all directories in /home anymore.
<pawalls> seb128, Whatever patch you made to restrict it to /media and /home/$USER really improved things significantly.
<pawalls> seb128, Before that, the desktop was just completely unusable.
<seb128> pawalls: well, the change is the function we are tweaking since yesterday ;-)
<pawalls> seb128, Yep
<seb128> I think the media thing is good enough
 * pawalls nods.
<seb128> we might want a way to let user not show mount in their directory too
<ogra_cmpc> ++
<seb128> ie, filtering those using .directory for example
<pawalls> seb128, Yeah
<seb128> but I think that's a less common usecase
<pawalls> seb128, Perhaps just a gconf setting for manual blacklist?
<seb128> not easy
<seb128> glib is way under gconf in the stack
<pawalls> glib doesn't depend on gconf I suppose.
<pawalls> Yeah
<pawalls> seb128, Anyway thanks again. What we have now is a great improvement.
<seb128> pawalls: you are welcome!
<ogra_cmpc> seb128, i think mounting in homedir is only relly annoying for developers ...
<pawalls> seb128, And I'll try to sticking around on IRC in case you have any questions. Feel free to poke me whenever.
<seb128> pawalls: ok, thanks
<ogra_cmpc> (i found more than 280 nautilus windows one day after running unattended buildscripts in my home tht loop mount stuff)
<elmo> how is there not a bug for this bash completion promptage?
<ogra_cmpc> i guess general users might appreciate the feature
<pawalls> ogra_cmpc, :)
<seb128> ogra_cmpc: might still need some tweaking, for example loop mounts should be ignored
<pawalls> seb128, I think the way it used to work is that all nfs mounts were ignored.
<pawalls> seb128, Which is I suppose why it didn't affect us in Gutsy.
<ogra_cmpc> seb128, well, at least as long as you need root anyway to mount it ... if you can mount them by doubleclicking an iso for example, the i'd disagree
<ogra_cmpc> but i think that still defaults to fileroller if i'm not wrong
<elmo> oh, there is, nm
<seb128> pawalls: gnome-vfs seems to be something interesting
<ogra_cmpc> ah, no, it defaults to n-c-b
<seb128> pawalls: it looks if the device_path is starting by "(pid" and classify those as autofs apparently
<Ibycus> hello, anyone here know where i would go to offer an opinion on ubuntu hardy ui?
<seb128> pawalls: ups, not starting
 * lamont will upgrade his laptop tonight and see if he can get more info for bug 210792
<ubotu> Launchpad bug 210792 in consolekit "no sessions after logging in" [Undecided,New] https://launchpad.net/bugs/210792
<seb128> pawalls: just if there is a (pid there
<seb128> Ibycus: try the forum maybe?
<Ibycus> seb128: ok, will do
<Ibycus> seb128: a particular subboard?
<seb128> Ibycus: no idea about that one
<Ibycus> ill have a look
<Ibycus> seb128: ill put it here: http://brainstorm.ubuntu.com/
<cjwatson> Mithrandir: (aleph0)^2 is still aleph0 - to get a higher order, you need to raise something to the power of aleph0
<pawalls> seb128, Ah.. interesting.
<cjwatson> (number-theoretic pedantry 'r' us)
 * slangasek grins
<keescook> doko: are you around?  I'm trying to sort out some note.GNU-stack/GNU_STACK issues when linking.  I have an "E" GNU_STACK that I can't find the origin of...
<keescook> (or anyone else...)
<ion_> âµâ
<slangasek> shouldn't that be âµâ° ?
<doko> keescook: sorry, have a conference call
<keescook> doko: okay, no problem.
<ion_> slangasek: Wikipedia doesn't seem to think so.
<slangasek> ok
<cjwatson> slangasek: it's usually subscripted, or at least was when I was studying number theory
<cjwatson> presumably to avoid confusion with exponential notation
<slangasek> fair 'nuff, it's been a long time for me so I suppose I was just misremembering :)
<cjwatson> of course, what we *don't* know is whether 2^âµâ == âµâ ...
<jdong> *grumble* ACPI mWhr discharge rates are estimated from mAh battery capacity decrease, isn't it...
<jdong> stupid sanity
<RAOF> cjwatson: Well, we do, kinda. We know 2^âµâ == âµâ is independent of ZFC :)
<cjwatson> RAOF: I think that's an extremely weak form of "know". :-)
<mdke> hi cjwatson, do you have a moment?
<cjwatson> mdke: sure
<ScottK> slangasek: I just uploaded the unforked version of SE Linux setools.  It will need to get looked at for binary New.  I'm pretty sure I did the transitional packages right, but ...
<slangasek> ScottK: ok
<calc> grr
<calc> getting these icon themes working properly in OOo is pita :\
<Riddell> calc: did you look at the issue with the livefs builds?
<keescook> doko: I'm trying to understand the live cycle of .note.GNU-stack into GNU_STACK bits.
<keescook> at what point does the GNU_STACK get set?
<doko> keescook: tbh, I didn't look at this after making it the default for edgy(?)
<keescook> doko: this isn't related to -fstack-protector
<keescook> that's entirely a code-generation and libc issue
<keescook> this is related to how gcc/as mark the GNU_STACK section.
<keescook> (as executable or not)
<bryce> hey kees, with latest hardy I notice xsane no longer detects my scanner, except when run as root
<keescook> bryce: perhaps a udev rule is needed?
<bryce> keescook: (which it didn't require on gutsy).  Is this some security thing?
<keescook> bryce: nothing I did explicitly.
<bryce> ok, strange
<bryce> maybe xsane needs gksu now?  hmm
<doko> .note.GNU-stack notes are emitted by the compiler, for assembly you have emit these yourself, for the rest, I'll have to look myself
<keescook> bryce: check the ownership of the device nodes, etc compared to gutsy
<bryce> unfortunately I no longer have gutsy around for checking
<keescook> doko: right.  I'm now emitting these in klibc, but the final (shared) link still gains GNU_STACK with "E".
<keescook> even though every component being linked in either has the note or doesn't have "E" in it's GNU_STACK.
<calc> Riddell: it was just a ooo-l10n wasn't built until this morning issue
<calc> Riddell: it wasn't installable on hardy yesterday either
<calc> Riddell: at least i am 99% sure that was what the problem was with livefs
<keescook> if you have a moment (it's quick to build), can you build klibc on i386 with this patch: http://launchpadlibrarian.net/13099228/klibc_1.5.7-4ubuntu2.debdiff
<Riddell> calc: ah, sorted
<keescook> doko: then I can show you what I've scratching my head about.  :)
<keescook> s/I've/I'm/
 * calc thinks he found why it doesn't fall back to the right theme properly
<tedg> keescook: BTW, do you know somewhere I could post to ask more about that FF linker bug?  I'd like to figure it out, but I don't know where to go.
<keescook> tedg: I don't.  My linker go-to guy is doko.  :)  Perhaps ask asac for pointers to devel channels/mailing lists?
<asac> tedg: which FF bug?
<tedg> asac: Sorry, not as much a bug, as I can't seem to link with the gnome-keyring plugin :(  https://launchpad.net/~ted-gould/+archive/+build/542813
<asac> tedg: what are you trying to do ;)?
<tedg> asac: It seems to be something with the linker.  If I link in "-lgnome-keyring" it fails, but "/usr/lib/libgnome-keyring.a" succeeds.
<tedg> asac: Make all the authentication tokens for FF be in gnome-keyring.
<kirkland`> evand: cjwatson: i'm curious if either of you guys have an opinion on https://bugs.launchpad.net/ubuntu/+source/partman-basicfilesystems/+bug/82351
<doko> keescook: built, but I made the mistak to look at the current glibc build logs :-/
<ubotu> Launchpad bug 82351 in partman-basicfilesystems "support for swap files" [Wishlist,Confirmed]
<keescook> heh
<asac> tedg: where is that gnome-keyring/ code from?
<tedg> asac: Mozilla bugzilla.
<keescook> doko: yeah, it builds, and it's certainly different (libklibc correctly lacks "E" in GNU_STACK)  the problem seems to be the utils, which strangely all still have "E"
 * tedg tries to say that 10 times fast 
<kirkland`> evand: cjwatson: i assume it's not something worth pursuing in hardy, due to the fact that it's probably just a minor annoyance and the bug has gotten no attention ;-)  but is it something worth pursuing in Intrepid?
<asac> tedg: bug id?
<tedg> asac: https://bugzilla.mozilla.org/show_bug.cgi?id=309807
<ubotu> Mozilla bug 309807 in Password Manager "Integrate Password Manager with Gnome Keyring Manager" [Enhancement,New]
<asac> tedg: 1st. try to apply that to xulrunner-1.9 instead of firefox
<tedg> asac: Okay, what's the difference?
<asac> tedg: not sure. everything is hidden nowadays ;)
<asac> ++-4.2 -o GnomeKeyring.o -c -I../../dist/include/system_wrappers -include ../../config/gcc_hidden.h
<asac> try to remove that business by hand and see if the link then succeeds
<asac> the include of gcc_hidden.h i mean
<asac> i currently don't understand why it doesn't see the symbols in libgnome-keyring because of that, but i guess its due to that mechansim
<asac> tedg: why are you working on that now?
<cjwatson> kirkland`: I've seen it, but it's a fair amount of work
<kirkland`> cjwatson: okay, thanks, i was just curious
<asac> tedg: https://bugzilla.mozilla.org/show_bug.cgi?id=309807#c4
<ubotu> Mozilla bug 309807 in Password Manager "Integrate Password Manager with Gnome Keyring Manager" [Enhancement,New]
<cjwatson> I've updated the bug
<asac> tedg: that makes this solution unfeasible for prime-time (which is most likely the reason why nothing has landed and no review has been requested.
<keescook> doko: any thoughts or things I should try?
<tedg> asac: Working on proving out some ideas on getting Firefox and the desktop to work together.
<asac> tedg: first start working with me ;)
<tedg> asac: Yes, that is a problem.  I'll have to see if it is feasible to work around.
<tedg> asac: Heh, I didn't mean to work around you.  I just thought this was going to be an easy "drop in and see if it works" type of thing....
<asac> tedg: yeah, but it isn't.
<asac> firefox 3 and gnome-keyring is only possible in an ugly fashion :)
<asac> we thought about a solution for epiphany for that ... but now that they give up on gecko, there is no point to investigate further ;)
<tedg> Well, the nice part is that the Webkit integration is already done.  So really they're ahead on it.
<doko> keescook: please let me look at it tomorrow, I do have the build at least now
<Riddell> tkamppeter: have you looked into backporting the libpaper patch change in ghostscript to 7.10?
<asac> tedg: webkit + keyring integration?
<asac> ok
<calc> doko: ping
<calc> doko: i have something for you to look at (small bit of code) to see if i am reading it correctly
<keescook> doko: okay, cool -- thanks!
<asac> tedg: we will land a gconf integration for proxy stuff in the next days
<asac> tedg: i think we cannot do much more for hardy
<asac> and for intrepid we can discuss at UDS.
<asac> I am open to any new idea ;)
<TheMuso> What is the default debconf priority for a dapper install supposed to be? High?
<cjwatson> high, yes
<TheMuso> cjwatson: Right, I'm trying to reproduce that libssl bug, with no luck so far...
<tkamppeter> Riddell, no I did not come to this idea.
<Ng> tjaalton: does the led-enabled iwl driver work ok for you?
<seb128> Ng: I'm not sure your printer issue is a poppler one
<Ng> seb128: oh?
<seb128> Ng: pdftops in poppler-utils generates a ps which looks correct
<seb128> Ng: using evince to print the ps is correct too but I've some fonts issues apparently
<seb128> Ng: I think the way evince works is that it renders the pdf using poppler and then use gtk to print
<Ng> seb128: ah, so it could be gtkprint?
<seb128> Ng: yes
<Ng> hmm
<seb128> Ng: well, how do you try printing?
<Ng> seb128: the PS files were produced with the Print To File printer in the evince print dialog
<seb128> Ng: do printing to a ps and using lp on the ps crashes the printer?
<seb128> s/do/does
<Ng> seb128: afair feeding the hardy ps on the bugreport to lpr will crash the printer
<seb128> Ng: could you try to pdftops the pdf and try to send this ps to the printer?
<Ng> seb128: I will wait for a quiet time in the office tomorrow and test
<seb128> Ng: ok, thanks
<seb128> Ng: might be https://bugs.launchpad.net/ubuntu/+source/gtk+2.0/+bug/151145
<ubotu> Launchpad bug 151145 in gtk+2.0 "Evince print fails with Postscript driver" [Critical,Incomplete]
<Riddell> cjwatson: tranlations on partition types works well
#ubuntu-devel 2008-04-04
<Roey> bryce:  heya Bryce, Jonathan Riddell referred me to you.  I had a question about this set of modules for the Linux kernel and X for accelerating 2d and GL for KVM and Xen guests (it's called "VMGL"); I was wondering if and when it will get incorporated into the next version of Ubuntu.  Its home page is here: http://www.cs.toronto.edu/~andreslc/xen-gl/
<Roey> Riddell:  thanks
<bryce> Roey: I hadn't heard of this prior to now.  Is there a bug id# open about the current status of it?
<bryce> Roey: if it isn't already in debian, then the first task would be to get it packaged
<Roey> ok
<Roey> it's just a project page so far, as far as I know--they had a paper about this for some conference back in '07
<Roey> and they have tarballs and rpms
<Roey> (just not an ubuntu module, yet)
<bryce> I see it is at version 0.1, which sounds pretty immature
<Roey> bryce, and I haven't checked yet about any submission as a bug id
<Roey> ok
<bryce> Roey: have you tested it?  does it do what it claims?  Or is it still early on in development?
<Roey> bryce:  right, right, it's rather embryonic
<Roey> bryce:  I just found out about it.
<bryce> gotcha
<Roey> bryce:  in #ubuntu+1,
<Roey> there's this one guy who -has- tried it and says it works for him
<bryce> ok, so step #0 is verify it does work on ubuntu and does something useful.  ;-)  #1 after that would be packaging it, and upload to universe
<Roey> his nick is h3sp4wn; he should be here momentarily (if he's at his computer)
<Roey> ok
<Roey> bryce:  ok
<Roey> bryce:  which archs must it be compiled for in order to submit to universe?
<bryce> once it's had time in universe to get tested, continue development, and is felt to be well polished and useful, then main inclusion can be considered (which requires some code review, security analysis, etc.)
<Roey> right right
<Roey> but you gave me what I was looking for, which is a roadmap
<Roey> thanks
<bryce> in the packaging you'll specify which arch it works in.  so as long as it works for one arch, that should be ok
<Roey> ok
<bryce> i.e., there's an arch field in debian/control
<Roey> ah, got it
<bryce> if it works on i386, that would be a good start
<Roey> hrm, that'd require me to compile a different kernel in that case
<Roey> (using a quad-core intel core here)
<Roey> q6600
<bryce> Roey: I suspect amd64 would be fine too, although you'd probably get better testing coverage if there's an i386 package.  Maybe that could come later after it's in universe though.
<Roey> do you mean i386 and not i686
<Roey> ?
<crimsun> ia32 (32-bit) vice amd64 (64-bit)
<rhineheart_m> when will be the hardy be released?
<TheMuso> rhineheart_m: http://wiki/ubuntu.com/HardyReleaseSchedule
<rhineheart_m> TheMuso, are you sure with the link you've provided. It seems that it is redirected to www.wiki.com
<slangasek> that was meant to be http://wiki.ubuntu.com/HardyReleaseSchedule
<rhineheart_m> april 24?
<slangasek> yes
<rhineheart_m> what is Intrepid Ibex? Is it a LTS also?
<slangasek> it's the next release after hardy; there are no plans for it to be an LTS, no
<rhineheart_m> just like the gutsy gibbon?
<slangasek> I expect it's going to be a release with an 18-month support cycle if that's what you mean, yes
<rhineheart_m> slangasek, what's the difference for heron from gutsy? Is it also a good version for server?
<slangasek> rhineheart_m: I think you might find that #ubuntu is better suited to answering these questions for you; this channel is for development of Ubuntu
<rhineheart_m> oaky.. thanks.. no plans yet to include webmin again to repo as it has been updated by the author already?
<slangasek> LTS is more likely to be deployed on servers than regular Ubuntu releases due to the longer support cycle, but I couldn't tell you how much more likely
<slangasek> webmin isn't going to be included in hardy, no
<rhineheart_m> any projected available web based GUI for hardy?
<TheMuso> slangasek: thanks. Slip of the cold finger.
<slangasek> rhineheart_m: ebox is included in universe for hardy.
<rhineheart_m> slangasek, how I wish a better web based GUI will be included that could handle multiple sites configuration... just like ISPConfig
<Riddell> siretart: the problems I was having playing DVDs were because I havn't set the region
<sigger_> I wrote up a little feature proposal on the wiki and created a Launchpad proposal for it.  What is the next step?
<bryce> url?
<sladen> sigger_: get it ready for the next UDS
<bryce> next step is usually for me to review/approve it
<bryce> er whoops!
<bryce> sorry thought this was #inkscape.  nevermind me
<bryce> sigger_: next step is to get it approved by mdz.  ;-)
<sigger_> hehe, np bryce
<sigger_> sladen: well, I unfortunately am not in a position to actually code it.
<Caesar> Has anything changed lately with the alternate installer that would make uuid-runtime no longer be installed by default?
<Caesar> I'm not sure what to look at to try and figure it out myself
<sigger_> sladen: If I leave it be, will is it in queue for someone to look at it, or do I need to take a further action to propose it?
<sigger_> s/will/
<sladen> Caesar: do you mean "I have tried to install using the alternate and found a possible bug with by-UUID not working on $this machine"?
<sladen> Caesar: things won't have intentionally changed to break something that previously worked
<srbaker> folks
<srbaker> i just installed hardy beta on a laptop that wouldn't install previous versions without screwing around.
<srbaker> where am i supposed to report my successes?
<_MMA_> srbaker: #ubuntu-testing can help.
<srbaker> okay
<srbaker> thx
<slangasek> keescook: can I blame you for strace failing to sensibly detach anymore on ^C?
<slangasek> ... and tricking me into breaking my own gnome-session when I was looking at bug #58171
<ubotu> Launchpad bug 58171 in gnome-session "Connection to ICE-unix/.. socket times out so programs take minutes to start" [Medium,Confirmed] https://launchpad.net/bugs/58171
<Erickj92> is the the appropriate channel to ask for help while programming under GNOME?
<jcastro> Erickj92: nope, try #gnome on gimpnet
<Erickj92> jcastro, what is the exact address?
<Erickj92> for gimpnet?
<jcastro> irc.gimp.org
<Erickj92> ok, thank you
<calc> does anyone know why totem won't play m2t files anymore?
<pwnguin> does anyone know what an m2t file _is_?
<calc> mpeg-ts
<calc> mpeg transport stream
<calc> ie what a dv/hdv camera spits out from dvgrab
<pwnguin> Bdoh
<calc> it used to work from what i recall, but gives me an error now
<calc> even with the fluendo mpeg-ts plugin installed
<RAOF> That was what I was going to ask next :)
<calc> i'm doing a full update to see if anything helps
<pwnguin> does vlc/mplayer handle the file?
<calc> haven't tried yet, just tried after haven't used it in a few months
<calc> ** Message: Error: Failed to connect stream: Invalid argument
<calc> error isn't very useful, will try mplayer
<calc> and note it doesn't tell me i need to install a different package to play it which totem normally does(?) if it can't play the file
<pwnguin> you can up the debug level
<calc> pwnguin: what argument do i use?
<pwnguin> i forget. but the manpage knows
<calc> i wonder if it doesn't want to play because its too high res for my screen
<pwnguin> oh
<pwnguin> that reminds me to file a bug
<calc> mplayer isn't playing it either
<calc> but it says no suitable res found
<calc> its 1920x1080 video on a 1280x800 laptop :\
<pwnguin> totem will make its window larger than the screen if it plays a song that has lyrics embedded in it
<calc> is there a way to make mplayer shrink its video output to say 1/4 original size?
<pwnguin> im sure mencoder can do it ;)
<calc> ah scale
<calc> hmm well i'll mess with it later seems it doesn't like my laptop much
 * calc bbl :\
 * lamont grumbles at doko for uploading an nmap with half a fix, and no bug in any bug-tracking system
<keescook> slangasek: haha, no, I can't claim that one.  blame the crappy PTRACE interface in linux.  ;)
<slangasek> keescook: has it somehow gotten crappier recently?
<lamont> hrm.. given a bug in the debian bts, is there a trivial way to import that to launchpad?
<Caesar> sladen: no, I mean previously the uuid-runtime package was installed by default with the alternate installer, and it appears to no longer be
 * lamont points slangasek at the other window. :-)
<tjaalton> Ng: it seems to work, but I haven't used it much yet
<slangasek> lamont: the...one I replied to?
<lamont>  /query here, and I didn't get your answer... prairie-net for the win
<slangasek> lamont: ... right before you disconnected? :)
<bd_> https://bugs.launchpad.net/ubuntu/+source/git-core/+bug/196846 Would it be possible to have someone with main uploader privileges look at this bug? It's an RC (high) bug for hardy, and a trivial patch is available. It would be a shame for gitk and git-gui to be broken in hardy's release, and the deadline's coming up...
<ubotu> Launchpad bug 196846 in git-core "gitk requires wish8.5 but depends on tk8.4" [High,Confirmed]
<lamont> did not.  my ISP did
 * lamont plans to upload nmap_4.53-3 and request a sync for 211666
<slangasek> Caesar: do you have an opinion on bug #90681? :)
<ubotu> Launchpad bug 90681 in dhcp3 "resolv.conf overwritten using VPN/PPP etc..." [Medium,Confirmed] https://launchpad.net/bugs/90681
<Caesar> slangasek: looking
<Caesar> slangasek: while we're at it, what about #203723 ?
<Caesar> slangasek: the problem with DHCP, is there's about three different ways that /etc/resolv.conf can be managed
<Caesar> So just dicking with /sbin/dhclient-script addresses one vector for /etc/resolv.conf getting messed with, but not all of them
<Caesar> and I hate the way NetworkManager (ab)uses dhclient
<Caesar> But this is the first I'd heard of this issue (makes perfect sense though). Why hasn't it been forwarded up to Debian?
<slangasek> Caesar: because there's not enough warm bodies to have someone watching the dhcp3 package in Ubuntu, I imagine
<slangasek> Caesar: is resolvconf a good solution for this, generally?  It seemed to be making headway in Debian, and now it isn't
<slangasek> Caesar: 203723> looks straightforward to fix, so it must really not be
<pitti> Good morning
 * slangasek waves
<laga> slangasek: can you please merge r1287 from http://bazaar.launchpad.net/%7Emythbuntu/debian-cd/mythbuntu-debiancd/?
<siretart> good morning!
<dholbach> good morning
<pitti> mjg59: hm, for bug 162654, maybe it's best to revert the network unloading for now?
<ubotu> Launchpad bug 162654 in pm-utils "networkmanager (0.6.5-0ubuntu16.7.10.0) needs to be restarted manually after suspend using pm-utils, while functioning correctly using acpi" [Undecided,In progress] https://launchpad.net/bugs/162654
<Silicium> heyho
<Silicium> there are some intoduction for creating debootstrap scripts
<Silicium> i only want wo install some packages (around 10) over debootstrap
<warp10> Good morning
<pitti> hi warp10
<warp10> hey pitti!
 * pitti looks at mvo, wondering what the libpri1.2 transitional package is all about
<pitti> mvo: that's just a library, isn't it? why do we need a transitional library package?
<mvo> pitti: some strangness in the asterisk package
<pitti> mvo: but, but... any details? this looks crackful
<mvo> pitti: I need to recreate the situation again, if you don't like I can look for a different fix. libpri1.0 claims a conflict on 1.2
<pitti> mvo: oh, I don't want you to do pointless work, I'm just trying to understand the ratinoale for this oddity
<pitti> oh, a conflict?
<pitti>  Conflicts: libpri1.2 (<< 1.4.0-3)
<pitti>  Replaces: libpri1.2 (<< 1.4.0-3)
<pitti> mvo: weird that a transitional package changes that in any way
<pitti> mvo: well, apt is your mystery :)
<mvo> yeah, then the package gets removed in hardy and
<mvo> that confuses it. the alternative is to remove the conflict
<mvo> I guess that is cleaner especially because there isn't really a conflict AFAICS
<pitti> mvo: unless they conflict on the soname symlink? /usr/lib/libpri.so.1
<mvo> meh, yeah
<mvo> I knew there was a reason
<pitti> mvo: the package name is wrong then, it should just be libpri1
<pitti> which Conflicts/Replaces/Provides libpri1.2 perhaps?
<pitti> if it didn't change ABI
<pitti> and if it did, then the SONAME is still wrong
<pitti> mvo: so, please don't get me wrong, not trying to cause trouble, but it doesn't feel like this would even be a working hack...
<pitti> since we have no guarantee that the transitional package is installed first
<pitti> oh, wait, that's what the conflicts is doing, nevermind
<mvo> the transitional package does work, I tested it in a dapper chroot, makes both aptitude and apt happy.
<cjwatson> Caesar: uuid-runtime seems to be optional (both according to the changelog, and according to Debian priorities); I made casper depend on it, but I wonder if we need to install it by default
<cjwatson> of course it's arguably inconvenient to deal with UUIDs without it ...
<pitti> mvo: ah, ok; well, *shrug*, I'll accept it, but the broken SONAME will likely cause more trouble in the future
<mvo> pitti: right, I don't think there is a debian bugreport about this yet, I will create one
<pitti> mvo: that'll do, thank you! (please make it serious, it's a gross violation of library policy)
<mjg59> pitti: I'm looking at it
<pitti> mjg59: good morning! thanks
<pitti> mjg59: btw, which TZ are you in ATM?
<mjg59> London
<pitti> aah; I was afraid it was Boston and you're up that long :)
<pitti> Riddell: *chuckle* removal of adept from Debian: "ROM, broken beyond repair" -- that's certainly a different adept then?
<pitti> doko: gcc-4.0 was recently removed from Debian; no rdepends in hardy AFAICS; I assume I can remove it from Hardy as well?
<doko> pitti: no, we still build gcc-3.4 on hppa
<pitti> doko: and that needs gcc-4.0?
<doko> libgcc2 is built from gcc-4.0
<pitti> oh, I should reenable ports in checkrdepends
<doko> hppa is too much broken for this
<pitti> ok, then I leave it for now *shrug*
<\sh> damn....what do I need to do to enable pulseaudio again? seems like it's not started anymore since one or two last updates
<\sh> starting manually fixed it ;)
<pitti> \sh: system -> settings -> audio -> software mixing?
<\sh> pitti, when I would find it, hopefully ;)
<\sh> I have system -> preferences -> default soundcard (which is set to PA) and system -> preferences -> sound (all needed output/input stuff is set to PA too).
<\sh> but session manager doesn't start PA automatically anymore
<pitti> \sh: do you have system -> settings -> audio -> "Klaenge" -> "Mix sounds with esd"? that triggers pulse
<\sh> ah...there
<\sh> that was disabled
<\sh> so you need to enable "ESD" to start pulse automatically?
<pitti> geser, doko: hm, atlas3 was removed from debian with "RoQA; NVIU; RC-buggy; obsolete g77 package", but we still have a lot of rdepends; is our transition not complete yet? is that something to be concerned with?
<doko> pitti: no, we need to keep the g77 based packages, IMO
<pitti> ok
<Riddell> pitti: hrm, where do you see that?
<pitti> Riddell: in process-removals
<pitti> asac: can you please have a look at the firefoxish bits of "binary-only demotions" on http://people.ubuntu.com/~ubuntu-archive/component-mismatches.txt and tell me what I should demote, and what should be seeded?
<asac> pitti: looking
<seb128> pitti: bug #211569 is something you might want to look at
<ubotu> Launchpad bug 211569 in xsane "xsane won't start unless run as root (Epson Perfection 1240)" [Medium,Confirmed] https://launchpad.net/bugs/211569
<pitti> seb128: libglib2.0-data certianly needs to become a Depends: of something?
<asac> pitti:  i don't understand taht page
<asac> what does "Binary only demotions to universe
<seb128> pitti: why?
<asac> " mean?
<pitti> asac: those are the binary packages which are not dependencies of any main package
<asac> firefox-themes-ubuntu -> universe
<seb128> pitti: it has only translations and we stip those
<pitti> asac: they either need to be seeded to stay in main, or become a dependency of a main package, or dropped to universe
<seb128> pitti: s/stip/strip rather ;-)
<pitti> seb128: ah, ok; so I can demote it then?
<seb128> pitti: yes
<pitti> seb128: thanks
<asac> pitti: everything that is firefox-3.0* is main
<seb128> pitti: hum, wait
<seb128> pitti: ok, that's alright
<asac> same for everything just firefox* .... firefox-granparadiso and firefox-trunk bits are transitional packages (they could stay in universe, but are from the same source as the firefox-3.0 bits)
<seb128> pitti: I was just checking that it doesn't contain the copyright, etc for the other binaries too
<cjwatson> could somebody with a thinkpad fingerprint reader look at bug 208668, please?
<ubotu> Launchpad bug 208668 in thinkfinger "sshd core dumps while trying to connect with a password" [Undecided,Incomplete] https://launchpad.net/bugs/208668
<pitti> asac: cdbs shouldn't do that if there is no depends:, thanks for checking
<seb128> pitti: that was for me I think ;-)
<pitti> right, sorry
<seb128> you are welcome ;-)
<asac> pitti: huh?
<pitti> asac: so they need to get seeded then?
<asac> seeding like on CD?
<pitti> cjwatson: I only have a Dell fp reader, but it also uses thinkfinger; I can try it a bit later
<Silicium> cjwatson: iam
<pitti> asac: just to supported, I guess
<Silicium> cjwatson: i have the T32
<Silicium> T43
<asac> pitti: ah. right. i can do that. can we keep parts in universe?
<pitti> asac: so those are transitional packages for universe and thus should go to universe? firefox-granparadiso firefox-granparadiso-dom-inspector firefox-granparadiso-gnome-support firefox-trunk firefox-trunk-dom-inspector firefox-trunk-gnome-support firefox-trunk-venkman
<asac> i'd like to keep -dom-inspector and -venkman in "unsupported"
<seb128> cjwatson: just curious but do you know if there is an known issue about scp upload speed being on crack? it tends to go to 100% really quickly when I scp to rookery for example and display a speed which is much faster than my dsl line and then stay stucked for a while which is likely the real upload still running
<pitti> asac: yes, we can have only some in main
<asac> pitti: yes right.
<pitti> asac: hm, that basically means that all of the listed ones can go to universe?
<asac> pitti: ok, we can basically push everything to universe
<asac> that is in that list
<asac> yes
<pitti> cool, thanks
<asac> the ones that are not transitional are venkman and -dom-inspector
<asac> and they are not supported
<asac> pitti: so nothing to do from my side?
<pitti> asac: no, I just wanted to ask you which we want to support
<asac> ok thanks
<seb128> pitti: btw did you read the xsane bug number I gave you in the same time you asked about the glib data demotion?
<pitti> seb128: yes, I'll look at it
<seb128> pitti: ok, cool
<asac> vim is not supported?
<asac> hmm
<ogra_cmpc> pitti, could jockey not display a descriptive message if linux-image and l-r-m are out of sync (running a test of which versionns are available before it even fires up the package installer which will then fail with error)
<asac> pitti: i see that libmozjs-dev libxul-dev xulrunner are bin only promotions to main ... can we hold that back?
<asac> pitti: we have to kick moblin folks to migrate mobile-basic-flash to xul 1.9
<cjwatson> seb128: not afaik
<cjwatson> seb128: or rather if it is it was too confused to be actionable
<seb128> cjwatson: ok, what informations would be useful in case I would like to open a bug about the issue?
<seb128> cjwatson: that's only a detail and I'll try to see when it does it, etc
<asac> pitti: ill talk to bob
<pitti> asac: no, those are source/binary promotion, and I don't want to promote xulrunner
<asac> pitti: ok. good. just don't promote the xulrunner binary ;)
<cjwatson> seb128: scp -vvv output, ideally with some indication of anywhere it hangs for a long period
<seb128> ok
<seb128> the estimation seems to be wrong for small files, I need try again to make sure
<pitti> seb128: I triaged that bug
<mjg59> pitti: Re: 162654 - I'm somewhat confused about what the problem is here. Is it just that we're not bringing interfaces back up on resume?
<asac> bug 162654
<ubotu> Launchpad bug 162654 in pm-utils "networkmanager (0.6.5-0ubuntu16.7.10.0) needs to be restarted manually after suspend using pm-utils, while functioning correctly using acpi" [Undecided,In progress] https://launchpad.net/bugs/162654
<seb128> pitti: cool
<pitti> mjg59: yes; rmmod'ing them tears down the ifaces, and thus you need a /etc/init.d/networking restart to ifup all of them again
<mjg59> pitti: If so, I think we probably just want the logic from acpi-support
<pitti> asac: promote xulrunner binary> over my dead, cold body :) (lib duplication)
 * asac hugs pitti 
<mjg59> pitti: Since the init script has various side effects (like refusing to deconfigure interfaces if you have network mounts)
<mjg59> pitti: Oh, wait. Actually, the restart call looks ok. Ish.
<pitti> ogra_cmpc: I'm not sure I understand; can you please file a bug with the details?
<pitti> mjg59: makes me a little nervous, but if we rmood modules, then it's at least better than doing nothing, yes
<pitti> mjg59: another question is whether we need to rmmod all of them in the first place?
<mjg59> pitti: I'd rather go with what we have in acpi-support, since it pays attention to which interfaces are currently up
<mjg59> pitti: No, we don't need to rmmod all of them. But it's easier than trying to work out which ones we /can/ rmmod.
<pitti> we only got reports about ipw3945, which isn't an issue any more (iwl3945), and for e1000
<mjg59> I suspect there are more
<pitti> tjaalton, bryce: we need to keep xserver-xorg-driver-all in main for dapper upgrades, right?
<tjaalton> pitti: not only that, but there's no way of knowing what driver the user needs
<tjaalton> oh
<tjaalton> -driver-all
<pitti> tjaalton: *driver* vs. *video*
<Ng> mjg59: after hitting the networking restart thing in the last few days I'm wondering if it might be better to expose the driver bugs than mess with peoples' networking setups by ripping out all the modules. i don't know how far it spreads beyond my e1000 though
<tjaalton> pitti: yes, that's for upgrades I think, mvo added it :)
<pitti> tjaalton: so I'll seed it for hardy as a transitional package
<mjg59> Ng: It's what we did in previous releases
<Ng> mjg59: indeed and that was why I thought it would be ok to suggest it
<pitti> seb128: gvfs-bin > universe, supported, or desktop?
<Ng> aha, so acpi-support does ifdown/ifup the interfaces as well as just ripping out the modules
<seb128> pitti: what do you think? supported or desktop I would say, those can be handy but are not really things desktop users will run
<ogra_cmpc> pitti, Bug #211733
<ubotu> Launchpad bug 211733 in jockey "jockey should know about restricted drivers being out of sync during linux rebuilds" [Wishlist,New] https://launchpad.net/bugs/211733
<pitti> mvo: oh, thanks for fixing aptitude/cwidget
<pitti> seb128: My gut feeling is supported
<pitti> ogra_cmpc: thanks
<pitti> cjwatson: hm; which seed would you recommend to add "xserver-xorg-driver-all" transitional package to?
<seb128> pitti: agreed
<pitti> seb128: hm, and libbonobo2-bin?
<pitti> not really needed any more AFAICS?
<seb128> pitti: it's still used, but those tools are not really required, you can demote to universe
<pitti> ArneGoetje, Riddell: do we need scim-bridge-client-qt4 for anything, or shall I demote it to universe?
<pitti> cjwatson: also, I don't see a proper place to seed 'vim'; what would you recommend?
<pitti> cjwatson: (it sounds like it should be in some platform supported-*, too)
<mvo> pitti: cheers
<mvo> pitti: drivers vs video - it should be enough to have -drivers-all in the archive, we shouldn't need it in the seeds
<pitti> mvo: but for upgrades from dapper it should be in main?
<pitti> mvo: or can we always count on having universe enabled on dapper upgrades?
<mvo> pitti: oh, yes!
<mvo> pitti: in main please (sorry, I misread the earlier bits then)
<pitti> right, what I thought; thanks
<pecisk> Can someone explain why https://bugs.launchpad.net/ubuntu/+source/gnome-system-tools/+bug/185854 bug has "Declined  for Hardy  by Pedro Villavicencio" text attached to it and what does it mean?
<ubotu> Launchpad bug 185854 in gnome-system-tools "Setting static IP in Network Settings doesn't produce correct data" [High,Confirmed]
<mrben> hello - quick question
<mrben> ok - in a package listing in ubuntu, what does the number before the colon mean?
<mrben> eg Package: ardour (1:2.0.5-1ubuntu1) [universe]
<mrben> http://packages.ubuntu.com/gutsy/ardour
<laga> mrben: i think that's called "epoch". try #ubuntu-motu for packaging related questions
<mrben> ok - thanks laga
<james_w> mrben: yeah, it's an epoch, sometimes they are needed for some reason, usually someones mistake with version numbers
<mrben> ahh
<pecisk> anyone? :(
<james_w> pecisk: it means that someone proposed it for Hardy, meaning that it would be put in a pool of bugs that would be considered as being high importance to fix before Hardy is released
<mrben> thanks for the info
<james_w> the fact that it was declined means that it wasn't considered important enough for this status.
<pecisk> well
<pecisk> that person have made wrong decision then
<pecisk> because it is actually a blocker
<laga> pecisk: i believe we're seeing similar issues in mythbuntu, but i have yet to confirm that.
<james_w> pecisk: well a blocker normally goes a different route, but proposing for hardy would be a good start.
<mantiena-baltix> doko: maybe you know if I should set BUILD_JARS_NATIVE=n in OOo2.4 Gutsy backport ?
<mantiena-baltix> doko: in gutsy's (OOo 2.3) debian/rules file BUILD_JARS_NATIVE was set to 'n', while in OOo 2.4 from Hardy it's set to 'y'
<mantiena-baltix> infinity: hi
<doko> mantiena-baltix: does it fail to build while building the native jars?
<amitk> ogra_cmpc: does the zsync update work for you? http://pastebin.ubuntu.com/6459/
<ogra_cmpc> amitk, riched uses it extensively and i know highvoltage has used it
<pecisk> james_w: simply I expierenced this bug on newest live cds, on up-to-date laptops, workstations. It is annoying and Hardy definitely can't be shipped with it.
<james_w> pecisk: I'm sure it exists, whether hardy can be shipped with the bug is more subjective.
<ogra_cmpc> amitk, s/-i/-o/
<james_w> pecisk: I'm pretty sure a patch to fix it would be accepted.
<james_w> pecisk: you would need to work out why set_auto on the interface doesn't make oobs write out the "auto" line.
<ogra_cmpc> amitk, or even omit the option and mv hardy-classmate-20080326.img hardy-classmate-20080401.img ... before you start
<ogra_cmpc> -i means definately "input file", you want to output to it :)
<pecisk> james_w: subjective? with manual IP address configuring don't working from gui? :) ok, sure, I will check it
<thom> pitti: thanks for the puppet sync dude :)
<pitti> thom: you're welcome
<james_w> pecisk: on_iface_toggled in src/network/callbacks.c is probably a good place to start looking.
<pecisk> thanks :)
<laga> pecisk: it'd be great if you got a patch :)
<pecisk> I will try
<pecisk> I do it only second time :)
<james_w> Is anyone able to answer my question at the end of https://bugs.edge.launchpad.net/ubuntu/+source/python-central/+bug/205470?
<ubotu> Launchpad bug 205470 in python-central "python-central crash on upgrade (was: python2.4-minimal could not be uninstalled)" [High,New]
<james_w> "if you are removing a package is there a window in which the files are removed (in particular /var/lib/dpkg/package.list), but the package is still listed in /var/lib/dpkg/status?"
<james_w> and by listed I mean listed there with a Version: and Depends:? Not in "purge ok not-installed" state.
<amitk> ogra_cmpc: I tried all sorts of cmdline options starting from the one you recommend: http://pastebin.ubuntu.com/6460/
<ogra_cmpc> hum
<ogra_cmpc> i'll test, one secd
<ogra_cmpc> amitk, http://paste.ubuntu.com/6461/
<ogra_cmpc> works fine here
<ogra_cmpc> (command cop/pasted fromm your pastebin)
<ogra_cmpc> 63min ETA
<ogra_cmpc> amitk, hardy-classmate-20080326.img is lying in $(pwd) ?
<ogra_cmpc> seems it complains about the output file missing
<Riddell> pitti: scim-bridge-client-qt4 is used by kubuntu-kde4-desktop, but I suppose it's probably also needed by qt 4 apps in main, ArneGoetje?
<amitk> ogra_cmpc: yes, file is in cwd.
<ogra_cmpc> thats very weird
<Ng> asac: did we remove firefox's Ctrl-Q quit shortcut, or did they?
<amitk> ogra_cmpc: nevermind. It will be faster for me to download the whole image  :)
<ogra_cmpc> amitk, all i can tell is that it works fine on two different machines i tried with exactly the command you gave
<asac> Ng: can't copy that ;) ... i still have ctrl+q
<Ng> asac: lemmie check with a fresh profile, the one I tested it in is a few weeks old
<Riddell> infinity, slangasek: livefs builds stuck again
<ogra_cmpc> woah, rsync got noisy
<ogra_cmpc> (on cdimage)
<fta> bryce, do we have a fix for bug 198759 / bug 208224 ? it's annoying on laptops..
<ubotu> Launchpad bug 198759 in xkeyboard-config "Right CTRL don't work" [Medium,Confirmed] https://launchpad.net/bugs/198759
<ubotu> Launchpad bug 208224 in xorg-server "[hardy] right ctrl key does nothing (french layout) (dup-of: 198759)" [Undecided,New] https://launchpad.net/bugs/208224
<cjwatson> fta: it seems to be a deliberate choice in the keymap, unfortunately
<cjwatson> which has held me back from just undoing it
<cjwatson> the right control key is deliberately mapped to a level-5 shift
<fta> hm, but at least on a french keyboard, everyone expect the control key to act as control, not produce garbage
<cjwatson> well, that's the thing, this keymap was produced by somebody French
<cjwatson> so there is clearly disagreement among French users, which makes it difficult for relative outsiders to figure out what's going on ...
<cjwatson> I think I might send mail to the keymap author and ask for clarification
<fta> would be nice
<cjwatson> fta: ok, I'll do that
<fta> strange thing is that it works as expected on all my desktops, but no on laptops
<pez2001_> can someone give me some tips on how i can have just one place in my src where i have to change the version number (im building rpms and debs too)  ...
<pez2001_> im using kdevelop
<cjwatson> fta: that would be odd, unless you're using a different keymap on the desktops
<cjwatson> fta: it's not particularly hardware-specific
<fta> i've tried both french, and french alternative on my laptop, none works as my desktops
<seb128> fta: do you use the same keymap? the default choice changed in gutsy or hardy
<cjwatson> it was earlier than that
<cjwatson> check /etc/X11/xorg.conf, anyway
<cjwatson> console-setup (1.13ubuntu7) feisty; urgency=low
<cjwatson>   * Set default variant for French to oss (LP: #89835).
<pitti> mvo: regarding the update-manager sitting in -proposed: is there any progress in verifying bug 172609? if I accept that, we'll stack more and more changes which never go into -updates...
<ubotu> Launchpad bug 172609 in update-manager "mishandles prerequists-sources.list on ports architectures" [High,Fix committed] https://launchpad.net/bugs/172609
<soren> lool: I didn't merge it. I just renamed the refacotored branch to trunk.
<pitti> pedro_: do you happen to plan on working on SRU verifications in the next time? there is still quite a bunch of old SRUs
<fta2> ISO_Level5_Shift (laptop)
<slytherin> hi all, I am trying to analyze OOo build failure on powerpc but not getting much info. Is it anyway related to java?
<fta> Control_R (desktop), same keymap.
<pedro_> pitti: yes, let me see what i can do
<pedro_> pitti: btw the gutsy tomboy links to GNOME reports instead
<cjwatson> fta: interesting, but I'm not sure we need to investigate it
<cjwatson> fta: it might for example be that on some of your systems you have selected a different keymap in GNOME that's overriding the default in xorg.conf
<fta> hm, ok, i'll check that.
<cjwatson> fta: in any case, this kind of investigation is the sort of thing that's needed when we aren't quite sure what's causing the bug, but in this case I can point to the line of code involved. :-)
<pitti> soren, zul: can you please seed likewise-open anywhere or make it a dependency? ATM it wants to go back to universe; TIA!
 * soren is (trying to be) on holiday today
<cjwatson> pitti: xserver-xorg-driver-all should go in ship, I think, so that it's available for CD upgrades
<cjwatson> pitti: perhaps vim should go in the dvd seed
<cjwatson> (we don't have a platform version of that, really)
<cjwatson> oh, we do, dvd inherits supported-common
<cjwatson> pitti: perhaps platform.hardy/supported-development
<cjwatson> and maybe move emacs, emacs22-el, emacs-nox from ubuntu.hardy/dvd to there as well
<cjwatson> oh, and emacs-goodies-el
<zul> pitti: on it
<Ng> cjwatson: did someone reply about the thinkfinger bug? I just installed it and openssh-server, added it to pam and I can still ssh to localhost without anything dying
<Ng> I didn't reboot, so I guess many pam services aren't using thinkfinger, but since sshd wasn't installed previously, it ought to have
<zul> pitti: done
<Ng> I wish the fingerprint stuff was remotely safe, but I'm going to uninstall it again ;)
<jdong> aren't fingerprints some of the silliest things to authenticate by?
<ogra_cmpc> yeah, easy to fake
<jdong> next we'll be authenticating by hair and dead skin cells
<StevenK> What would you rather, retina scan?
<laga> StevenK: passwords.
<soren> blood sample
<jdong> StevenK: at least you don't leave retina prints lying around everywhere
<jdong> :)
<laga> soren: check_is_it_red() [boolean]
<soren> :)
<laga> ;)
<jdong> lol
<ogra_cmpc> the chaos computer club germany recently published a finger cover to pull over your indexfinger with the print of our interior minister
<ogra_cmpc> (as gadget with their newspaper)
<laga> .. which is amusing as hell :)
<ogra_cmpc> yeah
<cjwatson> Ng: I don't think anyone else replied, no; but a followup to the bug would be better :)
<cjwatson> Ng: oh, hmm
<cjwatson> Ng: did you edit /etc/pam.d/<anything> to actually use pam_thinkfinger?
<cjwatson> oh, you said you did
<cjwatson> common-auth?
<cjwatson> IMO fingerprint authentication should be in conjunction with a password, not a replacement for it
<Ng> cjwatson: yep, I have it set up enough that sudo will work with password or fingerswipe
<Ng> I'll add a comment to the bug
<Mithrandir> I think I'm going to write a pam module that will allow fingerprint auth if short enough time has passed since the system was active.
<Mithrandir> so you can unlock the screensaver if you just left the office for 15 minutes, but not if you left it overnight.
<cjwatson> add it as an option to pam_thinkfinger?
<laga> so the guy who cut off my finger will have to hurry up. cool
<cjwatson> rather than a new module
<pwnguin> hey
<Mithrandir> cjwatson: yeah, guess so.
<mjg59> Would probably be preferable to add it to fprint
<Mithrandir> laga: indeed.
<mjg59> I don't see thinkfinger being the way forward
<pwnguin> interesting subject
<pwnguin> cjwatson: that bug report's for gutsy -- ubuntu doesn't ship thinkfinger in main or universe in gutsy =/
<pwnguin> mjg59: i dont see how anyone could conclude that thinkfinger is moving forward
<Hobbsee> pwnguin: jldugger is the likely culprit
<pwnguin> heh
<pwnguin> that bastard!
<Hobbsee> bah.  curses.
<Hobbsee> pwnguin: so, why are you packaging crack?  :)
<pwnguin> its not crack
<pwnguin> its just dying
<Hobbsee> anything in ppa is crack.
<pwnguin> fine
<Hobbsee> :P
<pwnguin> why is the hardy thinkfinger package also crack?
<jdong> what is the case with apparmor and overlay filesystems?
<jdong> is it  still a case of it doesn't work?
<laga> aufs seems to work? unless something automagically disables apparmor on my boxes :)
<pitti> zul: cheers
<zul> pitti: np
<pwnguin> Hobbsee: i guess i love crack. i do hits of nouveau and gnome-do at least weekly
<pitti> pedro_: I know; it was a gnome microversion update
<Fujitsu> nouveau is good crack, at least.
<pwnguin> Hobbsee: honestly, i was going to just let it linger some more and examine fprint, but it seems Dell forced the issue a bit ;)
<jdong> laga: I have aufs unioning /root-ro with /tmpfs, and apparmor freaks out with things like access to /root/etc/foo/bar failing
<Hobbsee> pwnguin: ahhh :)
<pitti> cjwatson: hm, editors in 'development'? Well, it doesn't matter too much..; thanks for your input
<Hobbsee> pwnguin: yay, gnome-do!
<pwnguin> Hobbsee: plus, how on earth do you authenticate via fingerprint via ssh?
<pwnguin> its a pam problem :P
<laga> jdong: currently, /etc/init.d/apparmor isn't started on my boxes, but i wonder if it's needed?
<Hobbsee> pwnguin: enofingerprintreader
<Hobbsee> pwnguin: aka "magic"
<jdong> laga: that would be what activates apparmor, yes :D
<laga> jdong: i definitely should do some regression testing before pushing the change that enables apparmor then..
<jdong> laga: yeah....
<laga> jdong: let me find an ethernet cable and i'll see if it works for me.
<cjwatson> pwnguin: heh, granted
<cjwatson> anyway, not openssh's problem AFAICS ;-)
<cjwatson> pitti: seems to be the closest that's there at the moment, and after all vim does have a disproportionate number of developer users
<pitti> cjwatson: emacs moved, vim added; I put them into a new section "Advanced editors" now
<cjwatson> thanks
<pitti> cjwatson: we don't have a platform/ship AFAICS?
<slytherin> hi all, I am trying to fix OOo build on powerpc. I have found 2 things unusual. Please let me know if I am going in right direction 1. ENABLE_JAVA is set 'n' on powerpc. 2. Line number 3681170 in uncompresed .diff.gz looks like some condition is missing. But I am not sure why this doesn't cause problem on other arch.
<mdomsch> uh, yeah, we kind of need thinkfinger, and soon...
<mdomsch> if thinkfinger gets replaced with something better, no worries
<pwnguin> thinkfinger mostly works in hardy
<laga> mdomsch: why do you need thinkfinger?
<mdomsch> laga, a goodly number of our Ubuntu-preloaded laptops have fingerprint readers
<laga> ah..
 * mdomsch works @Dell
<pwnguin> mdomsch: so should it be configured as a two factor hassle?
 * laga refrains from going on a anti-fingerprint reader campaign just because he didn't get enough sleep ;)
<mdomsch> pwnguin, I leave that up to the engineering team
<mdomsch> whether it's single-factor or 2-factor
<pitti> zul: bacula-director-sqlite bacula-director-sqlite3 bacula-sd-pgsql bacula-sd-sqlite bacula-sd-sqlite3 -- which of those should stay in main (need seeding) and which are ok to move to universe?
<mdomsch> in the end, that winds up as a user policy decision
<pwnguin> laga: honestly, if they can recover your fingerprints, they can probably do something worse than fake your prints
<zul> pgsql should be in main the rest should be in universe
<zul> pitti: ^^^
<pwnguin> mdomsch: somehow, i just dont see users clamoring for two factor ;)
<pitti> zul: can you please seed psql? I'll move the rest; thanks!
<zul> pitti: done
<pitti> zul: cheers
<laga> jdong: oh, apparmor isn't installed for my diskless clients.
<slytherin> can anyone please comment on my observation about OOo build? Or at least provide me further pointers
<lool> soren: Ok, thanks
<pitti> slytherin: --verbose?
<slytherin> pitti: I didn't understand
<pitti> slytherin: what's wrong with the OOo build?
<seb128> pitti: right some lines ago?
<seb128> s/right/read
<seb128> pitti: 15:18
<pitti> ah, there
<slytherin> pitti: It fails on powerpc only. And it has been failing throught hardy cycle
<pitti> hm, disabling java on ppc might be deliberate
<pitti> it might not work there; but I'm just guessing
<slytherin> pitti: Please read my 2nd point too and let me know what you think
<cjwatson> pitti: not at the moment
<slytherin> pitti: I was not able to make much out of the build log. I will try to analyze it again tonight.
<laga> jdong: ok, i installed apparmor and dmesg shows that i get access denied when accessing /rofs/something or /cow/foo. guess i should make sure it stays disabled.. ping me if you need something, i've gotta run now
<slytherin> cjwatson: It was disabled long time back. Not sure if anyone tried enabling it again recently. Surprisingly Debian has packages for powerpc.
<pedro_> pitti: is the retracer working?
<jdong> laga: yes, that's consistent with my findings too
<pitti> pedro_: argh, ssh broken ATM again; I'll have a look a bit later
<pedro_> pitti: ok, thanks you
<emgent> uhm
<emgent> pitti: regression ?
<cjwatson> slytherin: did you mean me?
<pitti> emgent: yes, at the side of my ISP
<cjwatson> slytherin: oh, I was replying to something else pitti said, nothing to do with ooo
<\sh> pitti, do we still have sync references of packages since hoary somewhere? :)
<slytherin> cjwatson: oh, sorry
<\sh> pitti, especially for subversion-helper-scripts ;) it's not clear where it came from...and why we don't find any reference for it in debian
<pitti> \sh: I don't know more than https://edge.launchpad.net/ubuntu/+source/subversion-helper-scripts either, sorry :/
<\sh> pitti, it doesn't give us a clue about the source...but I think I found it already :)
<\sh> http://www1.apt-get.org/search.php?query=subversion-helper-scripts&submit=Submit+Query&arch[]=i386&arch[]=all
<pitti> ah, apt-get.org import
 * pitti hugs dholbach
<\sh> pitti, that reminds me, it would be good to have those references on LP...sync-source: -> this site ;)
<Mirv> bryce: any news about the screen resolution tool, a new version? I'm mainly interested so that the i18n fixes would go in in time, but you're probably also doing other aspects before a new gnome-control-center upload?
<seb128> Ng: around?
<Ape> Hi
<Ape> I'm a coder and I'd like to be part of a open source project
<laga> jdong: apparmor is not too useful for my use case so i can live without it, luckily
<Ape> How can I start?
<Ng> seb128: yep
<seb128> Ng: the issue was not the gtk one I pointed yesterday, seems to be rather a cairo on
<Ng> seb128: aha, i saw some launchpad bug mail about something being re-classified as a cairo bug
<laga> Ape: well, one case would be looking for a blue print in launchpad and work on something that's interesting for you (contact the people listed in the blueprint beforehand)
<metellius> i want to code a patch for libqt-gui packages, but the whole dpkg-buildpackage process is insanely slow for actually getting some iterative code/compile/test programming going... is there actually a better way for this that people have thought of?
<laga> metellius: i sometimes use dpkg-buildpackage -nc
<laga> -nc means "don't clean up, start where it left off"
<laga> maybe that can do the trick for you
<metellius> doing a testcompile now to see if -nc makes a difference...
<Lamego> or you could work on a normal source dir, and create the patch/package later
<metellius> Lamego: I did think of that as an alternative too, but I was kind of hoping this was such a common problem there would be a less manual solution available
<pitti> pedro_: indeed, I restarted it; thanks
<pedro_> pitti: great, thanks :-)
<cjwatson> metellius: look through debian/rules build, find what it does (which is typically just 'make'), run that
<cjwatson> usually if you're planning to be spending enough time working on a package to need iterative code-compile-test, this is not a problem
<Mirv> pitti: hi. bug 199255 is assigned to you. do you need help with it? it seems trivial, translation domain not set somewhere so programs tries to read messages.mo instead of correct file. identical problem preventing translations from showing is bug 204155.
<ubotu> Launchpad bug 199255 in policykit-gnome ""Authorizations" shows untranslated, but it's translated in Launchpad" [Undecided,In progress] https://launchpad.net/bugs/199255
<ubotu> Launchpad bug 204155 in network-manager-applet "Nm-editor translations not loaded" [Undecided,Confirmed] https://launchpad.net/bugs/204155
<pitti> Mirv: I didn't find time to fix it yet; if you want to have a go at it, I'd appreciate :)
<seb128> pitti: opinion on https://bugs.edge.launchpad.net/ubuntu/+source/pixman/+bug/211785?
<ubotu> Launchpad bug 211785 in pixman "Please sponsor pixman 0.10.0-0ubuntu1" [Undecided,New]
<seb128> pitti: I think upstream can be trusted, they do and careful work usually
<seb128> pitti: pixman should only be directly using by cairo and xorg
<seb128> pitti: and the new version is required to update cairo (we have 1.5.14 which is an unstable version and target 1.6 for hardy)
<pitti> seb128: ugh, quite a lot of changes
<ion_> Btw, couldn't Ubuntu use pdiffs for apt-get update while we're waiting for the final solution, since it's already implemented?
<pitti> seb128: well, seems there isn't much room for saying 'no' anyway? :)
<seb128> pitti: not really no ;-) But I'm asking to be polite ;-)
<tjaalton> seb128: it was uploaded in debian recently
<seb128> tjaalton: ok
<tjaalton> so a sync should be possible soon
<ion_> mvo: Any news about apt-sync, btw? :-)
<tjaalton> seb128: are you syncing packages? could you sync tightvnc which is currently uninstallable because there's no vnc-common anymore
<tjaalton> we have -21, -22 removed the dependancy
<qense> hello developers
<qense> I've got a question concerning  bug 186264
<ubotu> Launchpad bug 186264 in hal "keyboard randomly goes dead; takes a logout to restore functionality." [Undecided,Incomplete] https://launchpad.net/bugs/186264
<qense> It already has a lot of log files attached to it, but I still can't decide if HAL is the package where it should be and if it's compelte
<qense> does anyone knows what to do?
<seb128> tjaalton: ok
<tjaalton> seb128: thanks
<seb128> pitti: could you just add a ack on the pixman bug if you are ok for the update?
<pitti> TBH I can't approve this as bugfix-only in good faith
<seb128> pitti: I didn't say it's bug fix
<seb128> pitti: bug cairo requires it or we are stucked with an unstable version
<seb128> pitti: or we need to patch cairo backward to not use whatever it requires now
<Caesar> tjaalton: just btw and fyi, the changelog in nfs-utils is still missing all of the previous Ubuntu changes
<Caesar> (not that I'm looking forward to rebuilding with our local changes *again* if you do anything about it)
<cjwatson> 09:32 <cjwatson> Caesar: uuid-runtime seems to be optional (both according to the changelog, and according to Debian priorities); I made casper depend on it, but I wonder if we need to install it by default
<cjwatson> 09:32 <cjwatson> of course it's arguably inconvenient to deal with UUIDs without it ...
<cjwatson> Caesar: don't know if you saw ^-- that this morning
<cjwatson> Caesar: are you just using it for uuidgen?
<tjaalton> Caesar: there weren't that many to begin with
<Caesar> cjwatson: yes I saw
<Caesar> cjwatson: we were using uuidgen, yes, and it just seemed to disappear
<Caesar> cjwatson: we're just explicitly apt-installing it in our early command now
<cjwatson> Caesar: I'm not sure what the right answer here is. On the one hand it's a regression for some; on the other, it is genuinely optional and most people won't notice
<cjwatson> mind you, it's tiny
<jdong> wow, gvfs-mount is quite sexy
<cjwatson> I think I'll put it in standard as a recommendation
<lamont> pitti: if you get bored today, could you look at 211666 (nmap) for inclusion?
<lamont> jdstrand: I added the 'Addresses-Ubuntu-Bug: 204658' line to your patch when I accepted it... :-)
<keescook> slangasek: nah, ptrace has always been crappy.
<lamont> keescook: ptrace has always been lovely, providing you're the attacker. :-0
<keescook> lamont: hehehe.  +1.
<keescook> I've seen gdb and strace do the thing slangasek describes, though.  really sucks.  "whaaat? noo! I said quit gdb! not the attached process!"
<keescook> from what I've been able to tell it tends to be either the application reacting poorly to an interrupted syscall, or threads gets highly upset.
<lamont> threads + gdb == NOTLOVE
<lamont> jdstrand: do you have more apparmor er stuff for bind9?
<jdstrand> lamont: nope. the ApparmorProfileMigration is all worked out
<jdstrand> lamont: just that bug you committed to -10
<jdstrand> (thanks btw)
<Mirv> pitti: ok, I got a fix (debdiff + package at PPA) for bug 204155 and subscribed ubuntu-main-sponsors, but the policykit-gnome (bug 199255) I couldn't resolve at least yet. If I don't update the bug, then I didn't find a fix (or have time)
<ubotu> Launchpad bug 204155 in network-manager-applet "Nm-editor translations not loaded" [Undecided,Confirmed] https://launchpad.net/bugs/204155
<ubotu> Launchpad bug 199255 in policykit-gnome ""Authorizations" shows untranslated, but it's translated in Launchpad" [Undecided,In progress] https://launchpad.net/bugs/199255
<lamont> jdstrand: ok.  sorry for not noticing that before i did the upload of -9 :-(
<jdstrand> lamont: np
<keescook> jdstrand, lamont: with the klibc changes I uploaded last night, can you update your initramfs and verify that it fixes the "m" issues with AppArmor on i386?  I verified that the resulting personality bits are correct, but I didn't have a functional setup of slapd.
<lamont> keescook: sure - it'll be this weekend though
<jdstrand> keescook: actually, just test-openldap.py then reboot is enough
<keescook> oh heh
<jdstrand> keescook: but I can do it
<jdstrand> keescook: it'll be a bit though
<jdstrand> (today, just not *now*)
<keescook> cool, thanks guys.  no rush.  :)
<jdstrand> keescook: thanks for getting to the bottom of it! :)
<keescook> jdstrand: it was a fun exercise.  ironically "fix executable stacks" is on my list already, it's just waaay down there.
<jdstrand> :)
<mok0> My kmail doesn't work under kde4 anymore :-(
<Riddell> mok0: #kubuntu-kde4
<lool> soren: I fought a little due to the state of the kernel, but I just got a lpia vm running
<mok0> Is it only me, or is gfortran incredibly much slower than g77?
<LaserJock> mok0: in compiling or the resulting binaries?
<mok0> LaserJock: Compiling
<lool> soren: Could you please have a look at lp:~lool/ubuntu-jeos/trunk and eventually merge it? :)
<LaserJock> I haven't noticed it, but I haven't been timing my builds :-)
<mok0> LaserJock: It's probably just because I'm sitting and looking at it...
<pitti> Mirv: thanks
<LaserJock> mok0: "A watched compiler never finishes"
<mok0> LaserJock: :-)
<infinity> Riddell: Hrm, mkquashfs appears to be hanging on creating kubuntu-kde4...
<Riddell> infinity: and that's blocking everything else?
<infinity> Riddell: Yeah, lockfile being held while kubuntu-kde4 spins.
<Riddell> infinity: any log file to find out what's up with kubuntu-kde4?
<infinity> Riddell: It just.. Gets stuck. :/
<infinity> Riddell: Given that it happens on both buildds (two different arches) every day, it's got to be reproducible.
<Riddell> infinity: but there must be a logfile to say what it's doing when it gets stuck no?
<infinity> Riddell: It's running mksquashfs.
<infinity> Riddell: It gets "stuck" around 70% and just spins.
<infinity> Riddell: I can only assume some bit of data unique to kubuntu-kde4 is tripping a bug in mksquashfs.
<infinity> Riddell: Anyhow, I've killed those two hung processes... I might disable the kubuntu-kde4 cronjob on antimony until we have time to debug the problem, if that's alright with you?
<mvo> cjwatson: hello! because the new sudo cleans the environment I'm looking for a new test to check if the release-upgrader is running under ssh. I used to check the SSH_TTY environment, do you know about a good alternative way without checking the environment?
<Riddell> infinity: k
<infinity> Riddell: I can't guarantee I'll have time in the immediate future to look at it, so if you want to use livecd-rootfs to try to reproduce it locally, that might be nice.
<infinity> Riddell: I assume, though, that kubuntu-kde4 is a community "fun" thing, not a release target?
<Riddell> infinity: it's a release target
<infinity> Riddell: Oh, poo. :/
<infinity> Riddell: Well, we'll have to make time soonish to look at the bug, then.
<pitti> zul: http://people.ubuntu.com/~ubuntu-archive/component-mismatches.txt also has some freeradius, nut, and redhat-cluster binaries which want to go to universe (see bottom of page); which of those should get seeded, and which shuold go to universe?
<cjwatson> mvo: it's going to be pretty nasty ... look in the process tree and see if one of your ancestor processes is 'sshd: <something>'?
<mvo> cjwatson: right, I was afraid you would answer this :) oh sudo, please give me back the old behavior
<pitti> cjwatson: would "who | grep `tty`" be a feasible solution?
<zul> pitti: freeradius and nut should all be seeded and im not sure about redhat-cluster though
<zul> pitti: ill go and seed them
<pitti> zul: thanks
<pitti> keescook, mathiaz: do we want libpam-apparmor in main? it currently wants to go to universe, so if we do, it needs to be seeded (to supported, I guess)
<cjwatson> pitti: who doesn't tell you that it's ssh
<cjwatson> you get a remote host name, but if you wanted that it might be more elegant to look in ck-list-sessions or similar
<pitti> mvo: is the actual aim of your test "remote login" or "ssh" in particular?
<cjwatson> I was guessing that mvo actually wanted to know specifically ssh, rather than just "is it remote"
<pitti> ah, I'm not sure
<cjwatson> if it's specifically ssh, a supplementary question would be why? :-)
<zul> pitti: done
<lamont> mvo: I have noticed that sudo is prompting more often than it used to...
<mvo> pitti: yeah, ssh because then I know what to do (offer to start a additional spare sshd)
<cjwatson> ah
<keescook> pitti: I have no desire for it to be in main currently.  changehat support is still rather weak overall, so I'd rather leave it out (same for the apache lib)
<mok0> Yikes the latest kernel update hosed my graphics setup
<keescook> mok0: in what way?
<mok0> keescook: It came up in 640x480
<keescook> mok0: usplash or Xorg?
<mok0> xorg
<mok0> Fortunately the old xorg.conf file was still there
<keescook> mok0: hm, I don't know much about xorg res settings yet.  bryce could this be related to xrandrgui changes?
<mok0> I also lost my GLX extension
<mok0> ... but perhaps I just need to re-enable my restricted nVidia driver
<seb128> re
<seb128> pitti: so about libpixman?
<seb128> slangasek: opinion on https://bugs.edge.launchpad.net/ubuntu/+source/pixman/+bug/211785?
<ubotu> Launchpad bug 211785 in pixman "Please sponsor pixman 0.10.0-0ubuntu1" [Undecided,New]
<slangasek> seb128: looks to me like it should be submitted for an FFe, but doesn't include an upstream changelog
<seb128> slangasek: the update is not trivial but it's required for the new libcairo version (we track 1.5 at the moment and would be better to not be stucked to a non stable version)
<slangasek> seb128: are there compelling reasons to want cairo 1.6.0 for hardy?
<slangasek> ok, you just answered that I guess :)
<seb128> slangasek: I think there is quite some work going upstream to fix firefox 3 issues since it uses cairo quite a lot now
<seb128> slangasek: so I would prefer to do the libcairo 1.5.n to 1.6 updates
<seb128> the new pixman has been uploaded to debian today
<seb128> we can wait until monday and upload if nothing break there maybe?
<slangasek> ok - then pixman should go through the FFe process, so please get me an upstream changelog
<seb128> ok
<slangasek> (and subscribe ubuntu-release)
<seb128> fta: ^ could you do that too?
<seb128> slangasek: well, the debdiff and diffstat and ping was sort of a FFe request, but right we will follow the rules ;-)
<keescook> who is our ntfs guru?  :)  I'd like someone to take a look at bug 190329
<ubotu> Launchpad bug 190329 in ntfs-3g "DAC permissions not correctly enforced" [Undecided,Confirmed] https://launchpad.net/bugs/190329
<fta> seb128, upstream changelog is empty, it was empty in the version too
<seb128> fta: git log between those then?
<fta> possible, i have to pull it 1st
<pitti> keescook: ok, demoting
<fta> slangasek, do you want a summarized changelog or the raw one ?
<keescook> pitti: btw, i think libapparmor1 and libapparmor-dev will fall into universe too
<fta> seb128, done (2 logs attached to the bug and ubuntu-release subscribed)
<seb128> fta: thanks
<seb128> slangasek: ^
<bryce> Mirv: yeah I've been focusing on getting the revert dialog ready to go, and there's some new stuff from upstream that I think seb128 has been working on
<seb128> bryce: not been working on those updates yet, I've been busy with lot of other GNOME things
<seb128> bryce: and GNOME 2.22.1 is due next week so I'll likely be busy doing those update for most of the week
<bryce> keescook: no the xrandr gui doesn't touch the xorg.conf at all.  I've seen some other reports of GLX extension problems, and it sort of feels like a kernel issue.
<slangasek> fta: the full upstream changelog
<bryce> seb128: hrm, well xorg stuff has been keeping me quite busy.  I have trouble finding time to contribute into the gnome work
<fta> slangasek, i've posted both
<seb128> bryce: yeah, everybody is overworked
<seb128> bryce: I would argue that this one is not a GNOME thing though but something the xorg team wants
<seb128> bryce: anyway, new GNOME = 60 to 80 updates to do, so I guess I'll be busy but I'll try to give a hand on that after the updates
<bryce> I'm going to be gone the last half of next week for my wedding, and will be out most of the week after that for the X conference, so I'm nearly out of time for Hardy work
<seb128> bryce: hum, k, too bad, I guess we will have to find somebody to help or delay to 8.04.1 then
<calc> seb128: what is the target date for 8.04.1 ?
<seb128> calc: not sure, around 3 months after 8.04 I think
<calc> oh ok
<jdstrand> slangasek: hi! curious on your opinion on bug #209897
<ubotu> Launchpad bug 209897 in ufw "FFe: ufw 0.16.2" [Undecided,New] https://launchpad.net/bugs/209897
<jdstrand> slangasek: if it's on your todo list, don't worry about it
<jdstrand> (talking about it with me that is)
<cjwatson> calc: start of July
<cjwatson> it's on HardyReleaseSchedule
<slangasek> jdstrand: on the list, yes :)
<jdstrand> slangasek: ok, thanks
<calc> cjwatson: oh ok
<shaya> upgrades from dapper to hardy might have a problem
<shaya> emu: Dynamic MMap ran out of room
<shaya> apt erros out on universe list
<shaya> that was E: Dynamic MMap ran out of room (not emu, stupid xchat)
<cjwatson> shaya: any chance that you have lots of other stuff in sources.list?
<shaya> not that much
<shaya> just dapper and hardy
<shaya> added a single hardy line
<slangasek> the typical upgrade process (using update-manager) is to replace the dapper lines with hardy.
<shaya> yea
<shaya> but aptitude is stupid
<shaya> it loses all the tracking information if I do it that way
<shaya> I guess I could do an apt-get update
<shaya> and then run aptitude
<laga> slangasek: did you have a chance to merge ltsp.seed from mythbuntu again?
<slangasek> laga: yes, done; sorry, forgot to mention that here
<laga> slangasek: no problem, thanks! :)
<shaya> what's the default mta in hardy? exim4?
<shaya> as thats what my upgrade is trying to install
<ScottK> shaya: None is installed by default.  Postfix is our preferred one, but if you have a package that needs an MTA, that package my prefer exim.
<infinity> shaya: postfix is the "preferred", but both postfix and exim4 are supported.
<shaya> well, exim4 got chosen
<shaya> not by me, so might be an ordering issue in some package
<infinity> (Note that packages in main are meant to have "postfix | m-t-a" deps, so if one doesn't, that's a minor bug)
<ScottK> shaya: If you'd rather have a different MTA, stop the upgrade, install the MTA you want, and then upgrade again.
<shaya> ScottK: i know
<ScottK> OK.
<shaya> I was just saying what infinity jus said
<shaya> might be a bug somewhere in Depends ordering
<lamont> infinity: they quit forking packages just to add that sometime ago
<infinity> shaya: That requirement doesn't exist for universe, though, just main.
<ScottK> As a rule if that's the only difference we don't change it.
<infinity> lamont: Oh, did we?  I'm out of the loop.
<shaya> infinity: universe is commented out right now per bug I mentioned b4
<ScottK> infinity: Yes.  Not worth maintaining the diff for.
<lamont> infinity: well, you see, I quit :-)
<infinity> lamont: But you keep coming back...
<lamont> infinity: like herpes
<infinity> lamont: But more irritating. ;)
<lamont> infinity: anyway, the new push is to make a 'default-mta' package, and have packages Depend: default-mta | mta
<lamont> then one package to throw the switch, and in the darkness bind them
<infinity> lamont: Makes sense, I suppose.
<laga> will default-mta be a virtual package?
<infinity> laga: No, it would have to be a real package.
<lamont> well, every time I bring it up with the exim4 maintainer in debian, it kinda starts interesting discussions
<lamont> laga: no
<lamont> it'll be a contentless package which Depends: on $WINNER | mail-transport-agent
<lamont> where WINNER== exim4 or postfix, depending on whether you're debian or ubuntu
<infinity> lamont: Well, it's a pretty big change that obviously only benefits derivatives, so I can see why one might get push-back.
<laga> ah, was just wondering :)
<ScottK> The benifit to Debian maintainers would be less having to see pointless Ubuntu patches on p.q.d.o.
<lamont> infinity: it's usually of the form "why don't we just make the debian default postfix so I can quit dealling with all the whiners" type response...
<lamont> I'm just not sure he's serious...
<infinity> lamont: I honestly don't care what the default is anyway, I'll keep installing exim locally.
<infinity> lamont: And I don't see why Debian would care much either, given their userbase.
<lamont> laga: the whole 'real | virtual' thing is so that you don't get a random one if none are installed, since apt will pick $SOMETHING that provides: virtual, and you have no control over it
<lamont> infinity: see the despair poster. :)
<infinity> lamont: It matters mostly for Ubuntu, because our userbase is (on averge) more "end-userish" and more likely to request support, and supporting both hurts.
<shaya> mailx: is Depends: exim4 | mail-transport-agent
<lamont> shaya: if there isn't any other ubuntu diff for the package, then it conforms to the current debian standard.  see, for example, uh, mailx
<lamont> :-)
<shaya> lamnt: even if it's in "main" ?
<lamont> <lamont> shaya: if there isn't any other ubuntu diff for the package ..
<infinity> shaya: Evidently, I was living in the past, and we no longer change packages in main for just that.
<shaya> doesn't make much of a consistent policy...
<lamont> infinity: I believe it was $lamont that did that in the past, the rest of the distro team went 'meh'
<infinity> lamont: I used to always do it too, as I'd assumed it was established policy.
<lamont> shaya: hence the work in progress to make it so we can change one package and win
<infinity> lamont: And it's painful to explain to users why they got a random MTA (even if we do support both of them)
<infinity> lamont: The big problem is that most of the wiki docs and such refer to postfix, and completely ignore that exim is also in main.
<infinity> lamont: So, a user with exim installed, while clearly having the superior MTA, is at a loss for "easymode" support.
<lamont> and pushing exim to universe wouldn't fix that either
<lamont> infinity: your bias is showing... pull your pants back up/
<infinity> lamont: Pushing exim to universe would make elmo and I very grumpy.
<infinity> lamont: Bias?  What bias?
<lamont> and wouldn't change anything
<lamont> heh
<infinity> lamont: I imagine my bias is similar to yours, in that I've contributed so much code and time to exim, I can't use anything else.
<lamont> exim vs postfix - depending on your criteria, both are better.
<lamont> Oh, I can use exim, I just don't like to
<infinity> We call all agree that both are infinitely better than writing sendmail.cf by hand.
<shaya> lamont: if one doesn't want to patch the packages
<shaya> why not just patch apt/aptitude/update-manager with the right logic?
<infinity> Eww.
<infinity> No.
<shaya> :)
<infinity> We don't want to FORCE postfix on anyone, nor have any "magic" in the background.
<infinity> We just want to have a default that makes it easier to exlain things to new users who don't know what an MTA is at all, and don't care.
<shaya> I didn't say force
<slangasek> I prefer my magic front and center, yes
<shaya> I said if no choice, choose it for them
<lamont> infinity: so having postfix provide: exim4 would be bad, eh? :-)
<laga> (if the user doesn't know what an MTA is, and if they don't care, should they be using an MTA?)
<infinity> But, y'know, for those who know, the easy solution is "apt-get install postfix mailx", and you're done. :P
<lamont> and the mail-server task includes postfix, to force things in the right direction
<infinity> laga: I'd argue "no", but I'm also regarded as an elitist jerk.
<slangasek> by "regarded", he means "there's a UN resolution that declares him to be..."
<infinity> Ouch.
 * calc thinks he determined what was wrong with OOo icons patch, finally :)
<laga> heh :)
 * calc isn't sure how it ever worked
<slangasek> infinity: don't worry, I'm pretty sure this is the same UN resolution that declares MJ Ray has an inalienable right to whinge on mailing lists
<infinity> slangasek: "whinge"?  Have you been hanging out with too many brits again?
<Daviey> oi!
<slangasek> infinity: mayhaps
<infinity> slangasek: perbe!
<lamont> nagios-plugins prompts-a-plenty FTFL
<lamont> infinity: he's trying to be cjwatson
 * lamont ducks
<slangasek> I just find "whining" an inexact description. :)
 * lamont wonders if he wants the dapper/modified, or hardy version of cupsd.conf
<infinity> Keep both, and alternate them based on moon phase.
 * shaya sighs
<lamont> well, the funny part is that this machine is the one that has the broken USB printer plugged into it
<infinity> If it's broken, I hardly see the issue.
<lamont> well, the jetdirect-printers that are also configured _do_ work
<slangasek> infinity: did you see Riddell's comment from this morning about livefs being stuck again?
<infinity> Yeah, only an ex-HP emplpoyee has JD printers at home.
<lamont> and my primary source of pain/joy uses a machine that's configured to print through cups on the machine I'm upgrading
<slangasek> oh, indeed, and you had a conversation about it right in front of me
<infinity> (I was going to go JD on my parents' printer, but the added cost for the JD card just isn't worth it)
<infinity> slangasek: Yes, yes we did.
 * lamont tries to remember if the colorlaserjet 2550n was bought from the HP referb, or from OfficeDepot closeout-rack
<infinity> slangasek: mksquashfs is hanging around ~70% on kubuntu-kde4 (and only on kubuntu-kde4) on both arches.
 * ScottK has a Jet Direct box.
<slangasek> infinity: right
<infinity> slangasek: Someone investigating that locally would be lovely, since it's clearly a distro bug, not my bug. :)
<lamont> infinity: I ran into mksquashfs hanging on my machine somewhere around 1-1.5 GB into an image
<slangasek> infinity: right... :)
<lamont> so upgrading to hardy probably won't fix it...
<lamont> kthx
<infinity> lamont: livefs uses hardy anyway...
<lamont> right
<lamont> I'm trying to remember if it was broken on gutsy for me, or if it broke after I upgraded
<infinity> slangasek: Anyhow, seems to be par for the course for us to headless-chicken last minute squashfs bug fixes before releases anyway, so I'm sure we'll manage.
<slangasek> heh
<lamont> in the end, my backup DVD image became an encrypted tar -j instead of an encrypted squashfs iso
<infinity> slangasek: And by "we", I mean "you".
<slangasek> yes, I'll managed, and you shall be managed
<slangasek> <-- release manager
<slangasek> I bet that would've sounded more ominous if I hadn't typoed
<infinity> It would also have carried more weight if I was on the distro team. :)
<slangasek> this too!
<lamont> dear nagios-plugins.  no love.
 * lamont looks around for his scissors
<laga> i'm trying to understand seeds (again) and the interaction with tasksel. if the seed for the live disk contains recommends like "* (network-manager-gnome)", are these installed by default?
 * lamont wanders off 
<Riddell> laga: yes (the brackets mean its a recommends rather than a suggests, so it can be removed)
<lamont> Apr  4 11:33:17 printers cupsd: Unable to open log file "/var/log/cups/error_log" - Permission denied
<lamont> win
<LaserJock> although tasksel isn't used by the live cd is it?
<slangasek> Riddell: s/suggests/depends/
<laga> LaserJock: true. :) trying to understand the interaction between seeds and the live disk ;)
<Riddell> laga: as slangasek says
<Riddell> LaserJock: live cds a bulid from kubuntu-live^ etc, which is a task
<calc> mu
<calc> er M}Y
<calc> sorry my 7mo old son decided he wants to use Ubuntu
<jdstrand> keescook: \o/ slapd still running without 'm' on i386 reboot ( bug #202161 )
<ubotu> Launchpad bug 202161 in klibc "apparmor broken after reboot on i386" [Medium,Fix released] https://launchpad.net/bugs/202161
<keescook> jdstrand: \o/
 * jdstrand hugs keescook 
<jdstrand> of course now, we have to update cupsys and slapd
<keescook> heh
<keescook> this exercise of klibc vs ld makes me feel well-prepared to take on the "eliminate executable stack" task now.  :)
<jdstrand> yea
<pawalls> join #puppet
 * pawalls fails...
<calc> heh comcast man trying to convert me to their service
<calc> i'm like "i don't really want packet filtered internet, but your new 50Mbps service in 2010 sounds great", heh
<calc> they offer 2-3x faster internet than i currently can get from my telco but they don't packet filter (afaict anyway)
<calc> at least not yet
<slangasek> but I'm thinking they aren't going to put that in a contract for you. :)
<calc> well at 50Mbps even packet filtered might not be too bad
<calc> i'd rather have 3Mbps unfiltered (that i currently have) than comcast's 6Mbps filtered though
<calc> for 17x faster internet access i might trade unfiltered traffic :-\
<calc> of course the rumor is that the 50Mbps connection will cost $150/mo (ouch)
<Caesar> Is there a way to see all bugs submitted in Launchpad, not just the open ones?
<Caesar> (for a given submitter)
<calc> whats the new style printf specifier for unsigned long (on amd64)?
<calc> that would be a unsigned 64bit specifier, right?
<calc> oh doh that isn't my bug, i left a extra , laying around :\
<calc> the numbers i am printing is small enough that the right specifier isn't a big deal it just was warning about them being wrong
<calc> a %lu
<cjwatson> laga: Launchpad arranges for anything in a task (either depends or recommends, or (in)direct dependencies from either of those) to have a Task: whatever header, and livecd-rootfs tells apt to install everything that says Task: whatever
<cjwatson> so it all works out
<cjwatson> Caesar: launchpad.net/~person/+reportedbugs, advanced search, check all the statuses
<cjwatson> Caesar: modulo bug 148901, which may interfere a bit, but not a lot to be done about that except encourage the LP guys to fix it
<ubotu> Launchpad bug 148901 in malone "less bugs listed when sorting" [High,Confirmed] https://launchpad.net/bugs/148901
<cjwatson> oh, heck, that's irritating me. "fewer"!
<laga> cjwatson: how does launchpad know which tasks are there (and which packages are related to a task?)
<Caesar> cjwatson: thanks
<cjwatson> laga: Task-* headers in the seeds
<cjwatson> laga: "which packages" is easy, it uses germinate to expand the correspondingseeds
<cjwatson> s/gseeds/g seeds/
<calc> it seems gedit is only registered to open files of type text/plain :\
 * calc wonders if this is considered a bug or a feature
<cjwatson> laga: it has a hardcoded list of which seed branches to look at
<laga> cjwatson: well, i've got the germinate and the tasksel package and they're all already set up for the mythbuntu branches, so i guess i'm good to go
<cjwatson> laga: mythbuntu, sadly, is not in Launchpad's hardcoded list
<cjwatson> laga: you can work around that by having livecd-rootfs install a metapackage rather than a task, though
<cjwatson> Launchpad only really matters for the Task headers
<cjwatson> i.e. omit the "^"
<elmo> oh hai, why is I getting sane prompts on resume?
<laga> cjwatson: i'm not interested in livecd-rootfs.. we have our own build scripts for the live disks where we indeed use a meta package :) i basically need to add a) a few packages to be shipped on our alternate disks which is built on cdimage.u.c (i guess that's easy) b) add some new tasks so users can choose what kind of setup (eg a set of packages) they want.
<cjwatson> laga: ok, well in that case you don't need to worry about Launchpad
<cjwatson> germinate, tasksel, and presumably mythbuntu-meta is all you need
<cjwatson> laga: I'm afraid that we are out of space on cdimage
<laga> cjwatson: i guess i can make a new seed file, add Task-Key: my-new-task and then run ubuntu-seeds.pl in tasksel?
<laga> cjwatson: our image is already built there, do you need to drop it?
<cjwatson> oh, is it?
<cjwatson> so it is, I thought you were requesting a new build
<cjwatson> please look at the *-server seeds in ubuntu.hardy for examples
<laga> no. :)
<laga> cjwatson: do they contain everything needed to generate new tasks?
<laga> or does additional magic need to happen?
<cjwatson> you also need to fiddle with the STRUCTURE file
<cjwatson> I suggest that you create the seeds and then let me review them
<cjwatson> I would like to review them before a tasksel upload happens in any case
<cjwatson> right now I'm too tired to give good general advice, but specific advice is a lot easier :)
<laga> that's ok, i'm too tired to ask good questions anyways :)
<laga> cjwatson: i'll take you up on your offer to review them :)
<cjwatson> basically putting the right set of Task-* at the top is sufficient, but tasksel will need to be rebuilt and likely mythbuntu-meta too
<cjwatson> you also need to get the structure right so that cdimage will include them on CDs
<cjwatson> which basically means (for alternate CDs) having them be inherited by ship
<cjwatson> and you'll probably need to adjust any tasksel preseeding you have in cdimage to allow the user to choose
<laga> cjwatson: i'll try to get back to you tomorrow, thanks for the input
<calc> Riddell: ping
<Riddell> hi calc
<calc> do we use human or crystal (or something else) on kubuntu?
<calc> i'm fixing the icon theme issue on openoffice and wanted to make sure i set it up right
<Riddell> calc: crystal
<calc> ok :)
<calc> i'm hoping to have the fallback patch working properly by later tonight for inclusion in the upload early next week
<calc> even with ccache it takes ~ 90m to do a build :\
 * calc wishes OOo could safely multithreaded compile
<tjaalton> calc: did you check --enable-ogltrans? the configure script doesn't seem to know about it, though the upstream one does
<calc> tjaalton: enable-opengl seems to do it
<calc> tjaalton: does installing openoffice.org-ogltrans not fix the issue?
<tjaalton> calc: oops, I didn't notice it exists.. let me check
<calc> /usr/lib/openoffice/program/OGLTrans.uno.so
<calc> /usr/lib/openoffice/share/config/soffice.cfg/simpress/transitions-ogl.xml
<calc> looks like it should be working
<tjaalton> ooh yeah ;)
<tjaalton> calc: yeah, works perfectly, thanks :)
<calc> great :)
<calc> wow selecting human-murrine crashes firefox
<Fujitsu> human-murrine is choosable again now? Yay!
<tjaalton> calc: switching compiz->metacity does the same
<calc> fun
#ubuntu-devel 2008-04-05
<jdong> calc: yup firefox gets pissed when the theme changes
<lamont>  /usr/lib/udev/migrate-fstab-to-uuid.sh: 141: uuidgen: not found
<lamont> so which package gets the bug report that says uuidgen moved from e2fsprogs to uuid-runtime?
<kirkland> kirkland@t61p:~/bin$ dpkg -S /usr/lib/udev/migrate-fstab-to-uuid.sh
<kirkland> volumeid: /usr/lib/udev/migrate-fstab-to-uuid.sh
<kirkland> lamont: ^ ?
<slangasek> e2fsprogs, given that e2fsprogs is essential?
<lamont> slangasek: as in uuid-runtime should be, too?
<slangasek> not sure, hence the question mark
<lamont> well, do-release-upgrade -d kinda breaks without it...
 * lamont heads out to dinner with his daughter
<Fujitsu> do-release-upgrade -d also breaks horridly if any one python-central-using package dies even slightly.
<blueyed> Hobbsee: ca you please release virtualbox-ose-modules from NEW?
<blueyed> s/ca/can/
<Hobbsee> slangasek: might want to
 * Hobbsee isn't here for overly long, and hasn't done the previous ones
<slangasek> I can't do it just now, but will look later this evening
<Fujitsu> Hmmm.
<Fujitsu> Did somebody break libpri's shlibs?
<Fujitsu> dpkg-gencontrol: warning: can't parse dependency libpri1.0 libpri1.2 (>= 1.4)
<sistpoty> Fujitsu: hm... I really thought I've seen libpri in motu-release's bug mail, but it must have been somewhere else, since search didn't show anything
<Fujitsu> mvo uploaded it two days ago.
<Fujitsu> I presume he broke it, as asterisk built fine recently.
<sistpoty> Fujitsu: ok, sent a mail to mvo
<Fujitsu> sistpoty: You have? Thanks, it's blocking an asterisk security update.
<sistpoty> Fujitsu: feel free to ping though, in case you see mvo around ;)
<LaserJock> sistpoty: ummm, like shouldn't you be asleep or something?
<sistpoty> LaserJock: yes, I should. and actually I'm on my wy to bed now ;)
<sistpoty> so good night everyone
<LaserJock> sistpoty: good night
<keescook> hmpf, wireshark crashes almost instantly for me.  :(
<blueyed> keescook: when starting capturing or on startup already? both works for me.
<keescook> blueyed: a little after starting capturing -- seems to be a glib segv -- hmpf, I will dig deeper tomorrow
<Fujitsu> I find it often hangs after starting a capture.
<blueyed> fwiw, I'm currently using the -server kernel.
<Fujitsu> Hmm, it still does its hanging thing.
<Fujitsu> Only on this laptop.
<Ape> I'd like to have a new feature in the gnome applet called system monitor
<Ape> It would be nice, if I could import a value from a file or from a script
<Ape> and then draw it like the other values(system load, ram, network usage)
<Ape> Where can I get the codes and start to make that feature?
<Ape> Or does somebody want help me with that?
<Ape> I found the sources in launchpad
<Ape> how can I add a new value input here?
<genete> Hi. I'm Synfig contributor and Ubuntu user. We have released recently the new Synfig version 0.61.08 but it seems we have been late for next ubuntu vesion.
<genete> I still having a 6.06 ubuntu vesion working and the last synfig release is fully compatible with it building from source.
<genete> Is is possible that someone package a backport for synfig last version? Check out here: http://synfig.org/Main_Page
<crevette> hello;  is universe freezed ? ie can we push new version of softawre ?
<Adri2000> genete: a backport is possible only from the current developement version of ubuntu, ie. hardy right now. if the version you want backported is not in hardy, either try to get a freeze exception for it (which becomes harder and harder as we are approaching the final release), or wait for intrepid developement to start
<Adri2000> crevette: there is Feature Freeze, so you can push bug fixes, but no new upstream release with new features (except if you get a freeze exception)
<crevette> too bad nobody cared about nemiver :/
<genete> Adri2000: ok, so take an eye on this project. I beliebe that it covers a big hole in the Open Source map and lately is being relaunched. Please drop by #synfig for synchoronization for next ubunutu release.
<genete> Glad to meet you. Bye
 * genete is away: Estoy ocupado
<Mirv> bryce: hi, the new gnome-control-center doesn't have the i18n patch 104 fixed
<Mirv> bryce: it still only patches the already-applied 101, and you mentioned you would fix it in a proper way despite the fact that 101 is coming from upstream so it cannot be changed or so...
<Mirv> bryce: the point was that the patch I originally offerred was supposed to be a patch changing the current 101 patch, not to be put in debian/patches directory.. but since you didn't want to change the 101 patch itself, you included my patch as a file to debian/patches which doesn't work
<Mirv> bryce: easiest would be mv 104_cc-randr12-enable-i18n.patch 100_cc-randr12-enable-i18n.patch <- no need to rework the patch for now. but a new upload should be done rather soon, since my patch was only reverting one string (as an example) to such that is already translated, so others have to be retranslated (soonish) by translators.
<Mirv> bryce: and finally, there's now also a bug 212132 :)
<ubotu> Launchpad bug 212132 in gnome-control-center "i18n patch 104 is not correctly applied" [Undecided,New] https://launchpad.net/bugs/212132
<bryce> Mirv: sorry about that, let me take a look
<bryce> Mirv, ok I've redone your patch to fix it, and uploaded.
<bryce> night
<kblin> hi
<Mirv> bryce: thanks a lot, good night :)
<afflux> I checked at https://launchpad.net/ubuntu/+source/bluez-pin/ but couldn't find any indication on where bluez-pin has gone after feisty. Any hints?
<afflux> ah, it was removed from debian
<qense> I've got a question about a bug I'm triaging: bug 186264
<ubotu> Launchpad bug 186264 in hal "keyboard randomly goes dead; takes a logout to restore functionality." [Undecided,Incomplete] https://launchpad.net/bugs/186264
<qense> I'm not sure if it's really in HAL and I was wondering if you know something more about it.
<qense> And do you think it contains enough information?
<Alan> I hope this is the right place for this, but...  Is there any particular reason why the update manager has to steal focus repeatedly during an update?
<qense> not really in my eyes, it could be considered as a bug
<Alan> But not one that anybody has ever bothered to report/fix?  I guess it isn't that important, but it's been around for a while...
<Alan> It's frustrating that I can't actually do anything if i'm running a couple of updates because the focus is stolen every few seconds...
<qense> you should report a bug at bugs.launchpad.net/ubuntu
<qense> it's indeed anoying
<Alan> At least it's not as bad as WinXP's "You still need to restart" popup every 5 mins :P
<qense> yes
<qense> in Linux you only need to restart when the kernel has been updated
<Alan> Yeah, I like that
<Alan> oooh, old bug...
<Alan> https://bugs.launchpad.net/ubuntu/+source/update-manager/+bug/35876
<ubotu> Launchpad bug 35876 in metacity "'Downloading package information' and 'building dependency tree' progress dialogs steal focus" [Low,Confirmed]
<ion_> And usually you can even delay that, unless there's a security fix of course.
<Alan> ion_, i love the nice modular linux kernel - back when i ran gentoo, i got a 2-month uptime on my desktop even when i'd been adding in entire subsystems to the kernel :)
<qense> Are there -server restricted modules for 7.10?
<Nafallo> qense: not that I'm aware of no.
<qense> ok
<qense> hardy does
<Nafallo> oh. didn't know that.
<Nafallo> what's in there?
<qense> someone I'm helping wants to install wireless drivers, but he's using the server kernel
<qense> so that won't work unfortunately
<Nafallo> wireless on a server?
<Nafallo> that sounds... weird :-)
<qense> yeah, I know :)
<muhaha007>  hi
<muhaha007>  does anybody know, where I can find the examples.pyw in pythoncard?
<muhaha007>  normally it should be in /usr/lib/python2.5/site-packages/PythonCard, but there's no such directory
<muhaha007>  installed it from apt
<muhaha007> :)
<mok0> muhaha007: dpkg -L pythoncard
<muhaha007> mok0: well, just /usr/share/doc/pythoncard
<muhaha007> but /usr/lib/python2.5/site-packages DOES exist :)
<muhaha007> mok0: evrything seems to be installed, codeEditor is working, but the directory for the samples doesn't exist
<muhaha007> mok0: so there's no /site-packages/PythonCard
<mok0> muhaha007: perhaps it's in another package
<mok0> pyhoncard-doc or pythoncard-tools
<mok0> or python-pythoncard
<mok0> muhaha007: pythoncard-doc: /usr/share/doc/pythoncard-doc/samples/webserver/webservices/examples.py
<muhaha007> dok0: thx, I'll search there, looking for samples.pyw :)
<syke_> hi
<syke_> several people (including myself) are reporting an issue where xulrunner-1.9 forces the removal of firefox-3.0, and then it is impossible to get it reinstalled
<syke_> this just started this morning, in case developers aren't aware of the issue
<qense> wasn't the xulrunner and firefox hug day thursday :P this bug is just too late
<qense> syke_: it's probably a dependency issue
<qense> what's the bug report at LP?
<syke_> I don't know that there is one -- this literally juts started happening to everyone sometime between last night and a few hours ago
<qense> :(
<jdong>  1.9~b5+nobinonly-0ubuntu1
<syke_> it does appear to be a dependency issue
<jdong> yeah brand new versions just uploaded it would seem
<jdong> published 3hrs ago
<jdong> could just be a transient archive issue?
<syke_> I'm happy to try thing here locally and pass the info along to #ubuntu+1, if it works
<qense> the bug isn't reported
<qense> do you think it's useful to open a bug report or is it likely going to be fixed very soon when firefox-3.0 is updated>
<jdong> syke_: can you file a bug report with the symptoms?
<syke_> sure
<jdong> thanks :) just so that the mozilla folk not active rigth now are aware of the issue :)
<qense> syke_: are you a member of ubuntu-bugcontrol?
<muhaha007> mok0: samples.pyw doesn't seem to exist
<qense> otherwise I can set the importance to high
<muhaha007> mok0: it's not in /usr/* or /lib/*
<syke_> qense: nope, wasn't aware of such a thing
<qense> ok
<syke_> should I be?
<qense> no :)
<syke_> heh ok
 * Gnine thanks all folks who make ubuntu possible
<LaserJock> muhaha007: there's a samples.py in pythoncard-doc but that's it, as far as I could tell
<muhaha007> mok0: on the project-page-documentation they say, that there should be a samples.pyw in /usr/lib/python2.5/...
<muhaha007> mok0: I hope they didn't cut that out in ubuntu repo ;)
<LaserJock> muhaha007: there isn't a samples.pyw in Ubuntu
<LaserJock> muhaha007: but you should see if samples.py is equivalent
<muhaha007> mok0: it's not :)
<muhaha007> samples.pyw is a binary for showing all the examples with source code and stuff
<muhaha007> mok0:http://pythoncard.sourceforge.net/walkthrough1.html
<LaserJock> muhaha007: oh, that could be why it's not there
<LaserJock> muhaha007: what if you ran samples.py?
<muhaha007> mok0: cant, must change it to executable first :)
<muhaha007> mok0:but that shouldn't be the problem
<LaserJock> you can run it with python
<LaserJock> python samples.py
<muhaha007> mok0:whooops: gives me errors in source code
<muhaha007> mok0:if I run it with python, nothing happens
<muhaha007> doesnt seem to be the binary I am searching for
<syke_> https://bugs.launchpad.net/ubuntu/+source/xulrunner-1.9/+bug/212416
<ubotu> Launchpad bug 212416 in xulrunner-1.9 "latest xulrunner-1.9 update breaks firefox-3.0" [Undecided,New]
<syke_> there's that bug
<LaserJock> muhaha007: well, I don't know what to tell you. The samples are there so you can try them out and the html docs as well
<muhaha007> mok0:I googled for it, found one entry in ubuntu-forum, but no solution, because there was a problem installing it from the source code
<qense> syke_: have others confirmed it?
<syke_> qense: yes
<Gnine> #ubuntu-bugs is more suitable place for such announcements
<syke_> as I said, there is now a steady stream of people coming into #ubuntu+1 and reporting the sympthoms
<syke_> gnine: I will note for the future
<qense> pl
<qense> ok*
<syke_> qense: is there anything else you'd like me to try, or add to the bug report?
<qense> it's complete for now, but be prepared to ask questions from developers
 * jdong updates his hardy chroot and takes al ook
<syke_> answer questions, you mean? :)
<syke_> certainly
<syke_> another issue that comes up a few times a day for the last few months is this one: https://bugs.launchpad.net/ubuntu/+bug/197558
<ubotu> Launchpad bug 197558 in linux "ssb module breaks BCM4328 with ndiswrapper (regression from 2.6.24-10)" [Medium,Triaged]
<qense> syke_: lets move to #ubuntu-bugs
<syke_> sure
<jdong>      3.0~b4+nobinonly-0ubuntu1 0
<jdong> syke_: it's because firefox 3.0b5 has not hit the archives yet
<syke_> jdong: hopefully it's on its way, then?
<syke_> and wasn't just a partial commit?
<jdong> syke_: yeah, it should be on its way. this problem should resolve itself in a few hours
<jdong> syke_: you can verify by typing "apt-cache policy firefox-3.0"
<jdong> note that it reports 3.0~b4 is in the repos
<jdong> and doing the same for xulrunner-1.9 reports 1.9~b5 is the current version
<syke_> jdong: correct
<syke_> I had another question -- can the gcc-snapshot of the gcc 4.3 branch be moved to a gcc-4.3 package, then gcc-snapshot pointed at the actual trunk (4.4)?
<syke_> bueller?
<LaserJock> syke: I doubt we'd do that kind of change for hardy
 * jdong starts looking at a backport of xulrunner
<jdong> go betas.
<LaserJock> oh man
<syke> ok. just seems weird to have a real gcc release still as a snapshot
<jdong> syke: well at the time it's packaged it was a snapshot
<syke> wasn't gcc-4.2 quickly shifted from snapshot to a discrete package?
<jdong> and as LaserJock said it's likely too late in the release cycle to put in a new gcc
<qense> I don't know what to do next with bug 186264 , it contains a lot of information already, but I couldn't find the actual cause. Are there any developers around here who know more about this piece of software and can help?
<ubotu> Launchpad bug 186264 in hal "keyboard randomly goes dead; takes a logout to restore functionality." [Undecided,Incomplete] https://launchpad.net/bugs/186264
<syke> well, not as the default, for sure ;)
<LaserJock> syke: well, it actually is a svn snapshot
<jdong> bzr version
<jdong> grr
<syke> laser: I get that, but gcc 4.3 was released almost a month ago now :) trunk is now 4.4
<LaserJock> syke: sure, but it's not lying to call it a snapshot ;-)
<syke> er, sure.. that's one way to look at it ;)
<syke> I did notice that it is now a snapshot of the 4_3 branch, rather than trunk, at this point
<LaserJock> yeah
<syke> is it just a matter of the usptream debian providing a discrete 4.3 package?
<syke> (or do they even do such a thing?0
<syke> it wouldn't matter to me if I didn't have to futz with symlinks as much to use gcc 4.3 for my local development
<LaserJock> I believe that's exactly it
<syke> ok cool
<LaserJock> 4.3 entered debian on the 2nd
<LaserJock> which is a long time after our Feature Freeze
<syke> 3/2 or 4/2?
<LaserJock> 4/2
<syke> ok
<LaserJock> sorry, I was wrong
<syke> hm?
<LaserJock> 3/9 was the first 4.3 version in Debian
<qense> Sorry for bumping but I've been trying to get an answer for the whole day: I don't know what to do next with bug 186264 , it contains a lot of information already, but I couldn't find the actual cause. Are there any developers around here who know more about this piece of software and can help?
<ubotu> Launchpad bug 186264 in hal "keyboard randomly goes dead; takes a logout to restore functionality." [Undecided,Incomplete] https://launchpad.net/bugs/186264
<poningru> any reason why firefox was uninstalled just now?
<syke> btw, the firefox-3.0 update is now in my repo and things are happy again
<syke> pon: do another update, then reinstall
<qense> so the bug can be marked as invalid or fix released
<syke> yup
<syke> and the several duplicates that have popped up in the last hour
<syke> laser: I'll try poking my canonical rep on that front, also
<LaserJock> syke: which front?
<syke> laser: both this ndiswrapper issue and gcc-4.3
<syke> at my work we are switching to gcc-4.3 aggressively since it now has a built-in warning that find stack-based buffer overflows
<syke> -Warray-bounds, which works by default with -O2 and -Wall
<LaserJock> well, you can use gcc-snapshot
<syke> we also got about a 5% increase in performance in one of our big C++ apps just by recompiling in GCC 4.3 thanks to the new constant folding
<syke> yes, but as I say, it's a pain to use/deploy since the symlinks all have to be updated
<LaserJock> well, I guess you could ask then, but I seriously doubt we'd make that change this late
<syke> yup, never hurts to ask
<syke> btw, I really appreciate you guys being so helpful/positive :)
<LaserJock> better than your Canonical rep would be to ask doko
<LaserJock> he's the toolchain guy and does much of the gcc maintaining in Debian and Ubuntu
<syke> appears to be idle -- any idea when he is usually on?
<LaserJock> European business hours
<laga> syke: you can probably also rebuild the debian deb on your box isntead of building from source.. that might save you some symlinking hassle..
<LaserJock> and probably not until the weekend is over
<syke> laga: that's a good idea, actually -- thanks!
<LaserJock> laga: yeah, that would probably be a good idea
<syke> we try to not customize the ubuntu too much, but we already have to for eclipse-cdt and whatnot
<laga> syke: pbuilder might be a good friend here
<syke> pbuilder?
<syke> I already have been building local KDE packages for optimization, testing, and bugfixes
<LaserJock> syke: https://wiki.ubuntu.com/PbuilderHowto
<LaserJock> allows you to build .debs in a clean chroot
<LaserJock> and you can build .debs for multiple releases on a single machine
<syke> oh cool, thanks! I was just using dpkg-buildpackage before
<LaserJock> pbuilder is a lot cleaner
<syke> it certainly reads that way ;)
<syke> brb
<LaserJock> if you have LVM free space around you could also try https://help.ubuntu.com/community/SbuildLVMHowto
<LaserJock> that's pretty darn close to the environment that all the Ubuntu .debs are built on
<poningru> :(
<poningru> I had to install firefox manually
 * poningru is wondering why updating removed firefox
<LaserJock> poningru: there was a xulrunner/firefox mixmatch
<LaserJock> temporary archive issue
<poningru> ah 1.9
<poningru> gotcha
<poningru> wait I thought gecko 1.9 was gran paradisio
<LaserJock> is there a problem with that?
<poningru> I'm just confused... digging around to figure out what the problem is
<LaserJock> what problem?
<poningru> the mixmatch
<poningru> the xulrunner/firefox version mismatch issue
<poningru> ignore me I'm just confused
<syke> poningru: it's been resolved -- people should be able to update and reinstall firefox3 now
<syke> (and monodevelop_)
<poningru> sweet danke
<emgent> heya
#ubuntu-devel 2008-04-06
<YokoZar> So it looks like Gnometris is still completely broken by default in Hardy
<LaserJock> how is it broken?
<YokoZar> If you use the default theme, it renders the tiles way too slowly and becomes very uncontrollable after a few lines of blocks build up
<YokoZar> https://bugs.launchpad.net/bugs/138586
<ubotu> Launchpad bug 138586 in gnome-games "Gnometris controls very unresponsive when keys are held down" [Medium,Confirmed]
<LaserJock> hmm, works fine here
<YokoZar> Try pre-filling 10 rows with tango shaded theme, then just hold down left and right
<Fujitsu> The default is still Tango Shaded (or was a week ago), so it's rather painful once you've got more than a dozen blocks :(
<YokoZar> It's really embarassing actually.  Can't run Tetris on our amazing new high performance operating system (it's broken in Gutsy too)
<Fujitsu> Yep.
 * minghua hopes that minesweeper still works fine.
<YokoZar> minghua: you can also install wine and run winemine from the terminal :)
<LaserJock> well, does somebody want to change the default?
<YokoZar> LaserJock: it's a main package, right?
<LaserJock> YokoZar: yeah
<YokoZar> LaserJock: well, I nominate a core dev then ;)
<LaserJock> YokoZar: you might want to email ubuntu-desktop
<ScottK2> YokoZar: You can make a debdiff and subscribe ubuntu-main-sponsors
<YokoZar> ScottK2: I guess so, it seems like no one else wants to do it, heh
<emgent> heya ScottK2
<ScottK2> heya emgent
<climatewarrior> does anyone know if this is a bug
<climatewarrior> I installed ubuntu hardy beta and restricted doesnt seem to recognize my broadcom card. In gutsy it automatically fetched the firmware and got everything working
<LaserJock> climatewarrior: perhaps bug #197558
<ubotu> Launchpad bug 197558 in linux "ssb module breaks BCM4328 with ndiswrapper (regression from 2.6.24-10)" [Medium,Triaged] https://launchpad.net/bugs/197558
<climatewarrior> humm thats a different issue. I have a broadcom 4309 and the device works. The only issue is that I had to manually do the firmware cutting. In Gutsy restricted detected my card. Fetched the firmware from the internet and cut it for me.
<climatewarrior> i just wanted to know if this a known issue or something. Because if its not I wanted to file a bug report.
<climatewarrior> Bug #201294 seems to be the same as mine
<ubotu> Launchpad bug 201294 in restricted-manager "Restricted manager doesn't notice broadcom" [Undecided,New] https://launchpad.net/bugs/201294
<climatewarrior> hahah found it at the same time. Yeah that seems to be it. But it seems that nobody is working at it
<climatewarrior> ok, dont worry. Its a known issue
<climatewarrior> https://blueprints.launchpad.net/ubuntu/+spec/restricted-manager-rewrite
<climatewarrior> Whiteboard     jockey is in hardy, and being tested and fixed.  Compared to gutsy's rm, the following things are still missing:
<climatewarrior> Â - KDE port, Martin Bohm is working on it
<climatewarrior> Â - broadcom wifi hander (easy to implement)
<ashes_of_youth> can anyone offer me some advice regarding a broken translation?
<calc> hmm launchpad-integration works a lot better than using the url, heh, i need to get this in ooo asap
<calc> it actually reports useful info, i should have worked on this bug a long time ago
<ashes_of_youth> hello
<calc> hi
<Fujitsu> calc: Indeed. No more asking on every bug which version people have.
<calc> Fujitsu: yea
<ashes_of_youth> guys, i am trying to find out once a bug has been nominated, are there any further steps to take?
<Fujitsu> Why did you nominate a bug?
<ScottK2> ashes_of_youth: Not unless you are going to try and fix the bug.
<ashes_of_youth> someone else nominated one of my bugs
<ashes_of_youth> its a broken translation, which i've fixed on launchpad
<ScottK2> Ah.
<ScottK2> If I knew something about translations in Ubuntu, I'd be glad to help you figure it out ...
 * calc patches up for lpi to see if it works :
<calc> :)
<ashes_of_youth> i guess i'll leave it for now then...
<emgent> heya calc :)
<calc> emgent: hi
<calc> building test debs with more proper lpi support (still not linked)
<vlowther> Bug #212660, suspect mjg59's three headed monkey spootted in wild in 2.6.24-1[45]
<ubotu> Launchpad bug 212660 in linux "kernel 2.6.24-15 fails suspending" [Undecided,New] https://launchpad.net/bugs/212660
<YokoZa1> pitti: Hmm, my blog posts don't seem to be getting to Planet Ubuntu.  I noticed you committed after me, have you been having a similar problem?
<sabdfl> anybody here know how to use unattended-upgrade ?
<Nafallo> sabdfl: like in turn it on?
<sabdfl> yes
<sabdfl> i thought one only had to install it
<Nafallo> System, Administration, Software Sources
<Nafallo> then tab Updates and Install security updates without confirmation
<Nafallo> :-)
<slytherin> pitti: I think I have found the problem for OOo FTBFS on powerpc. But I am unable to test it since I don't have much disk space on my machine. We need to remove the code from rules file that disables java on powerpc. Look for this line - Java causes powerpc build to fail.
<slytherin> Mithrandir: Hi, Can you please look into the missing binaries bug for bluez-utils. I think there is no other way to fix it now.
<Hobbsee> slytherin: which bug #?
<slytherin> Hobbsee: regarding what? bluez-utils?
<Hobbsee> yes
<slytherin> Hobbsee: bug 191704
<ubotu> Launchpad bug 191704 in bluez-utils "hidd binary removed form bluez-utils package unable to connect as a result" [High,Confirmed] https://launchpad.net/bugs/191704
<slytherin> Hobbsee: and also bug 192403
<ubotu> Bug 192403 on http://launchpad.net/bugs/192403 is private
<slytherin> oops, bug 192043
<ubotu> Launchpad bug 192043 in bluez-utils "latest bluez-utils is missing /usr/bin/pand" [Undecided,Confirmed] https://launchpad.net/bugs/192043
<Hobbsee> slytherin: StevenK might end up looking into that
<slytherin> Hobbsee: Ok. Can you also help me with OOo FTBFS on powerpc? I think I have found out solution but don't have much space on my ibook to test it. :-(
<Hobbsee> no
<Hobbsee> there might be a community ppc machine somewhere still, though.  TheMuso may remember
<slytherin> Hobbsee: Ok. I will try contacting him in my night.
<Hobbsee> slytherin: he's @ canonical now, so you might try him during standard au working hours.
<slytherin> Hobbsee: So that means I will have to wait till tomorrow.
<Hobbsee> probably, yes
<slytherin> Hobbsee: Ok. Thanks for info.
<Hobbsee> y/w
<sabdfl> Nafallo: and on a server?
 * Hobbsee tries to remember what hte ppc build machine was called, on imbrandon's server....
<Hobbsee> darn, it's been far too long since i've used it
<Nafallo> sabdfl: edit /etc/cron.daily/apt I think. haven't seen a CLI application for that I don't think.
<Nafallo> sabdfl: aha! there is another way the README says ;-)
<Nafallo> To activate this script you need a current apt and then setup
<Nafallo> /etc/apt/apt.conf to include:
<Nafallo> APT::Periodic::Update-Package-Lists "1";
<Nafallo> APT::Periodic::Unattended-Upgrade "1";
<sabdfl> why on earth doesn't it do that when it's installed?
<Nafallo> sabdfl: you'd have to ask mvo :-)
 * Hobbsee was wondering that too
<sabdfl> thanks Nafallo, will do
<laga> what upgrades are pulled in by unattended-upgrade?
<Hobbsee> laga: apt-get upgrade, i think.
<Nafallo> sabdfl: are you going for the pub on Friday anyway? :-)
<Nafallo> laga: security.ubuntu.com only :-)
<Hobbsee> wow, that's old when it references dapper.
<laga> Nafallo: ah, good. :)
<Hobbsee> sabdfl: i was going for the "why isn't this installed by default", actually
<laga> Nafallo: still not a good idea becuase security updates aren't always trouble free :)
<Hobbsee> particularly for xserver
<Nafallo> Hobbsee: because of the reason laga said? :-)
<Hobbsee> Nafallo: yeah, but still.
<sabdfl> Hobbsee: it will become a question in the server install in 8.10
<laga> at least in feisty, some kernel updates in feisty-security also had support for new hardware which led to some breakage here.. easy to fix, but still surprising :)
<sabdfl> in exchange for the "make your clock UTC" question
<Nafallo> Hobbsee: because security updates have regressions from time to time. I rather have a hard to get exploit then a security update killing SQL ;-)
<sabdfl> imo, installing the package should activate it
<Nafallo> sabdfl: kewl :-)
<Hobbsee> sabdfl: ah, right.
<Hobbsee> sabdfl: well, yeah, that's the other thing.
<sabdfl> at least, the UTC question will disappear if windows is not on the machine
 * Hobbsee could hijack, and fix the package....
<Hobbsee> but, seeing as it has "apt" in the name, that may not be a great idea...
<slytherin> Hobbsee: can you please give back f-spot on powerpc?
 * Hobbsee flips the magic switches
<Hobbsee> slytherin: given back
<laga> Hobbsee: what does "giving back" mean? i've heard it a few times in here so i'm curious :)
<Hobbsee> laga: sometimes packages fail to build because of other things that haven't built, or other transient stuff.
<Nafallo> haha
<Hobbsee> laga: to give them back means to requeue them, so they're added to the build queue again
<Hobbsee> for slower arches, it's actually quite common
<Nafallo> people are coming up with names for releases up until 12.10 in -se ;-)
<laga> Hobbsee: ah, thanks for the explanation
<Hobbsee> some will fail in depwait, so will be auto-retried, but others fail in such a way they need a manual giveback
<slytherin> Hobbsee: something wrong on buildd. f-spot depwaits on libgtkhtml3.16-cil. The binary is available on all arch. But not sure why buildd not able to find it.
<Hobbsee> slytherin: URL of the depwait?
<Hobbsee> ohj wait
<slytherin> Hobbsee: http://launchpadlibrarian.net/13146622/buildlog_ubuntu-hardy-powerpc.f-spot_0.4.2-1ubuntu1_MANUALDEPWAIT.txt.gz
<Hobbsee> yeah, found it, thanks
<Hobbsee> realised i already had it here, so didn't need to look it up
<Hobbsee> slytherin: libgtkhtml3.16-cil | 2.20.1-2ubuntu2 | hardy/universe | powerpc
<Hobbsee> slytherin: you'll need an archive admin with actual power.
<Hobbsee> unless sabdfl suddenly wants to give me the keys :P
<slytherin> Hobbsee: what do you mean. I thought you were buildd admin.
<Hobbsee> slytherin: file a bug asking them to promote  libgtkhtml3.16-cil on ppc (the others are in main), and subscribe ubuntu-archive.
<Hobbsee> slytherin: i am, but i don't work for canonical.
<Hobbsee> slytherin: so i only have access to some of the magic switches.
<slytherin> Hobbsee: oh. got it.
<Fujitsu> 1.2.4 will give access to overrides, IIRC.
<Hobbsee> Fujitsu: for main or universe?
<Hobbsee> Fujitsu: or both, i guess?
<Fujitsu> The web UI gets overridability, I believe.
<Fujitsu> Probably both.
 * Hobbsee thought the general thing was for universe archive admins to be able to bump to multiverse, but hopefully archive admins to main will happen too
<Hobbsee> slytherin: have you met rmadison?
<Nafallo> :-)
<slytherin> Hobbsee: yes. Just forgot to use it. :-)
<Hobbsee> slytherin: and if it says the package isn't available, and the package you want to build is in main, it's saying that you should check if the builddep has dropped to universe.
<Hobbsee> slytherin: ahhh, np.
<slytherin> Hobbsee: done. bug 212801
<ubotu> Launchpad bug 212801 in gnome-desktop-sharp2 "Please promote to main on powerpc" [Undecided,New] https://launchpad.net/bugs/212801
 * Hobbsee acks
<pitti> Good morning
<ion_> Howdy
 * pitti waves from Austin
<protonchris> Good morning to you too
<ion_> pitti: Try to seem as innocuous as possible to avoid being classified as an enemy combatant and getting thrown to Gitmo. :-)
<Hobbsee> heya pitti!  *hugs*
 * pitti hugs Hobbsee
<Hobbsee> :)
<pitti> ion_: I'll keep my brim pulled down low
<penguin42> would it be possible to get paman/padevchooser installed by default on hardy - it looks like it might make it easier to see wtf is going on with pa
<Hobbsee> by now, no?
<cody-somerville> Hobbsee, are you on the release team?
<Hobbsee> cody-somerville: yes.
<cody-somerville> Do you have time for a quick chat?
<Hobbsee> fsvo quick, yes.
<penguin42> Hobbsee: PA is pretty high up the list of problems for upgrades - and it's not easy for people to debug
<penguin42> Hobbsee: Talking users running pacmd to see what's going on sounds like a recipe for disaster
<ernstp> What's the procedure to request a debian import again?
<Hobbsee> !sync
<ubotu> Sorry, I don't know anything about sync - try searching on http://ubotu.ubuntu-nl.org/factoids.cgi
<Hobbsee> bah
<Hobbsee> shoujld be on https://wiki.ubuntu.com/MOTU/Contributing
<Hobbsee> pitti: why is'nt all of abiword demoted?
<Hobbsee> i don't see anything keeping it there?
<pitti> Hobbsee: because so far we wanted it in main? pretty GNOMEish
<pitti> Hobbsee: it's seeeded
<pitti> seeded, too
<Hobbsee> pitti: where, though?
<Hobbsee> pitti: i thought you all used oo.o, and it was only xubuntu that used abiword
<pitti> in ubuntu.hardy/dvd, edubuntu.hardy/supported, xubuntu.hardy/desktop
<Hobbsee> ahh
<Hobbsee> pitti: so, why is abiword (binary) in universe?
<Hobbsee> shouldn't it all be seeded?
<pitti> because Xubuntu is in universe, and in Ubuntu we only want -gnome
<Hobbsee> ahhh, and -plugins, i take it.
<pitti> well, I guess it wouldn't hurt too much to seed abiword, too
<pitti> yes
<Hobbsee> pitti: what are your thoughts on upgrading it?
<Hobbsee> cody-somerville: would like to, for xubuntu
<pitti> Hobbsee: I think we should do it, but test it really well
<pitti> is there a PPA with 2.6?
<Hobbsee> cody-somerville: ^^
<cody-somerville> No, I'm just working through my e-mail. I can certainly make that happen though.
 * Hobbsee wonders hwo apt-show-versions is different to rmadison
<cody-somerville> I can also get the Xubuntu testing team to add in specific testing for Abiword since we ship (a version of) abiword.
<Hobbsee> cody-somerville: that'd be a good idea
<cody-somerville> hmm...
<cody-somerville> Abiword has split their source package up
<xhaker> ahh weekends... pitti care to look into bug #197968
<ubotu> Launchpad bug 197968 in libmtp "Link in udev rules.d" [Wishlist,Confirmed] https://launchpad.net/bugs/197968
<cody-somerville> Stupid wireless :/
 * cody-somerville wonders what he missed.
<soren> Nothing.
<cody-somerville> what was my last?
<soren> 15:32:34 < cody-somerville> Abiword has split their source package up
<soren> 15:34:39 < xhaker> ahh weekends... pitti care to look into bug #197968
<soren> 15:34:43 *** fta_ n=fta@unaffiliated/fta has joined #ubuntu-devel
<soren> 15:35:04 < ubotu> Launchpad bug 197968 in libmtp "Link in udev rules.d" [Wishlist,Confirmed]  https://launchpad.net/bugs/197968
<ubotu> Launchpad bug 197968 in libmtp "Link in udev rules.d" [Wishlist,Confirmed] https://launchpad.net/bugs/197968
<ubotu> Launchpad bug 197968 in libmtp "Link in udev rules.d" [Wishlist,Confirmed]
<cody-somerville> The rest of what I said: That is probably why Ubuntu and Debian is still at 2.4.6
<cody-somerville> They split up the source package with the 2.5.0 release.
<shaya> anyone seen vorlon?
<slangasek> nope
<james_w> hehe
<shaya> hola
<shaya> just responded to your response on my grub bug
<shaya> did ubuntu ever ship a grub pre 0.97?
<slangasek> oh, "spotter" is you, heh
<shaya> yes
<shaya> shaya potter
<slangasek> ubuntu would have shipped a pre-0.97 grub at some point
<james_w> https://edge.launchpad.net/ubuntu/+source/grub
<james_w> says pre-dapper
<shaya> so upgrading to hardy will kill render it unbootable (especially if uninstall old kernel)
<slangasek> e.g., sarge shipped with 0.95+cvs-something, and there were Ubuntu releases in the same timeframe; that seems to be the version breezy shipped with
<shaya> this laptop was an old debian laptop
<slangasek> what exactly is it that causes the boot failure?
<shaya> partitioned it and installed dapper
<shaya> new kernels cant boot w/ older grub
<shaya> known issue
<slangasek> how old?
<shaya> google "no setup signatures found"
<emgent> hi people
<shaya> unsure
<shaya> checking
<slangasek> the oldest I find in the changelog is still 0.95+cvs
<slangasek> and that's all the way back to warty
<shaya> but I think there's a bigger issue w/ grub as well, as mbr portion never gets updates
<slangasek> well, neither does second-stage, unless you manually run grub-install
<shaya> right
<shaya> that's probably the bigger issue
<shaya> the second-stage
<shaya> the mbr portion is minimal
<slangasek> I will say that making changes to how we handle *any* of this stuff, three weeks before an LTS release, is a losing proposition.  I don't believe three weeks is enough time to chase down the regressions that will be introduced by adding new code to re-write MBR/second stage on upgrade.
<shaya> :)
<shaya> no
<shaya> I'm not saying to auto do it
<shaya> I'm saying in kernel preinst check
<shaya> and if fail, warn in big letters
<slangasek> well, then the kernel has to know how to detect a broken bootloader
<shaya> right
<shaya> can grep stage2
<shaya> q. being how to "find" stage2
<slangasek> it should be at /boot/grub/stage2 for any non-mangled Ubuntu install
<slangasek> if it's not, it's out of scope
<slangasek> hmm, what does "file /boot/grub/stage2" give you?
<slangasek> here, it spits out a GRUB version for me
<shaya> well, I'm updated now
<slangasek> ah, heh
<slangasek> still have the old one around somewhere?
<shaya> found a feisty dvd
<shaya> booted into single user
<shaya> chrooted into fs
<shaya> and fixed
<shaya> no
<shaya> it was 0.92
<slangasek> yeah, I don't know where to get an 0.92 to compare with
<slangasek> but if "file" is enough to answer this question, that's a really easy check
<shaya> /boot/grub/stage2 isn't even executable for me
<shaya> ah
<shaya> yes
<shaya> I see
<shaya> just need to find the newest version where grub is incompatible
<slangasek> so far the only other instance of this problem that Google is giving me is for grub 0.91
<shaya> yes
<slangasek> which is even older, and definitely older than the first version Ubuntu shipped
<shaya> :)
<shaya> reading grub changelog
<shaya> see if there's any mention
<shaya> slangasek: I'm not the first to hit this
<shaya> https://answers.launchpad.net/ubuntu/+question/29013
<slangasek> mmm
<shaya> well he beat me by a few hours
<shaya> I was about 12 hours ago :)
<shaya> followed up
<laga> cjwatson: here? i'm working on the mythbuntu seeds now :) what does the Task-Key field do?
<soren> laga: If the package mentioned there does not exist, the task will not be shown.
<soren> laga: If one of the other packages is not available it simply will not be installed.
<laga> oh, it's as simple as that. great, thanks.
<alex-weej> does anyone know if gnome 2.22.1 will be uploaded before hardy release?
<JohnPinWa> Hello.  I'm looking for ways to contribute to Ubuntu as a developer.  I'm reading the "How to get involved" web pages but can't find the "Do this step next" instructions.  Who do I tell I'm here and ask how I can help?
<laga> JohnPinWa: i think #ubuntu-motu might be a good starting point, too
<JohnPinWa> Yeah, the developer stuff says go see Motu and the Motu stuff says "Well, start with developer".  Kinda confused now.
<JohnPinWa> This channel has more activity than the motu so I started here.  I'll ask there too.
<YokoZar> pitti: any objections to me uploading a new ia32-libs?
<laga> JohnPinWa: heh :)
<laga> JohnPinWa: you can also start looking at blueprints in launchpad, then contact the person who's listed as a contact for the blueprint if you're interested
<JohnPinWa> Probably just my ignorance.  If things aren't just the way I expect them to be I have trouble reaching out sometimes.  But I still might be useful.
<laga> JohnPinWa: no worries! i'm sure you'll do great. a lot of open source development happens because people want to scratch an itch. so, if a bug is annoying you, fix it and share the patch.. or create that awesome new app you always wanted and let others benefit.
<JohnPinWa> Laga: Thanks.  Getting some feedback on the Motu channel so I'll see where that goes.
<JohnPinWa> I do appreciate the help.
<warp10> Hi all!
<mok0> Hi warp10
<warp10> hey mok0!
<emgent> hey
<Ng> mjg59: how likely are ICH8 chipsets not listed in http://www.codon.org.uk/~mjg59/tmp/ahci_quirk_2.6.24.diff to work? The X300 has 2850 (IDE controller) and 2829 (AHCI controller). Mostly just curious if I can get the DVD writer on AHCI
<mjg59> It's unlikely that the DVD writer is SATA
<mjg59> If the hard drive is already appearing on AHCI, then that's as AHCI as you get
<mezell1> There's a fairly serious bug that has been in launchpad for over a month that is affecting me, but no developer has commented on it... what's the chance of getting a developer to look at and fix the problem before Hardy release?
<mok0> mezell1:  bug #?
<mezell1> 191884
<mok0> bug 191884
<ubotu> Launchpad bug 191884 in libnss-ldap "wrong id behaviour on a system with LDAP" [Undecided,Confirmed] https://launchpad.net/bugs/191884
<mezell1> with the current combination of coreutils and libnss-ldap, you cannot get group information
<mok0> mezell1: hmm
<mok0> mezell1: has it been fixed in Debian?
<mezell1> debian testing has version 259 instead of the 258... i'm not sure if that fixes it or not
<mezell1> i've only installed 260
<mok0> mezell1: ... and that fixes the problem?
<mezell1> mok0: installing 260 from source (ie, from padl, not debian) fixes the problem
<mok0> mezell1: It would be good if you would do a bit of work, but then there is a good chance that the bug could be fixed before hardy
<mok0> mezell1: you need to make a comment for the bug saying that the new upstream version solves the problem, and (2) attach the part of upstream changelog that explains diffs from 258-260
<mezell1> mok0: my last comment notes that the latest upstream version fixes it, and I provide instructions as a workaround for others with the problem
<mezell1> mok0: in the ChangeLog, version 260 lists one change, "* patch from Ralf Haferkamp <rhafer@suse.de>: only set errno for NSS_TRYAGAIN"
<mok0> mezell1: I see that, but you need to make a comment aimed at the sponsor, not the users.
<mezell1> mok0: it does not point to a bugzilla number, so I can't verify what and how it actually fixes
<mok0> mezell1: but it does solve your problem?
<mezell1> mok: i haven't pinpointed if it's that change, or one from 259
<mok0> mezell1: can you do a diff on it?
<mezell1> mok0: i don't see a place to download older versions from padl, but I guess I could grab the 259 source from debian
<mok0> :-)
<mok0> yes
<mok0> mezell1: you also may want to subscribe ~ubuntu-directory to the bug when you're done with it
<mezell1> mok0: thanks for your help
<calc> anyone know how to split an argument in shell into multiple arguments or to variables?
<calc> eg i have an arg "foo bar baz" and i want to be three separate bits
<persia> calc: If you call `myscript foo bar baz`, you ought be able to access the variables inside myscript (assuming shell) as $1, $2, $3, etc.
<calc> persia: i'm trying to work around a bug that causes the arguments to show up as a single argument
<calc> persia: OOo calls external programs with the argument list space separated but not as individual arguments
<calc> i need to cause them to become individual arguments for the program i need to run, so i was going to wrap it and split it somehow
 * persia tries something else
<calc> i'm pretty sure its easy to do and i think i used to know how to do it, but its been a long time since i did it, and never had a use for it since
<calc> for msg in $@  will split it on space but then i need to somehow execute with all the split parts on one line
<persia> calc: The wrapper script contains a shebang line, and a call to the real script with $1.  A generic wrapper script would have the single line "$0 $1", as long as you can guarantee that OOo never works properly.
<calc> persia: oh thats all it needs?
<persia> Well, basically.  As soon as you expand $1 in a shell-script context, it becomes three tokens if called to another shell.  If you want to do it within a single script, you have to parse it, and so assign variables directly, rather than using $1, $2, etc.
<calc> persia: wow, thanks :)
<calc> i was thinking too hard about the problem :)
<persia> (and actually, you need something like $0-real $1)
<calc> i think there is a way to do the split in a single shell script but that isn't needed for this
<calc> thanks for the help :)
<calc> persia: so a generic call that doesn't use $0 would be something like this?
<calc> program=$1
<calc> shift
<calc> $program $@
<calc> ?
<persia> calc: Looks right.  Try calling `./foo bar\ baz\ quux` as a test.
<persia> Actually, no.  shift will eat all your arguments.
<calc> persia: it looked like it worked for me
<calc> persia: but i don't know if it would work in all cases
<calc> i did this though:
<calc> ./foo1.sh "/usr/bin/launchpad-integration -P openoffice.org -i"
<persia> calc: That ought to work.  Depends on your calling convention.  $program contains your entire quoted string.  I don't know what you ended up putting in $@
<persia> Try again with some more arguments: you may well breate it.
<persia> s/breate/break/
<calc> persia: oh yea it does :(
<persia> calc: Try just calling $($1), if the program name is part of $1
<calc> i forgot i can't get to the individual args until its executed
<calc> do i even need the $() wrapping it?
<calc> #!/bin/sh ; $1 - seemed to work
<persia> calc: Well then, that's even easier :)
<Ng> mjg59: that's unfortunate, but thanks
<james_w> calc: are you ever going to want to pass an argument with a space in to launchpad-integration?
<calc> james_w: no
<james_w> good, it seems like the API you have would never allow you to do that properly.
<calc> it only gets called like: -P packagename -i,-b,-t
<james_w> ok
<calc> i filed a bug upstream about the issue and just work around it like this :\
#ubuntu-devel 2009-03-30
<slangasek> calc: yes, we ought to fix up that GPL violation; have you opened a bug on raptor in Ubuntu?
<slangasek> mdke: split into per-language binary packages, yes - currently, gnome-user-guide is one of the 5 largest packages on the CD, and we could save a lot of that by splitting off the translations for languages that we don't ship on the CD (e.g., the large Swedish translation)
<calc> slangasek: not yet, i will go ahead and do so
<calc> slangasek: i noticed we don't change raptor, should i file the bug as a sync request?
<UsamaAkkad> hello, if some one want to do minimal install cd for Mint or similar Ubuntu based distribution. what file should he change ?
<calc> slangasek: i filed it as bug 351331 and linked to the debian issue
<ubottu> Launchpad bug 351331 in raptor "Sync raptor 1.4.18-2 (main) from Debian unstable (main)." [Critical,Confirmed] https://launchpad.net/bugs/351331
 * calc wishes we could just get rid of openssl from the archive
<TheMuso> hrm I just got a weird failure to upload with amd64 pulseaudio, twice, first after initial upload, and second after I retried the build, thinking it was possiby transient. All other arches built and uploaded successfully.
<Hobbsee> TheMuso: looks like a launchpad error.  see #launchpad with https://launchpad.net/ubuntu/+source/pulseaudio/0.9.14-0ubuntu15/+build/923086
<TheMuso> Hobbsee: ah ok
<dholbach> good morning
<robert_ancell_> dholbach: hi
<dholbach> hey robert_ancell_!
<dholbach> how are you doing?
<dholbach> back at home?
<robert_ancell_> dholbach: sure am
<dholbach> ah great - how's life in .au? :)
<robert_ancell_> dholbach: I miss the comfy chairs in the London office though :)
<dholbach> hehe :-)
<dholbach> must have been quite a trip - how long did it get you to get back?
<robert_ancell_> dholbach: I left the hotel at 5:30am Saturday and got home at 9pm Sunday.  I think it's about 24 hours all up...
<dholbach> robert_ancell_: ugh - it's a shame we don't have the technology for "beaming people over" yet
<robert_ancell_> dholbach: I think there's a Canonical team working on that :)
<dholbach> robert_ancell_: sounds like an idea only somebody who was in space already could have ;-)
<robert_ancell_> dholbach: maybe that's the solution - you can travel faster when outside an atmosphere!
<dholbach> robert_ancell_: so if the whole free software thing doesn't work out we all work as receptionists at the ticket counters or what?
<robert_ancell_> dholbach: hehe
<DaSkreech> calc: ping :)
<dholbach> can somebody take a look at bug 350344 from the sponsoring queue?
<ubottu> Launchpad bug 350344 in laptop-mode-tools "Merge laptop-mode-tools 1.47-1 from Debian testing" [Undecided,New] https://launchpad.net/bugs/350344
<DaSkreech> How many packages are in main ?
<dholbach> DaSkreech: http://paste.ubuntu.com/140542/
<dholbach> errr
<dholbach> http://paste.ubuntu.com/140543/
<DaSkreech> wow
<dholbach> excusez-moi
<DaSkreech> ok thanks :)
<dholbach> the first one counted both sources and binaries
<DaSkreech> Where did the 8 go to?
<mdke> slangasek: that sort of thing is well beyond my packaging ability, but if it's not too late in the cycle, maybe someone else could do it
<mdke> slangasek: the other potential solution would be to do what we do in ubuntu-docs and only ship translations which are over X% complete, and see if that reduces the size of the package
<dholbach> DaSkreech: hm?
<DaSkreech> dholbach: main kinda implies open source packages but adding the sources gets you less than double the number of packages
<DaSkreech> you should have 8 more
<dholbach> DaSkreech: no, main is what is supported by Canonical - it's not directly comparable to Debian's "main"
<dholbach> http://www.ubuntu.com/community/ubuntustory/components
<pwnguin> DaSkreech: you can have a source package generate more than one binary package...
<DaSkreech> so it should be fun to track down what is in main which is not providing source
<DaSkreech> pwnguin: like app and app-data ?
<dholbach> DaSkreech: hu? everything in main does
<dholbach> DaSkreech: yes
<DaSkreech> not according to the numbers :-)
<Mithrandir> DaSkreech: why do you think so?
<Mithrandir> DaSkreech: can you find a single example of a package in main without corresponding source?
<pwnguin> but you do have a point, if you have 6234 source packages, wouldn't you expect at least 6234 binaries?
<DaSkreech> well if you have a number of binary packages each which has at least one source package
<DaSkreech> then you should have twice the packages when you have binary and source
<pwnguin> you know
<DaSkreech> there is less than that
<pwnguin> if you have a source package that builds universe and main binaries
<pwnguin> does it go in universe or main?
<Mithrandir> DaSkreech: no.  Each source package has at least one binary package (but often more).  Never the other way around, a binary package never has two sources.
<Mithrandir> pwnguin: main.
<pwnguin> Mithrandir: then obviously dholbach's cache is broke ;)
<DaSkreech> Mithrandir: it still doesn't detract from my argument
<dholbach> pwnguin: I'm happy with my cache right now :)
<Mithrandir> > wget -q -O - http://archive.ubuntu.com/ubuntu/dists/jaunty/main/source/Sources.bz2 | bzip2 -d | grep -c ^Package
<Mithrandir> 3024
<Mithrandir> > wget -q -O - http://archive.ubuntu.com/ubuntu/dists/jaunty/main/binary-i386/Packages.bz2 | bzip2 -d | grep -c ^Package
<Mithrandir> 6151
<Mithrandir> so you have around 3k sources generating about 6k binary packages.
<Mithrandir> pwnguin: dholbach only counted binary packages, nowhere did he count sources?
<pwnguin> (well he claimed he did, and i was foolish enough to trust him ;)
<Mithrandir> DaSkreech: your argument is the wrong way around, since you start by counting binary packages, not source packages.  You'll have at least the same number of binary packages as source packages, not at least the same number of source packages as binary packages.
<dholbach> pwnguin: in the first paste.u.c link I did
<pwnguin> dholbach: well your numbers dont add up :P
<DaSkreech> ah right
<pwnguin> or i misread
<DaSkreech> well I was only interested in binaries anyway :)
<pwnguin> "packages" is too generic =(
<pwnguin> Packages, i mean
<DaSkreech> Looks so
<pwnguin> you know what, it's like 1am. i should just sleep or something.
<mdke> hi dholbach
<dholbach> hiya mdke
<mdke> dholbach: could you do me a favour and take a look at this bug in ubuntu-docs - https://bugs.launchpad.net/bugs/303578
<ubottu> Ubuntu bug 303578 in ubuntu-docs "System->About Ubuntu homepage has glitchy "Thank you" line" [Medium,Triaged]
<mdke> dholbach: the cause of the bug is clear (comment 12) but I don't know how to fix it, any ideas?
<dholbach> mdke: I don't know - could it be a CDBS thing? creating those symlinks?
<mdke> dholbach: the problem is that in previous releases we shipped some symlinks in a particular location, and now we ship a directory - but dpkg doesn't remove the symlinks so people upgrading and missing that directory
<mdke> dholbach: so we need to include something in the upgrade process that removes those symlinks
<mdke> dholbach: the last comment has the commands required, I don't know how to put that in the package though
<dholbach> mdke: sounds like something you'd do in the maintainer scripts - I'd ask for advice on ubuntu-devel@ - my experience with maintainer scripts is luckily somewhat limited
<mdke> dholbach: ok, I'll do that, thanks
<dholbach> mdke: good luck :)
<pitti> Good morning
<StevenK> Morning pitti
<pitti> slangasek: kick bug-buddy> agreed, we don't use it by default anyway
<pitti> kirkland: no, I used --remove-home, not --remove-all-files
<pitti> kirkland: and semantically, /var/lib/ecryptfs/$user is really a part of your /home/$user, IMHO
<pitti> hey StevenK, had a good weekend?
<StevenK> pitti: Yup! You?
<pitti> StevenK: pretty good too; just an hour shorter :) (DST change)
<StevenK> pitti: Heh, the phone company's network time did that over the weekend
<slangasek> mdke: my biggest concern would be splitting out the languages that *are* mostly complete :)
<slangasek> pitti: ok; I guess seb128 is already poking at the gnome-desktop-python-desktop-2-gnome stuff, so I'll coordinate with him when he awakes
<pitti> slangasek: right, he's working on it; thanks
<slangasek> seb128: o hai
<slangasek> damn :)
<mdke> slangasek: yes, but as I understand your proposal, it would be to make gnome-user-docs consistent with the rest of the desktop, which is acceptable
<mdke> slangasek: there's not much point in a particular language being included in gnome-user-docs if the rest of the desktop is untranslated by default for that language
 * slangasek nods
<mdke> slangasek: ditto ubuntu-docs, and yelp itself
<mdke> (I don't know if yelp ships translations or has them in language packs)
<mdke> ah, it ships them in the package
<slangasek> pitti: ^^ what do you think, splitting gnome-user-docs by language?
<pitti> makes sense, of course, I just wished it wouldn't require manual packaging
<pitti> but the automatic one depends on a small soyuz feature which isn't there yet :(
<mdke> do you think we should do the same for ubuntu-docs?
<slangasek> mdke: that's less of low-hanging fruit
<seb128> that would win us lot of CD space for extra locales for sure
<slangasek> so I wouldn't have us spend the effort yet
<mdke> slangasek: ok, I was just thinking for consistency. Maybe for the next release cycle
<slangasek> for the next release cycle, maybe the automation pitti mentions will be available :)
<mdke> ok, I'll keep an eye out
<mdke> gtg
 * slangasek sees that gnome-user-docs bzr uses a separate branch for each distroseries, wah
<slangasek> that would be fine, if debian/control didn't currently point to the hardy branch :)
<pitti> seb128: can you ssh to ronne? hangs for me
<pitti> I'd like to fix the retracers
<seb128> pitti: hangs too
<pitti> seb128: ok, thanks; I'll talk to IS
<slangasek> pitti: bug #277589 reopened, looks like there's a bug in my attempted refactoring of the user-submitted patch :(
<ubottu> Launchpad bug 277589 in hotkey-setup "sony brighness on a geforce series older than 8 (nvclock works fine)" [Undecided,Fix released] https://launchpad.net/bugs/277589
<slangasek> mdke: should ubuntu-core-dev be a member of ubuntu-core-doc?
<superm1> slangasek, that reminds me, i wanted to ask what happened to the rest of getting rid of hotkey-setup? looks like a few thinkpad related bits in there still and that flip on the xorg stuff are left
<slangasek> superm1: the remaining thinkpad bits need to wind up as a udev rule, I guess, with the init script disabled by default if we've made it to that point; I meant to talk to thinkpad_acpi upstream (a DD), because he claimed recently that there were no thinkpads left that needed thinkpad_keys
<superm1> slangasek, ah. so likely better to get that taken care of during early karmic then
<superm1> and the DOS switching needs to be checked why those defaults aren't set in the kernel module yet too then
 * slangasek nods
<pitti> lamont: the patch in bug 348990 makes sense to me; do you want to apply it to Debian and sync, or should we apply it locally to Ubuntu?
<ubottu> Launchpad bug 348990 in postfix "Deinstallation doesn't delete all files" [Undecided,Confirmed] https://launchpad.net/bugs/348990
<slangasek> mdke: also, are there specific known reasons why you're still using pack-0.92 format for gnome-user-docs instead of something newer (and speedier)?
<pitti> it would perhaps help if "bzr upgrade" wouldn't consider pack-0.92 as "current"
<tkamppeter> mvo, doko, you are the Python maintainers? Can you have a look at bug 349781?
<ubottu> Launchpad bug 349781 in python-defaults "hplip not working after jaunty upgrade" [Critical,Incomplete] https://launchpad.net/bugs/349781
<tkamppeter> mvo, it seems that only the i386 build server produces broken builds of Python libraries written in C.
<dholbach> tkamppeter: that bug should be fixed since python2.6 2.6.1-1ubuntu5.1
<dholbach> tkamppeter: bug 349467
<ubottu> Launchpad bug 349467 in python2.6 "Many python programs fail with: "undefined symbol: PyUnicodeUCS4_DecodeUTF8"" [Critical,Fix released] https://launchpad.net/bugs/349467
<dholbach> tkamppeter: it looks like a dup AFAICT
<slangasek> yes
<dholbach> "Running sudo perl -p -i -e 's/PyUnicodeUCS2/PyUnicodeUCS4/g' /usr/lib/python2.6/dist-packages/cupsext.so does indeed fix the problem."
<slangasek> if editing is required, then that means we need to get that package rebuilt in the archive
<dholbach> slangasek: I think infinity said there was just python-hildon on lpia rebuilt with that pytho
<Keybuk> mvo: I had a fantastic bug with the dist-upgrader today
<Keybuk> the only thing it did to upgrade me to 9.04 was uninstall nvidia-glx
<mvo> Keybuk: with the partial upgrade?
<Keybuk> mvo: no
<Keybuk> turns out I had jaunty in my sources list pinned to "not upgrade"
<seb128> cjwatson: hi
<mvo> Keybuk: could you pastebin me your /etc/apt/preferences file please?
<Keybuk> Package: *
<Keybuk> Pin: release a=jaunty
<Keybuk> Pin-Priority: -50
<Keybuk> --
<seb128> cjwatson: we are getting several comments on bug #343668 now, the bbc server for the totem plugin is not working for some weeks
<ubottu> Launchpad bug 343668 in totem "BBC plugin doesn`t working" [Low,Confirmed] https://launchpad.net/bugs/343668
<seb128> cjwatson: do you think you could try to ping the bbc guys about that?
<mvo> Keybuk: ok, thanks
<slangasek> dholbach: then infinity's analysis is incorrect; http://launchpadlibrarian.net/24396323/buildlog_ubuntu-jaunty-i386.hplip_3.9.2-3ubuntu2_FULLYBUILT.txt.gz clearly shows python2.6-minimal 2.6.1-1ubuntu5, the broken version.
<slangasek> tkamppeter: a simple reupload of hplip is enough to fix this bug
<YokoZar> Man, it's very frustrating upstreaming bugs in launchpad now.  I can't figure out how to do it by just copy/pasting the upstream bug link
<pitti> YokoZar: "now"? the workflow didn't change recently AFAICS?
<YokoZar> pitti: the links on the page seem broken to me
<YokoZar> On non-beta launchpad I can click "also affects project" and just paste the link there when I click "I have the URL for the upstream bug"
<YokoZar> on new launchpad it's "simplified" by forcing me to type in the name of the project first
<YokoZar> Half the time I think I clicked the wrong thing, so I go to "Also affects distribution" which does have a URL for upstream bug reports I can copy paste, but when I do it there I get errors
<pitti> YokoZar: that should only happen for packages which don't already have an associated project, hmm
<YokoZar> I'm getting it on this bug (which already has an upstream bug task) https://bugs.launchpad.net/ubuntu/+source/wine/+bug/243390
<ubottu> Ubuntu bug 243390 in wine "Difficult to associate a Wine application as a handler or default handler for a file type" [Wishlist,Confirmed]
<YokoZar> affects Wine both Wine (Ubuntu)
<directhex> binfmt, and associate directly with the application .exe!
<YokoZar> directhex: the issue is mime types for data files, not the .exe
<YokoZar> directhex: eg I install Photoshop and it says it can open .jpgs, but it's very hard to make it so double clicking a .jpg will open it in photoshop
<directhex> YokoZar, i find file type association is a black art in general
<YokoZar> Windows has it's own separate list for these sorts of file handlers, and Wine needs to glue that into our own file type thing.  Then the desktop environment needs to be taught how to understand it as well
<directhex> tbh i think vista allows changing default filetype handlers really well
<slangasek> YokoZar: you can only have one task per upstream project on a bug, so of course saying 'also affects' wants you to pick a different project?
<YokoZar> slangasek: right, which is why I ran into this launchpad upstreaming issue because I wanted to link it to another upstream project (http://bugzilla.gnome.org/show_bug.cgi?id=379658)
<ubottu> Gnome bug 379658 in Desktop "Better integration with WINE when opening files in Nautilus" [Enhancement,Unconfirmed]
<YokoZar> launchpad doesn't want to figure out that's nautilus from just looking at the bug link
<slangasek> it never has
<slangasek> the cases where you don't have to fill out the upstream project are when it's already pre-populated the value for you
<YokoZar> hmmm I think you might be right
<YokoZar> I do still get confused by the upstream bug link on the "also affects distribution" page
<YokoZar> because I keep mixing up which of these two I'm supposed to be clicking on (my normal metric was to guess and look for the place to paste a URL, which got broken here since I needed to manually add nautilus first)
<tkamppeter> Thanks, dholback and slangasek, I will reupload HPLIP.
<slangasek> tkamppeter: cool, thanks :)
<\sh> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
<pitti> \sh: bless you
<\sh> Ã´h damn....
<\sh> I shouldn't clean my desk and putting papers on my keyboard ,->
<\sh> but now...desk is clean and I can go on holiday without anybody complaining: "You desk is totally chaotic" ,->
<pitti> \sh: enjoy your holiday!
 * directhex tries an update in a pbuilder
<\sh> pitti: hehe....waiting for the boy to come :)
<\sh> pitti: hopefully he will be released with jaunty ,-)
<pitti> oooh!
<pitti> \sh: congratulations! *hug*
<Keybuk> \sh: but will you name him Jaunty? :)
<\sh> pitti: thx :)
<Keybuk> Jaunty Hermann has quite a ring to it
<Keybuk> (and congrats, btw :p)
<\sh> Keybuk: when I can convince my wife to have "Jaunty" as third or fourth name...or much better as an official nickname (Artistname) then yes :)
<\sh> Keybuk: lastname won't be "Hermann" :) I'll go for the last name of my wife to be :)
<\sh> Keybuk: lastname will be a cameroonian lastname ... so it will fit into the "Ubuntu" story ;)
<\sh> ok...lunch time :) bbl
<tkamppeter> slangasek, dholbach, HPLIP is reuploaded now.
<dholbach> tkamppeter: super
<slangasek> @yay
<cjwatson> seb128: I already did
<cjwatson> seb128: I can mail them again (somebody else asked me about this too)
<seb128> cjwatson: well, people start suggesting we stop shipping the plugin now
<seb128> I'm not sure what to try
<seb128> try -> reply
<cjwatson> like I say, I'll mail them again
<seb128> thanks
<directhex> silly bbc. i pay my license fee dangnabbit!
<Keybuk> ==17268== Conditional jump or move depends on uninitialised value(s)
<Keybuk> ==17268==    at 0x40177B7: (within /lib/ld-2.8.90.so)
<Keybuk> oh, yay
<lamont> pitti: I'll make a pass through my bugs this week at some point
<pitti> lamont: shall I assign it to you? (it's in the sponsoring queue ATM)
<slangasek> Keybuk: ld's always had a few of those that are innocuous in practice, neh?
<slangasek> ld.so, I mean
<lamont> sure
<pitti> slangasek: you are currently doing syncs? can I smuggle one in?
<Keybuk> slangasek: yeah, I just hate it when valgrind is out of sync with them ;)
<slangasek> pitti: yes
<slangasek> Keybuk: ah, heh
<slangasek> pitti: what are you smuggling in? I'm done with the sync bug list now, just about to hit flush
<pitti> slangasek: I'm done (nano and postgresql-common)
<slangasek> ok
<directhex> yay @ slangasek
<Keybuk> slangasek: it makes my test suite full of FAIL
<slangasek> aww :(
<Keybuk> 13 of 13 tests failed
<Keybuk> Please report to http://bugs.launchpad.net/libnih/
<Keybuk> :-(
<ebroder> Can somebody mark bug #333197 as fix released in Jaunty and confirmed in Intrepid?
<ubottu> Launchpad bug 333197 in openafs "openafs-modules 1.4.8 segfault after stop" [Undecided,Fix released] https://launchpad.net/bugs/333197
<ebroder> (I can't do that without being on ubuntu-dev or something, right?)
<apw> bryce, you about?  wanted to talk about those i914 drm '*ERROR*' messages we have been seeing
<slangasek> perhaps he has the sense to not be up at 3:30
<apw> heh as you prove, its always worth asking
<slangasek> :-)
<\sh> there needs to be an whois field on freenode..that shows the timezone of the user ,-)
<broonie> \sh: No, that shows their sleep cycle. Timezone is not a reliable indicator!
 * slangasek records his as a parametric equation
<ogra> slangasek, what about daily builds, do you plan to enable them again at some point ?
<\sh> broonie: ok...much better
<slangasek> ogra: they are enabled, except for those cronjobs that involve livefs builds for ports because infinity was doing maintenance
<ogra> ah
<slangasek> infinity: can we re-enable the ports livefs cronjobs?
<ogra> right, i was indeed wondering about http://cdimage.ubuntu.com/ports/daily-live/ :)
<infinity> slangasek: We can, although the sparc buildd exploded on upgrade, so you'll either need to artificially disable sparc for now, or suffer with failures (should fail quickly with No Route to Host)
<slangasek> suffering with failures is fine
<slangasek> thanks
<ogra> great
 * ogra needs to see if oo.o finally ends up in the livefs ... having image builds is extremely helpful
<pitti> mvo: are you going to upload a new synaptic soon? if not, I'd like to do a no-change upload for bug 348225
<ubottu> Launchpad bug 348225 in synaptic "Remove inline translations from .desktop files" [Medium,In progress] https://launchpad.net/bugs/348225
<mvo> pitti: I can do that, let me check if I have anything else pending
<pitti> mvo: I'm already test building, so if you don't have anything else, I'll just upload it
<pitti> mvo: I didn't see UNRELEASED stuff in bzr
<mvo> pitti: ok, I have a pending bug but no fix yet (and it might be a problem with apt-xapina-index) so just go ahead
<pitti> mvo: ok, thanks
<slangasek> pitti, ArneGoetje: how is language pack generation meant to handle non-ascii characters in description fields? :)
<slangasek> e.g., language-pack-oc, language-pack-nb
<bluszcz> hi, where I can read about ttf packaging policy?
<pitti> slangasek: -nb works just fine? (BokmÃ¥l)
<pitti> slangasek: oh, ugh
<bluszcz> for debian there is: http://www.debian.org/doc/debian-policy/ch-customized-programs.html#s11.8.5
<bluszcz> and for ubuntu is the same?
<pitti> slangasek: the (post 1500) is part of the description (year)
<slangasek> bluszcz: the same policy applies, yes
<slangasek> pitti: yes, but it's supposed to say "ProvenÃ§al", not "Proven" :)
<bluszcz> great
<pitti> slangasek: WFM..
<bluszcz> there is no word about TTF fonts
<pitti> slangasek: where are you looking at this? perhaps a system without locales, such as the DC?
<bluszcz> only speedo etc
<slangasek> pitti: ah, yes, was testing in a chroot without locales
<slangasek> pitti: looks fine in a real system; ok, I'll do the same thing in gnome-user-docs
<slangasek> bluszcz: correct; that section of policy talks about "packages providing fonts for the X Window System", which is not the case for truetype font packages in general - it refers to a more-or-less obsolete font handling method
<slangasek> bluszcz: for truetype fonts, I don't think there's any policy spelled out; the convention is to create a per-package directory under /usr/share/fonts/truetype, and use fontconfig
<pitti> seb128: ronne is back, fixing retracers now
<seb128> pitti: excellent
<kwwii> cjwatson, pitti: if you have an encrypted disk, when does it ask for your password?
<pitti> kwwii: some seconds after usplash starts
<kwwii> pitti: does it switch back to text mode or does it do it in the usplash?
<pitti> kwwii: it asks in usplash
<pitti> in the text area
<kwwii> wow, when was that implemented? nice
<kwwii> thanks for the info
<pitti> kwwii: I did that ages ago, somewhere around gutsy
<pitti> I haven't used an encrypted disk since after hardy any more, though
 * pitti hugs ecryptfs
<kwwii> cool, I'm adding that to my use cases of the new boot experience
<pitti> but we need to account for that case in plymouth, yes
 * pitti -> lunch, bbl
<slangasek> pitti: when you're back and have some time, I have a cdbs question for you
<slangasek> pitti: regarding gnome-user-docs; what I want to achieve is to install all the docs in a single tree, run fdupes over them, and then split the files up by language into separate packages, but I have no idea what cdbs targets I need to use for this
<seb128> slangasek: why not using .install for each locale?
<slangasek> seb128: will that let us run fdupes?
<seb128> slangasek: cdbs does fdupes for you
<slangasek> across packages?
<seb128> yes, it consider depends iirc
<elmo> how often should I be seeing the 'software out of date' stuff?
<elmo> I haven't gotten a notification since I upgraded to jaunty, and it's been 3 days now
<seb128> elmo: is that a dialog?
<slangasek> seb128: ok, let's see
<seb128> elmo: security updates daily, normal updates weekly
<slangasek> elmo: 7 days if there are no security updates
<slangasek> :(
<elmo> err
<elmo> that's insane
<seb128> elmo: and there is no notification icon anymore, just update-manager auto-opening
<seb128> elmo: yeah, try to convince the design team they are sitting near to you ... ;-)
<slangasek> well, unless you run 'gconftool -s --type bool /apps/update-notifier/auto_launch false'...
<elmo> seb128: yeah, I'll speak to them about it; though I suspect I'll be redirected upwards
<directhex> gah @ preinst woe
<hyperair> i really don't see the point of the update-notifier change in behaviour if everyone's going to type that and disable the new behaviour
<seb128> the assumption is that only geeks will do that
<directhex> hyperair, change is exciting!
<seb128> and that normal users don't want to be pressured daily about non urgent updates
<elmo> can't we increase the frequency during beta at least?
<hyperair> seb128: keyword is assumption.
<slangasek> except we don't actually have non-security SRUs happening on a daily basis...
<seb128> well you can't know before trying
<hyperair> seb128: i don't know how many times i'm gonig to have to explain this stupid behaviour to new converts
<seb128> so it can only be assumptions
<slangasek> and people who are running the devel release ought to be getting the latest fixes
<seb128> slangasek: right unstable series are a different case and we could tweak settings there
<seb128> the design team focussed on experience for normal users on stable
<slangasek> seb128: except it's not a different case, because as I said, we don't have non-security SRUs happening daily
<seb128> well for sure you have updates less often
<seb128> for the record I don't like the change
<slangasek> I really don't think waiting 7 days before they're offered for installation makes sense
<amitk> less often but much bigger updates
<slangasek> and "you can't know before trying" --> "trial and error", yuck
<seb128> I don't think they care much about the number of days
<directhex> bah, for some god-unknown reason, i have a preinst that isn't running when it should be
<mvo> elmo: there is the /apps/update-notifier/auto_launch to get the old behaviour back
<seb128> what they have been wanting to change is the icon to auto-opening
<mvo> elmo: gconf key I should add
<seb128> and the delay is reaction to users complaining about the thing opening too often
<seb128> mvo: <slangasek> well, unless you run 'gconftool -s --type bool /apps/update-notifier/auto_launch false'...
<seb128> mvo: already mentioned ;-)
<mvo> heh :)
 * mvo is too slow
<slangasek> seb128: what's the best cdbs target to use for auto-generating my .install files?
<ebroder> slangasek: Probably install/$PACKAGE
<Keybuk> right, time to reboot into jaunty
<seb128> slangasek: what ebroder wrote
<slangasek> I'll give that a try, thanks
<Keybuk> ok, that's weird
<Keybuk> ^C has stopped working
<elmo> seb128: do I need to talk to the DX team about dropping the 'days between notification' stuff for beta too?
<seb128> elmo: I'm not sure to understand the question, is beta a special case there in your opinion?
<elmo> seb128: sure, because there are no security updates
<elmo> seb128: firefox 3.0.8 went into jaunty proper
<slangasek> seb128, ebroder: 'install/gnome-user-guide-%::', is that not what I want?
<seb128> elmo: well then you mean unstable cycle
<elmo> so I wasn't notified about it
<seb128> elmo: beta is just a special case in the unstable cycle
<elmo> seb128: sure, I guess so
<ebroder> slangasek: Uh...I think that would run once for each gnome-user-guide-foo package
<seb128> elmo: right ;-)
<ebroder> slangasek: That may be what you want - use $@ to your advantage :)
<slangasek> ebroder: which is what I'm trying to achieve; but it doesn't run at all
<slangasek> AFAICS, it's only running the stock cdbs rule
<seb128> slangasek: "stock"?
<slangasek> seb128: if I call 'fakeroot ./debian/rules install/gnome-user-guide-da', I see 'dh_installdirs -pgnome-user-guide-da' printed but I don't see the output from the rule I've added in debian/rules
<seb128> what if you debian/rules install?
<slangasek> install-indep, you mean?
<seb128> right
<slangasek> checking
<slangasek> yeah, same thing
<seb128> otherwise you might want to try "binary-install/binary::"
<slangasek> (and calling binary-indep didn't do it, so...)
<slangasek> seb128: generating all the .install files in a single pass, then?
<seb128> binary being your actual binary package name
<slangasek> oh
<slangasek> but I don't want to encode that list of binaries anywhere in debian/rules
<slangasek> since it changes whenever upstream adds a translation
<seb128> well binary-install/binary-%:: then
<slangasek> still no
<seb128> otherwise I guess just use "pre-build::" to generate all the .install
<seb128> you are sure that's run once before build
<seb128> if you have the list in the LINGUAS or similar
<seb128> ie if you know the list before building
 * slangasek nods
<slangasek> find gnome2-*-guide/ -maxdepth 1 -type d ;)
<ebroder> Blargh. What do I do with a bug that's fixed in Jaunty but I want to reopen for an SRU? Should I just mark it as confirmed and let someone who actually has the right bits juggle the state between Jaunty and Intrepid?
<slangasek> ebroder: target it to the release if you can; if not, subscribe ubuntu-sru
<ebroder> slangasek: Who can target bugs? motu?
<ebroder> (It's a universe package)
<slangasek> ebroder: motu should be able to, yes.
<ebroder> Ok. But if I can't, I just leave the bug closed?
<slangasek> ebroder: hmm, I guess in that case you'll need to reopen it after all to get any attention on it
<pitti> slangasek: I'd just use dh_install, but you can also create a programmatic install rule in install/<pkgname>:: or common-install-indep::
<ebroder> slangasek: Ok, cool, that's kind of what I was thinking
<\sh> asac: what magic curse do I have to use to have flash/flex back in ff on jaunty 64bit? ;)
<slangasek> pitti: well, even if I use dh_install, it's going to be programmatic <shrug>
<slangasek> pitti: anyway, pattern substitutions seem to be failing me for whatever reason :(
<asac> \sh: sudo apt-get install --reinstall flashplugin-nonfree ?
<\sh> asac: let's see :)
<asac> let me know.
<\sh> asac: you don't want to see that error message
<slangasek> hah, and then the rule fails anyway because there's an upstream translation that's not in LINGUAS
<slangasek> thbbt
<lool> cjwatson: hey, not sure we have doko this week; I have a couple of issues with the ubuntu-toolchain glibc branch
<\sh> asac: http://paste.ubuntu.com/140692/
<lool> cjwatson: One is that my branch is still up for merging
<\sh> asac: and it was installed and license was approved and worked in intrepid
<lool> https://code.launchpad.net/~ubuntu-toolchain/ubuntu-toolchain/glibc-2.5-package/+merges
<ebroder> \sh: dpkg-reconfigure flashplugin-nonfree?
<pitti> slangasek: what are you trying to substitute?
<lool> cjwatson: the other is that there's again a diff between what's in the archive and what's in the branch; e.g. in ./control.in/libc6.1 and other control files, the description was changed
<\sh> ebroder: the same...it looks in the wrong location of the file...
<slangasek> pitti: creating a common rule for install/gnome-user-guide-*:: or whatever
<lool> cjwatson: http://paste.ubuntu.com/140693/ etc.
<slangasek> eh, s/*/%/
<\sh> grmpf
<\sh> after removing the location of the tar.gz of flash it downloads it again..but no change in behaviour...ff is dimming itself..when browsing to a flash site..
<asac> \sh: which flash site are you looking at?
<\sh> asac: .xsession-errors: http://paste.ubuntu.com/140696/
<\sh> asac: golem.de
<ebroder> \sh: I'm making this up, but try `echo "flashplugin-nofree flashplugin-nonfree/httpget bool true" | debconf-set-selections`?
<\sh> asac: but s/golem\.de/<any site with flash content>/
<pitti> slangasek: $(patsubst %,install/%,$(DEB_INDEP_PACKAGES)):: doesn't work?
<pitti> slangasek: but I guess if you jump through those hoops, using common-install-indep:: is easier
<slangasek> pitti: I hadn't tried that; why does it have to be written that way?
<asac> \sh: please check if you have some dangling symlinks in /usr/lib/mozilla/plugins/ or something
<pitti> slangasek: well, how did you write it?
<slangasek> pitti: exactly as I said
<pitti> slangasek: I just stole that from buildcore.mk
<slangasek> install/gnome-user-guide-%::
<pitti> oh
<pitti> slangasek: I'm not sure that % has a special meaning in make outside of $() substitution functinos
<\sh> asac: http://paste.ubuntu.com/140698/ if this looks ok to you...no dangeling symlinks (only libtotem)
<pitti> I'm not enough of a make guru for this, I'm afraid
<slangasek> pitti: oh, I'm quite certain it does have a special meaning, but its meaning appears to be incompatible with whatever cdbs does :)
<asac> \sh: where does the alternative point to?
<\sh> asac: shermann@wz-pc-010:~$ ls -al /etc/alternatives/mozilla-flashplugin
<\sh> lrwxrwxrwx 1 root root 56 2009-03-30 14:23 /etc/alternatives/mozilla-flashplugin -> /var/lib/flashplugin-nonfree/npwrapper.libflashplayer.so
<asac> \sh: also check xulrunner-addons/plugins
<asac> and firefox-addons/plugins ;)
 * slangasek adds this to "reasons cdbs is too clever for my own good"
<lool> slangasek: What's your diff / .dsc?
<cjwatson> lool: ok, I'll look at it and sort it out
<pitti> slangasek: cdbs by and large creates automatic dependencies to install/<packagename> targets, for all available packages in debian/control
<lool> slangasek: Happy to take a look
<lool> cjwatson: Thanks; then I'll poke you for merging of the neon stuff
<slangasek> lool: don't worry about it; I'm still mid-composition anyway
<slangasek> not worth the trouble to post it somewhere :)
<\sh> asac: xulrunner-addons looks like mozilla/plugins , firefox-addons is empty (the plugin)
<pitti> slangasek: it doesn't extend make in a way to match install/% for any install/foo
<lool> slangasek: I have a decent toolbox of CDBS hackery in my pkg-gnome checkout; happy to have a look  ;)
<slangasek> pitti: matching install/% isn't an extension though, it's standard target pattern matching :(
<\sh> asac: bbl...
<\sh> asac: more infos: it's just a dist-upgrade from intrepid
<pitti> slangasek: hm; as I said, I don't know enough about make for this; I only ever used it with functions, and even that very rarely
<cjwatson> lool: I wouldn't worry too much about the control desync, it's not that important
<PecisDarbs> Someone willing to play with https://bugs.edge.launchpad.net/hardy-backports/+bug/267305?
<ubottu> Ubuntu bug 267305 in hardy-backports "Please backport django 1.0" [Undecided,New]
<PecisDarbs> 1.0 is very nice and stable release of django and it would rock to have it in hardy
<slangasek> lool: lp:~vorlon/gnome-user-docs/ubuntu-jaunty, if you're particularly interested. :)  (works now)
<slangasek> mdke: hrm, why is gnome-user-docs a native package?
<slangasek> does upstream not release tarballs?
<slangasek> pitti: do you want to review this package split at all before I upload it, or otherwise coordinate wrt langpacks?
<pitti> slangasek: I'm happy to take a look, but if it works for you, go ahead :)
<pitti> slangasek: once it's through new, I'll add the language-support-* dependencies
<slangasek> ok, cool
<pitti> slangasek: /me takes a look at the commit
<pitti> slangasek: looks good to me, great work!
<slangasek> thanks :)
<slangasek> pitti: I guess this split saves us about 5MB on the alternate CDs, and $mumble on the desktop CDs
<pitti> \o/
<\sh> back
<\sh> asac: any clue on that behaviour?
<slangasek> pitti: ok, gnome-user-guide is out of NEW
<asac> \sh: no. you could post a strace -f of firefox
<asac> i suspect some bad links somewhere
<\sh> asac: my pleasure...
<\sh> asac: hmm...strace {firefox,firefox-3.0.8,/usr/lib/firefox-3.0.8/firefox} segfaults...but ff runs..grmpf..
<asac> \sh: odd. sure you have all firefox properly killed before doing it?
<\sh> asac: whatever I do...(even strace -p) the process with strace coredumps but is still running
<asac> hmm
<\sh> asac: yepp..checked twice..no trace of firefox..
<\sh> asac: firefox started from cli...strace -p <ff pid> -> telling ff to http to whereever -> coredump
<\sh> *** glibc detected *** strace: malloc(): memory corruption (fast): 0x000000000225f610 ***
<\sh> select(Aborted (core dumped)
<asac> so strace is broken?
<cjwatson> Riddell: could somebody who knows about qt layout fix bug 344382? it isn't obvious to me how to do so, since the relevant QLabel does have wordWrap set to true, so I think it must be something more subtle
<ubottu> Launchpad bug 344382 in ubiquity "Jaunty: Kubuntu ubiquity password page is 2/3's bigger than the others" [Undecided,New] https://launchpad.net/bugs/344382
<\sh> asac: good question...regarding the fact, that ff is still running, I would say yes, but I'm in no position to really say so...others will have a much better insight in strace ;
<cjwatson> Riddell: ... actually, never mind, I think it's been fixed since the bug was reported, 'bzr cat -rtag:1.11.14' shows wordWrap set to false
<slangasek> if strace core dumps, that's an strace bug, sure
<cjwatson> heh, indeed you fixed it yourself
<asac> \sh: maybe downgrading strace ...
<asac> \sh: seems so
<asac> i guess we should file a relese bug on that
<asac> broken strace is a blocker imo
<\sh> asac: much better: fix bug #316762 on strace
<ubottu> Launchpad bug 316762 in strace "strace crashed with SIGABRT in malloc()" [Undecided,New] https://launchpad.net/bugs/316762
<asac> is that the bug?
<asac> yeah seems so
<\sh> asac: yepp filed in january...and the attached logfile looks the very same to my output
<asac> maybe its our direct.h patch?
<asac> https://edge.launchpad.net/ubuntu/jaunty/+source/strace/4.5.17+cvs080723-2ubuntu1
<\sh> asac: you mean the missing linux/dirent.h patch from pitti?
<asac> \sh: not sure. just stabbing ni the dark. most likely its just because we have a cvs snapshot now ;)
<pitti> slangasek: I'll add them in an hour, when they get published
<\sh> asac: anyways...I can reproduce that on two machines, which had the very same upgrade path...so I'll check this evening on the other machine
<kirkland> pitti: right
<slangasek> pitti: cheers :)
<pitti> kirkland: ECONTEXT?
<kirkland> pitti: cjwatson agreed with you, i think the last package i uploaded should do what you want, and meet cjwatson's code critiques
<pitti> kirkland: ah, thanks
<kirkland> pitti: just woke up, reading scrollback, you highlighted me :-)
<kirkland> pitti: re: deluser
<tkamppeter> pitti, can you approve the -proposed package for bug 351630? I have already uploaded it and it waits for approval. Thanks.
<ubottu> Launchpad bug 351630 in foo2zjs "[Intrepid] foo2zjs does not print with custom paper sizes" [Undecided,New] https://launchpad.net/bugs/351630
<pitti> tkamppeter: on my next SRU run, will do
<tkamppeter> pitti, thanks.
<seb128> pitti, slangasek: ok, I've a gnome-python-desktop split of gtksourceview and gnomeprint ready to be uploaded (we have to split gtksourceview too because it depends on gnomeprint), it wins 2.3megas on installed size
<seb128> pitti, slangasek: libgnomeprint, libgnomeprintui, libgtksourceview would be out of the CD but still in main due to build-depends still being there
<seb128> pitti, slangasek: not sure if that's worth for jaunty ...
<slangasek> I don't know
<slangasek> 2.3MB installed; but hard to know how much on the livefs
<slangasek> seb128: if you think it's worthwhile, go ahead
<slangasek> could you also drop the bug-buddy build-dep at the same time?
<seb128> slangasek: that would mean stopping building the bug-buggy binding
<slangasek> yeah
<seb128> do we really want to do that?
<slangasek> is there really any reason we shouldn't?
<seb128> some gnome applications import it
<slangasek> if you think it needs to stay, then I'll hack up a patch to build it without the bug-buddy build-dep
<slangasek> ok
<seb128> I need to check how it behaves if not installed
<hyperair> pitti: could you take a look at the nautilus-share merge request? i accidentally diff'd against the wrong thing in my previous patch upload
<slangasek> let's just go the safe route, I'll fix the configure script to build the binding even if bug-buddy's not installed
<seb128> slangasek: ok, so I would say the CD space win is not worth the python bindings split
<slangasek> ok
<seb128> not sure about moving those 3 deprecated libs out of the CD though
<seb128> would it mean we stop supporting those officially
<seb128> which would be a win ...
<seb128> though in practice they are not so much maintainship work
<pitti> hyperair: looks fine now; seb128, you commented on the nautilus-share merge, do you want to do that yourself, or shall I take it?
<hyperair> pitti: thanks
<seb128> pitti: please do it
<apw> pitti, hey ... why does apport refuse to file bugs when i have out of date packages?
<seb128> pitti: I just commented because the bug wrongly requested a sync
<seb128> and I didn't want somebody to ack the sync too quickly
<apw> i only have out of date packages cause you lot are rebuilding everything
<apw> thats just daft
<pitti> apw: well, but for that very reason we also get a lot of broken stack traces :/
<pitti> apw: it was an "emergency brake" for getting even more crash reports
<apw> then its completely rediculous to do a beta release at the same time, no?
<seb128> pitti: any opinion on python-gnome-desktop gnomeprint, etc?
<apw> as noone who tests it (like me) can report any bugs, an indeed should expect instability
<pitti> apw: also, it doesn't check for "any outdated package", just for "any outdated package in the crashed program's depenency chain"
<apw> so its not a good time for a beta either
<apw> right but you are rebuilding the world on me
<slangasek> "the world"?
<apw> oh an not popping up the update-manager for 5 days
<apw> so i am bound to have out of date packages if i follow normal user experience
<pitti> seb128: no strong one; if you want to do the work, go ahead, but I don't think it's urgent
<apw> i thought we rebuilt everything 'now'
<seb128> pitti: well as said before I've it read for upload if we want it
<pitti> seb128: I see no reason not to upload it if you did it already and it works
<seb128> pitti: that doesn't win us a lot and we still have to keep the lib in main due to build-depends
<apw> my real point is are we not just wasting tester cycles by conenciding these two things?
<pitti> apw: I don't think so
<slangasek> apw: we do test rebuilds; we don't rebuild the packages in the archive except to fix bugs
<pitti> apw: we rebuilt perhaps 50 packages since beta, but we have some 25.000 in teh archive
<seb128> pitti: well, that could break third party softwares around which still use gnomeprint or gtksourceview1 and would need to update their depends
<apw> oh hrm
<apw> pitti, i have 193 updates pending since beta
<pitti> apw: I'm aware that being able to report crash bugs involves daily dist-upgrades
<apw> pitti, you are but even i am not
<pitti> apw: but ATM I don't really see how else to do it
<pitti> seb128: oh, I see
<seb128> apw: you suggest that we stop fixing bugs so you can reply crashes?
<seb128> reply -> report
<slangasek> I think he's asking that apport not refuse to file crashes because of outdated packages
<apw> seb128, heh no of course not.  i think if we are fixing so little then it should be safe to accept crashes
<pitti> seb128: I thought you split out a gnome-python-desktop-main or so, with gnome-pyhton-desktop pulling in -main and -extra
<apw> it makes apport useless it feels to me
<seb128> pitti: hum, could do that
<apw> anyhow i'll go hit update and see if indicator-applet poops self again
<seb128> apw: export APPORT_IGNORE_OBSOLETE_PACKAGES
<apw> seb128, thanks
<cjwatson> apw: we don't typically expect people to install beta and then sit with it until we do the final release - we expect people to install it and then upgrade reasonably frequently to final
<seb128> you're welcome
<pitti> apw: ^ right, but pretty please don't report crashes against packages which were updated recently
<pitti> apw: using that is okay if the oboslete package is deep down the dependency chain
<apw> cjwatson, yeah i know, but the new update-manager works against that as i don't get told
<seb128> apw: there is a reason why that is not set by default, if apport tell you that versions changed the retracing with probably fail and not be useful
<apw> pitti, s'ok i won't do it...
<apw> i am tryng to behave like a real user and report my experience to you
<apw> i don't want to deviate from th
<pitti> apw: thinking about it, we now auto-invalidate bugs with failed stack traces and obsolete dependencies, so reporting those probably don't hurt so much as it used to
<apw> that.  but i can tell you  i was pretty annoyed whern it asked me to report, it muched for 2 mins and then told me to bugger off
<cjwatson> (real users don't report bugs to #ubuntu-devel, mind you ;-) )
<apw> and then didn't even wake up update-manager to get me updated
<seb128> apw: that's one of the trade off of running an unstable distribution
<apw> just re-rand the bust ones
<pitti> apw: I don't particularly like the u-m silence for an entire week either; it's appropriate for stable, but not for a devel release
<apw> seb128, yep ... i am fully aware
<sladen> pdate-manager has been reported "Partial upgrade possible only" for the last couple of months.  SHould I care?
<apw> i am completly capable of coping and not whining.  the purpose of my whine is to try and see what appears like my girlfriend would and behave the way she would
<slangasek> mumble shouldn't be needed for stable releases either if our SRUs are reasonable
<apw> and she would have come and shouted at me
<seb128> apw: she souldn't be using an unstable distro ;-) apport is not running by default on stable
<sladen> that APPORT_IGNORE_OBSOLETE_PACKAGES should really check if it's one of the involved packages that actually crashed
<apw> yes she should, she was told it was really shiney and there was cute popups, how could she resist
<seb128> apport does check only rdepends
<pitti> slangasek: that's what it does if you *don't* specify it
<pitti> erm, sladen, I mean ^
<pitti> sladen: well, it checks the crashed package and its transitive dependencies
<sladen> pitti: oh.  maybe it's libc or something.  I haven't had apport non-whinge (eg. succeed) for 3 weeks now
<sladen> pitti: perhaps it needs an override button "report anyway" ... which given that it's only shown to development-release users would be useful
<pitti> sladen: I'm not so sure about that
<seb128> everybody would click it
<pitti> sladen: it's not that we need to find ways to get even more bug reports
<pitti> we have plenty
<seb128> that would defeat the purpose of the check
<apw> pitti, it would be nice if it at least told me what was out of date
<slangasek> doesn't it?
<apw> so i could make a judgement about updating
<seb128> apw: it does
<pitti> and reports about older versions aren't very useful
<slangasek> it always did before
<pitti> it should
<seb128> it lists everything outdated in a dialog there
<sladen> IIRC, it just says "some packages are out of date"
<sladen> oh
<seb128> and list those
<apw> seb128, i think i would have noticed.  it said you have out of date packages only
<seb128> apw: are you sure you don't have a dialog unfocussed somewhere?
<seb128> apw: that seems a bug then, open an apport bug on launchpad
<apw> not that ic an see
<apw> why would it not be in the dalog which told me it was out of date
<pitti>             report['UnreportableReason'] = _('You have some obsolete package \
<pitti> versions installed. Please upgrade the following packages and check if the \
<pitti> problem still occurs:\n\n%s') % ', '.join(old_pkgs)
<pitti> and if old_pkgs is empty, it isn't shown at all
 * sladen does a killall -SEGV evince  ... okay so that did tell me packages
<pitti> so that indeed sounds like a curious bug
<apw> pitti, well i must be blind then as that looks impossible
<seb128> apw: http://people.ubuntu.com/~seb128/apport.png
<seb128> apw: that's what I get there
<pitti> apw: it could very well be a bug somewhere
<apw> yeah i must have been too angry to read the second sentence
<apw> as i deffo had the top
<apw> dlinded by rage :)
<apw> sorry for the noise.  /me crawls back under his rock
<pitti> apw: no need to apologize; it's a valid concern, I just don't know how to make it better without increasing the bug tracker noise a lot
<pitti> I guess the u-m silence contributes a lot to this
<apw> pitti, would apport complaint about the things in apport as well as the thing you were using?
<apw> pitti, i was very happy to find a way to get the little icon back
<seb128> pitti: maybe add a "upgrade now" button to the apport dialog ;-)
<pitti> apw: can you reformulate this, please?
<sladen> on a related topic, would there be a good way to show users why their CPU has gone to 100% but firefo hasn't actually yet disappeared
<sladen> (during the collection process)
<seb128> compiz change the color of the dialog when not responding
<seb128> do you find that a good visual clue?
<apw> pitti, i was wondering if apport would whine about say python because apport uses it when reporting ... does it include its own deps
<pitti> apw: only if you'd report a crash of apport itself
<pitti> apw: if you report a crash in, say, libgtk, an outdated python doesn't matter at all
<apw> i am hearing reports of python being reported as out of date for a kernel panic, but i've not seen it myself
<slangasek> sladen: anything that would permit the crash handler to trace down the process's X windows and display something friendly would surely be comparably sluggish?
 * slangasek attacks the OOo java build-dep tree with a chainsaw
<sladen> slangasek: I was thinking about something more general such as changing the cursor to an hour glass Gtk-wide when CPU level >= 90%  (Mac / RiscOS had that for years and whislt it might be annoying, it at least show that the computer is *aware* that it is being slow)
<sladen> ...the animation helping to convince the user that it hasn't actually crashed
<directhex> slangasek, you're not trying to build OOo are you? with your bare hands?
<directhex> sladen, the windows 95 busyish cursor!
<slangasek> not at all; I'm using slave laborers to build it
<sladen> seb128: just tried that a few times.  The window vanishes before it gets a chance to turn grey  (which took ~10-15 secodns)
<seb128> ok
<directhex> slangasek, slaves plural? calc is but one man!
<sladen> seb128: so it's   15 seconds hang with 100% CPU.  "Gah damnit $#%@#$ where did my work go".  15 seconds more 100% CPU.  Pause.  Apport notification.  Click, report.  5 seconds CPU.  "Could not be reported"  blood boiling
<seb128> that's one of the reason why we don't enable it on stable ;-)
<sladen> :)
<sladen> perhaps, apport could fire up a pulsing status icon in the top menu "collecting crash information".  Then this could change to solid when the report is ready
<pitti> bryce: can you upload bug 320893 today/soon? If you are swamped, I can do it tomorrow morning
<ubottu> Launchpad bug 320893 in xserver-xorg-video-intel "[i915GM] Regression in xserver-xorg-video-intel version 2.4.1-1ubuntu10.3" [Critical,In progress] https://launchpad.net/bugs/320893
<Tm_T> hi kids
<pitti> slangasek: did you see the updated script in bug 295441? I don't think we need to mess with it further in SRUs, but it might be worthwhile for jaunty; WDYT?
<ubottu> Launchpad bug 295441 in pam "pam-auth-update does not correctly process a valid profile file" [Medium,Fix committed] https://launchpad.net/bugs/295441
<slangasek> pitti: I saw, but since he attached a script instead of a diff I haven't had a chance to look into it yet
<slangasek> pitti: I doubt it has any other changes that need to be applied to jaunty, though; I think I probably just missed a related change when cherry-picking for the SRU
<Tm_T> I failed to find any related bug for this, so I wonder if there's been any other victims of 64bit(only?) gcc/g++ segfaults: internal compiler error: Segmentation fault
<Tm_T> keep hitting on that in Jaunty now all the time
<cjwatson> Tm_T: try with lower optimisation settings to start with
<cjwatson> Tm_T: /usr/share/doc/gcc-4.3/README.Bugs
<pitti> jdstrand: I'm a bit confused about bug 305264; ubuntu-sru is subscribed, it is apparently in -proposed and v-needed, but the SRU team never accepted it; is that a kind of "security update staging" procedure:
<ubottu> Launchpad bug 305264 in openldap "gnutls regression: failure in certificate chain validation" [High,Fix committed] https://launchpad.net/bugs/305264
<pitti> jdstrand: ?
<pitti> jdstrand: is there anything the SRU team needs to do for those?
<Tm_T> cjwatson: hmm, will try, thanks, apparently there's several bug reports, just failed to find them, let's see if this gets sorted out
<cjwatson> Tm_T: don't assume your crash is the same as anyone else's
<jdstrand> pitti: it should be pushed along with the openldap SRU that is in the same report
<jdstrand> pitti: that was a bit of a twisty bug, but we are very close to being able to close it
<jdstrand> pitti: I followed up with mathiaz on it last week, and he is preparing the openldap bits and I believe has uploaded them
<jdstrand> pitti: to -proposed
<jdstrand> pitti: so to fully answer your question, nothing needs to be done until openldap is verified and ready to go to updates, at which point, both gnutls and openldap whould go
<pitti> jdstrand: I see, thanks
<alex-weej> backlight level is reset to 100% after S3 resume, but g-p-m thinks it's still whatever it was
<alex-weej> is this a general problem with bl drivers or just mbp_nvidia_bl?
<alex-weej> need to work out whether to get g-p-m to reset bl level to what it thought it was before resume or whether to fix the bl module to be consistent
<lool> cjwatson: Happy if you can review NEON hwcaps changes lp:~lool/ubuntu-toolchain/glibc-neon-and-misc-hwcaps they are building in a PPA ATM, and I'll test them tomorrow; if they work I'd like to push them tomorrow
<lool> (I'm not offering them for merging just yet because of the bzr status I mentionned earlier and because I will test them first)
<slangasek> ArneGoetje: so the deadline we give folks for langpack translations according to the schedule is the same day as RC; I know we talked about when to do the last full langpack rolling, I guess we definitely need one after RC then - should we also have one before RC, to get right sizes for the RC?
<ArneGoetje> slangasek: probably
<ArneGoetje> slangasek: that would mean this coming Friday.
<bryce> pitti: yeah I can do the upload for that
<ArneGoetje> slangasek: ah no... that would be for non-langpack translations...
<ArneGoetje> slangasek: so, Friday 10th, right?
<slangasek> ArneGoetje: RC is the 16th, so the 10th would work, yes
<ArneGoetje> slangasek: ok
<mdke> slangasek: still around?
<slangasek> mdke: barely
<mdke> slangasek: i was going to respond to your highlights about gnome-user-docs, but we can take it to email, or leave it for another day if you like
<slangasek> mdke: whichever :)
<mdke> slangasek: email then. enjoy your evening
<apw> cjwatson, did i see someone talking about some automated location selection for the registry domain?
<cjwatson> apw: YM the network-manager regulatory domain, or something else?
<apw> well the kernel CRDA one, but thats probabally the same, something to do with your locale or something floated past
<apw> i just cannot remember where i might have seen it
<cjwatson> apw: there was a proposal that the installer should set it with a modprobe option, but I bounced that over to network-manager on the grounds that having the installer do it is bad for people who might travel between regulatory domains
<cjwatson> apw: I don't know what happened to the bug after that
<apw> yeah what i saw was some script which was looking at your home location or something
<apw> but for the life of me i don't know if it was a bug, or a developer email or imaginary
<cjwatson> no idea then :)
<Tm_T> cjwatson: aye, I do not assume, I rather try to find it there is something useful for finding the root of the cayse
<Tm_T> cause
<tkamppeter> pitti, can you have a look at bug 348316?
<ubottu> Launchpad bug 348316 in cups "Printer (HWModel Name) May Not Be Connected" [Undecided,Confirmed] https://launchpad.net/bugs/348316
<tkamppeter> For many users USB printers get detected but it is not possible any more to print through the CUPS USB backend with Jaunty.
<cjwatson> lool: I checked glibc bzr; I'm not sure why the package as uploaded has old text in control.in/libc<blah>, but all the files in bzr are correct so I think that can be ignored
<tkamppeter> pitti, CUPS is the same in Intrepid and Jaunty. Only change is runloop-backchannel-eof-spin.dpatch, an upstream bug fix. I have already asked the reporter of the (probably duplicate) bug 350107 to test with the unpatched backend, but he has still the same issue.
<ubottu> Launchpad bug 350107 in cups "[Jaunty beta] Epson RX620 doesn't print" [Undecided,Incomplete] https://launchpad.net/bugs/350107
<cjwatson> lool: lp:~lool/ubuntu-toolchain/glibc-neon-and-misc-hwcaps looks fine to me if it tests out OK
<tkamppeter> pitti, can it be that the kernel causes the problem?
<pitti> tkamppeter: entirely possible; however, I think it's also worth asking for /var/log/kern.log, and trying with sudo aa-complain cups
<pitti> tkamppeter: but if the printer gets detected properly (lpinfo -v has it), then the backend should work okay, permission-wise
<bryce> pitti: I've uploaded bug 320893 -- would you mind shepherding it through the remainder of the sru process?
<ubottu> Launchpad bug 320893 in xserver-xorg-video-intel "[i915GM] Regression in xserver-xorg-video-intel version 2.4.1-1ubuntu10.3" [Critical,In progress] https://launchpad.net/bugs/320893
<pitti> tkamppeter: posted a followup
<pitti> bryce: thanks muchly; will do
<mdz> pitti: I was just looking at bug 351024 and realized it would be a good idea to include the CD build number for reports done from the live CD
<ubottu> Bug 351024 on http://launchpad.net/bugs/351024 is private
<pitti> mdz: I agree, good idea; could you please file this as a bug report?
<mdz> pitti: yes, I'll see if I can work up a patch as well
<pitti> not that trivial, since it's ubuntu specific, but that's okay for now
<pitti> I still haven't split it into trunk and ubuntu
 * pitti disappears to Taekwondo, good bye everyone
<mdz> cjwatson: any guess what's behind 351024?
<cjwatson> mdz: I looked at that, who knows, could be anything, but looks like a busted live CD
<cjwatson> mdz: we get loads of weird bugs like this on ubiquity
<cjwatson> which AFAIK are not typical but CDs suck
<mdz> cjwatson: even with no errors reported in the log?
<cjwatson> mdz: far from unknown
<cjwatson> mdz: I'll look into pygtk in more detail tomorrow and see if I can figure out anything more
<mdz> cjwatson: would it be too brutish to force an integrity check before filing the report?
<cjwatson> mdz: when I dig into this sort of problem, oftentimes it turns out that the integrity check passed
<cjwatson> mdz: it seems that different CD read patterns often show up different bugs
<mdz> cjwatson: *cry*
<cjwatson> my sentiments exactly
<cjwatson> hence "CDs suck"
<cjwatson> so the error here is that gdk_cursor_new_from_pixmap returned NULL:
<cjwatson>   g_return_val_if_fail (GDK_IS_PIXMAP (source), NULL);
<cjwatson>   g_return_val_if_fail (GDK_IS_PIXMAP (mask), NULL);
<cjwatson>   g_return_val_if_fail (fg != NULL, NULL);
<cjwatson>   g_return_val_if_fail (bg != NULL, NULL);
<cjwatson> well, either that or g_new failed
<ScottK> "You must order a CD via shipit and wait 4 - 6 weeks.  If you can reproduce the bug with that CD, then you can report it."
<ScottK> Note:  I'm not actually recommending that.
<cjwatson> so I suppose it could be that one of the pixmaps couldn't be read
<cjwatson> ScottK: ... and then you get the people who go "I got this with a pressed CD" and you panic for a bit and then it turns out that cleaning their CD drive fixes it
<mdz> cjwatson: is it time to discuss deprecating CD installations in favour of USB sticks?  they seem much more reliable
<ScottK> Yes, so not even being that annoying will do it.
<ScottK> It's actually pretty hard to find good quality CD media.
<cjwatson> mdz: maybe when we fix more of the USB installation bugs ;-) I think deprecate is too strong though; realistically I don't see people stopping using CDs any time soon
<maswan> Stop supporting anything but network installs. Ship a tiny dhcp+tftp-server. ;)
<mdz> cjwatson: "rank second in order of preference"
 * cjwatson -> dinner
<mdz> USB sticks large enough to install Ubuntu can now be had for USD 4 or less
<maswan> Also, would it be possible to have a smarter integrity check which is more like a real access pattern?
<mdz> which is still more than a CD-R, of course...
<mdz> maswan: yes.  would it help? maybe not.
<maswan> mdz: Yeah, I should get around to get one, one of these days.. Of course, once you're at the point where you already netboot a couple of computers, netbooting an installer is less work than remembering to get a stick. :)
<maswan> mdz: Not quite a general solution though..
<ebroder> I have a custom boot CD that's using the Jaunty alpha 6 kernel/initrd from the mini.iso (with custom arguments). I'm getting http://paste.ubuntu.com/140869/ when I try to boot onto a Dell 755. I know I'm in i-get-to-keep-both-pieces territory, but is this my fault, or Ubuntu's?
<ebroder> I've used the CD in a VM, where it worked fine
<pace_t_zulu> is there a way I can help with the notifications project?
<pecisk> pace_t_zulu: test with all kind of apps and report misbehaviour
<pace_t_zulu> pecisk: where can i find pidgin's code for interfacing with notifications? I believe it can be improved
<pecisk> pace_t_zulu: it sends a D-BUS message, I suppose
<pace_t_zulu> pecisk: so the code would exist in pidgin's source?
<pecisk> pace_t_zulu: it has several parts. Code for D-BUS message which causes those shiny OSD notifications to appear and code for general notification
<pace_t_zulu> pecisk: is there a guide for how to hack pidgin's source? is there a package i can install?
<pecisk> pace_t_zulu: apt-get source pidgin will get you a source and diff of Ubuntu changes
<pace_t_zulu> pecisk: thank you... apologies for my ignorance
<pecisk> np :)
<pecisk> pace_t_zulu: this Mark post on notifications will inform you about how it happens. There are several links to Ubuntu Wiki about this - read them all, they usually contain very useful info.
<pace_t_zulu> ?
<pecisk> pace_t_zulu: sorrry, forgot the link http://www.markshuttleworth.com/archives/265
<pecisk> pace_t_zulu: how to hack pidgin propably read there http://developer.pidgin.im/
<pace_t_zulu> thanks pecisk
<pecisk> np
<lool> cjwatson: (thanks for fixing and reviewing)
<natewiebe> what is the best way to compile from source, then making a deb out of it?
<natewiebe> ive tried checkinstall, but im wondering if there is a better way
<c_korn> natewiebe: dh_make
<natewiebe> does that work better than checkinstall?
<ivoks> checkinstall is dirty, but can be used for fast deb
<ivoks> those deb packages are flawed and shouldn't be used outside that single machine
<natewiebe> okay.. thanks
<ivoks> if you want to create deb package that would be usable outside, you should debianize the source
<natewiebe> they havent made a gui yet have they?
<ivoks> gui?
<ivoks> :)
<natewiebe> and i should do that using dh_make?
<natewiebe> haha
<ivoks> http://pwet.fr/man/linux/administration_systeme/dh_make
<ivoks> start here: http://www.debian.org/doc/maint-guide/
<natewiebe> awesome.. thanks
<c_korn> I have a binary here and ldd says: libtinyxml.so => not found. why didn't dh_shlibdeps make the package depend on the lib package that contains this file?
<c_korn> I used dh_makeshlibs to create the lib package
<LordKow> c_korn, i think gencontrol does that.
<LordKow> maybe im wrong
<c_korn> dpkg-gencontrol: warning: unknown substitution variable ${misc:Depends}
<c_korn> this is the all output of gencontrol
<c_korn> no word about a missing dependecy
<LordKow> and you can ignore those gencontrol warnings about misc:Depends... im pretty sure.
<c_korn> yes, well I will just add the dependecy manually
<c_korn> but it is odd anyway
<LordKow> well yea i take back that first part you said... dh_shlibdeps *should* be adding that dep but sometimes you just have to add it manually.
<LordKow> first part i said that is. i dont think i can take back what you said ;)
<c_korn> LordKow: yeah, thanks.
<jtisme> can anyone tell me the name of the installer file containing the  db_get db_go etc. shell functions
<NCommander> cjwatson, is it possible we could get Kubuntu/Xubuntu CDs for ports (or at least PowerPC) this cycle? I realize that space on antimony might be at a premium, so if its not possible, could jidgo files be generated so users can assemble their own CDs?
<cjwatson> mdz: sorry, I was in a rush for dinner earlier and didn't really mean to be dismissive of that bug. I will look at it properly (since Evan's on holiday); it didn't show up in my tests with today's daily build, but I suppose it could be that the icon ubiquity is asking for only exists on some images
<cjwatson> jtisme: it's not specifically an installer file: /usr/share/debconf/confmodule
<jtisme> cjwatson, thanks
<cjwatson> NCommander: cdimage has been trying to build them for ages. If they aren't appearing, then it's because they're failing, not because they're not being tried
<NCommander> cjwatson, it seems I'm an idiot (I didn't see the ports CD where it was, although I'm confused on why Kubuntu has a full set of CDs, and Xubuntu just got ARM and PowerPC, but this I shall figure out)
<mdz> cjwatson: no worries, I'm just scanning over http://qa.ubuntu.com/reports/bugnumbers/bugs-since-2009-03-26.html for anything which looks actionable
<cjwatson> mdz: ah, I was wondering where it came from; couldn't imagine you were looking over all ubiquity bugs ...
<mdz> cjwatson: it caught my eye originally because I didn't notice 'beta' in the summary, and figured it could be a regression in the dailies
<cjwatson> I did a sweep through newish ubiquity bugs today, since we needed an upload
<Ng> am I reading pm-utils scripts right, and the existence of /var/run/pm-utils/pm-suspend/storage/inhibit prevents suspending?
<james_w> Ng: looks like it to me
<Ng> james_w: that was my reading too. I just removed it, ran pm-suspend again and it came back. Time to do more reading :)
<james_w> Ng: /usr/lib/pm-utils/pm-functions:		# if the hook exited with an unknown exit code inhibit,
<james_w> /usr/lib/pm-utils/pm-functions:		hook_exit_status $? && LAST_HOOK="$base" || inhibit
<Ng> yeah
<Ng> bam, one culprit found
<Ng> + /etc/pm/sleep.d/07-stop-play.sh suspend suspend
<Ng> kill: 4: Usage: kill [-s sigspec | -signum | -sigspec] [pid | job]... or
<Ng> so the question is whether or not it's reasonable to only call kill if there actually is an argument, or if there should always be an argument. the ps is returning no matches here
<james_w> Ng: why not use something like pkill?
<Ng> james_w: that script is from a third party package, so I'll move along now
<james_w> ah, well if you will insist on modifying an install of Ubuntu then of course you will find bugs :-)
 * Ng wonders if there should be a notification of what caused the suspend process to fail
<lamont> *qa.ubuntu.com going offline for a few minutes for maintenance.
<lamont> and *qa.ubuntu.com is back online
 * cjwatson hates it when people lie in bug reports (as proven by the logs they attach)
<ScottK> If you're going to lie, at least be smart about it?
<pwnguin> at least they were kind enough to attach logs
<cody-somerville> People do that?
<bryce> cjwatson: my favorite lie:  "I have the same issue."
<bryce> usually followed by, "Well, except that..."
<ScottK> My favorite one is "I wasn't watching pron"
<slangasek> jpds: why are you proposing to add these apparmor profiles into the apparmor package, instead of into the package providing the binary?
<jdstrand> slangasek: cause I told him too
<jdstrand> :)
<slangasek> oh?
<slangasek> ok, why are *you* doing that then? :)
<jpds> slangasek: Sorry, does it email everyone? Didn't know that.
<jpds> slangasek: And what Jamie said. :)
<jdstrand> slangasek: it is because they aren't ready yet. profiles-devel is simply a collecting area for in progress profiles, not ready for mass consumption
<slangasek> it does, which is a known annoyance that I don't hold against you :), I'm just puzzled by where they're going
<slangasek> ah, I see
<jpds> Sorry about the spam folks.
<jdstrand> actually, it is a good thing
<jdstrand> that way people will know when new profiles are being developed
<slangasek> no, it's not a good thing. :)
<jdstrand> I acknowledge the spam factor, but if you look at it with the right pair of glasses, it is good :)
<jdstrand> slangasek: I happen to own two pair. I can loan you one if you like :P
<slangasek> heh
<calc> this is probably a dumb question, why doesn't ssh to another box with my public/private key log me in without asking for my password?
<wgrant> calc: Is it in .authorized_keys on the remote box?
<wgrant> Have id_[rd]sa.pub isn't enough.
<wgrant> s/Have/Having/
<calc> wgrant: ah ok
<wgrant> ~/.ssh/authorized_keys, I of course mean.
<calc> that fixed it :)
<Ampelbein> calc: you can use seahorse to setup your key automagically.
<Ampelbein> calc: rightmouse-click on they -> "configure key for secure shell" (just in case you need it again)
<mrooney> when do the karmic archives open?
<jpds> mrooney: After 30/04: https://wiki.ubuntu.com/KarmicReleaseSchedule
<mrooney> jpds: thanks! I was just thinking about you as I look for Barcelona flights
<mrooney> I knew the flight was rough but, I didn't realize I leave on friday and get in on sunday :)
<jpds> Hehe.
<mdke> seb128: testing your theory on bug 264314 now, if it works I'll do a debdiff
<ubottu> Launchpad bug 264314 in brasero "Brasero documentation does not appear in Yelp search results" [Medium,Confirmed] https://launchpad.net/bugs/264314
<seb128> mdke: thanks
<seb128> mdke: I think it's just that the directory has not been listed in any .install when the package has been splited for the new library
<seb128> mdke: just dh_install --list-missing after the build to see what is not installed
<mdke> seb128: ok, thanks
<mdke> seb128: I see that the bzr branch only has the debian directory, is there an easy way to get the source with it, or can I just use "apt-get source" for everything?
<seb128> mdke: bzr-buildpackage
<seb128> mdke: it does get the tarball etc for you and start the build
 * mdke installs
<seb128> mdke: https://wiki.ubuntu.com/DesktopTeam/Bzr
 * mdke reads
<seb128> mdke: if you are interested in a not to complicate description of how to use bzr for desktop packaging
<mdke> seb128: I am, thanks
#ubuntu-devel 2009-03-31
<Ampelbein> hi. i get a FTBFS for xserver-xorg-input-aiptek, buildlog: http://www.warperbbs.de/melting/readfile.php?file=andreas/xserver-xorg-input-aiptek_1.1.1-1build2_i386.build.gz , error: http://paste.ubuntu.com/141051/
<TheMuso> Ampelbein: at a glance, you are missing a build dependency of some sort.
<TheMuso> Ampelbein: apt-file could help you track down the file you want, and the package its in.
<Ampelbein> TheMuso: just seen: http://launchpadlibrarian.net/24381721/buildlog_ubuntu-jaunty-i386.xserver-xorg-input-aiptek_1%3A1.1.1-1build2_FAILEDTOBUILD.txt.gz thats the official build
<Ampelbein> should i open a bug for this?
<TheMuso> Ampelbein: not sure yet, let me think...
<TheMuso> Ampelbein: I think a bug is only needed if you have a diff to fix it, but others may think differently.
<Ampelbein> TheMuso: i also think that's why those packages are not installable anymore. we changed xserver-xorg version and the old, compiled packages, conflict with those versions.
<TheMuso> right
<Ampelbein> see bug #351076
<ubottu> Launchpad bug 351076 in xserver-xorg-input-void "Package xserver-xorg-input-aiptek does not install (Januty beta)" [Undecided,New] https://launchpad.net/bugs/351076
<Ampelbein> TheMuso: i'll be looking for the file and provide a diff
<bryce> Ampelbein: thanks
<bryce> Ampelbein: this bug was discussed on ubuntu-x@ earlier today.
<Ampelbein> bryce: oh, sorry. didn't see that
<Ampelbein> just joined half an hour ago
<bryce> <tjaalton> sbeattie: there are a few input drivers that won't build against xserver 1.6. on my list of things to fix..
<bryce> sorry, s/ubuntu-x@/#ubuntu-x/
<LaserJock> kees: around?
<kees> LaserJock: in and out, trying to get a ppc machine booted
<Ampelbein> bryce: i think i found the issue, at least for the aiptek-driver, must look for the other drivers too.
<bryce> Ampelbein: excellent
<Ampelbein> it seems that since ABI-Version 3 some function calls became obsolete
<Ampelbein> and of course the filename changed from xf86Version.h to xorgVersion.h
<Ampelbein> i will attach a patch for someone experienced to review though
<Ampelbein> bryce: can you give me some assistance? got the following warning from dpkg-shlibdeps :http://paste.ubuntu.com/141095/
<Ampelbein> shouldn't shlibdeps check the "depends" and get the symbols from the libraries needed?
<bryce> not sure
<bryce> but Xfree, Xrealloc, xf86Msg, etc. are all extraordinarily standard calls that haven't moved or anything
<bryce> Ampelbein: you might compare how linking is done in this driver with a working driver.  maybe it's doing things in a wrong order or something
<Ampelbein> ok, will do that
<Ampelbein> bryce: a dependency was missing. but this could not have resulted in an actual error as those dependencies are installed with xorg anyway. but i added them nonetheless.
<bryce> ok
<Ampelbein> bryce: now a package-naming question: currently the package is named 1.1.1-1build2, should i name 1.1.1-1build3 or rather 1.1.1-1ubuntu1, since this is a change not in debian yet?
<bryce> 1.1.1-1ubuntu1
<Ampelbein> thank you very much for helping!
<YokoZar> Ampelbein: regarding missing dependencies: does the package list ${shlibs:Depends} on its depends line?
<Ampelbein> YokoZar: yes, it does
<YokoZar> hmm, ok then.  I'm still trying to figure out the cases where that misses things
<bryce> Ampelbein: and thanks for investigating the problem!
<Ampelbein> bryce: bug #352083
<ubottu> Launchpad bug 352083 in xserver-xorg-input-aiptek "FTBFS due to xserver-1.6" [High,Confirmed] https://launchpad.net/bugs/352083
<Ampelbein> could you look over it and see if what i've done is ok?
<bryce> sure
<Ampelbein> i'm a bit unsure because i usually use quilt or cdbs to add patches. here i added quilt, but before there was no patchsystem used.
<Ampelbein> so there are many changes not reflected.
<bryce> Ampelbein: yes this looks perfect, thanks for adding a patch system, that's the correct way to do it
<bryce> Ampelbein: this looks good to me, do you feel it to be ready for upload?  I can sponsor for you if so.
<Ampelbein> bryce: don't know. the driver builds fine, but i don't have an aiptek handy to test if it works correctly
<bryce> hmm
<bryce> I tried pbuildering it but got an error
<Ampelbein> whuups.
<Ampelbein> my bad
<infinity> bryce: Your posted debdiff can't possibly be correct.  It doesn't include any debian/* changes for quilt.
<bryce> let me doublecheck that the patch is applying
<Ampelbein> i forgot
<Ampelbein> debian/rules not changed
<bryce> infinity: aha right
<infinity> bryce: Also, sort of ironic that you told him that was the right way to do it.  I tend to rey to discourage people from forking packaging from Debian (unless you intend to push the quiltiness back up to XSF) just to maintain a 3-line patch...
<bryce> Ampelbein: do you want to post a new debdiff with that added or shall I?
<Ampelbein> i will do that
<infinity> bryce: A 3-line inline diff is so much easier to merge than a bunch of extra goo in debian/*
<bryce> infinity: tjaalton is going to incorporate the fixes for this and other input drivers that are failing to build and put into debian
<infinity> s/tend to rey/tend to try/
<Ampelbein> so shouldn't i use a patchsystem for that?
<infinity> bryce: Kay.  If all the debian/* changes are going upstream too, I retract my objection.  I just spent too much time over too many years merging massive changesets that boiled down to "I wanted to fix a 5-character string, and I added 15 lines to debian/* to do it"
<Ampelbein> infinity: i'm sorry. i'm fairly new to this. just updated ubuntu-desktop-packages so far.
<infinity> Ampelbein: Don't apologize.  It's more of a religious thing than a strict policy. :)
<bryce> infinity: in this case the fix Ampelbein is adding is already upstream at freedesktop.org, so he's essentially backporting it for us
<infinity> Ampelbein: And if the people who will be dealing with this (bryce and tjaalton) think it's good, it's good.
<bryce> infinity: when debian has a newer version incorporated, we can probably just sync.  But meantime this will enable others to test the driver
<infinity> bryce: Yeah.  My usual argument is just that it makes merging with Debian a bit tougher.  More chance for conflicts in control/rules/etc.
<bryce> infinity: what Ampelbein is doing is good
<infinity> bryce: But, not my domain, so I defer to you and tjaalton.
<bryce> infinity: we're well accustomed to patch systems appearing and disappearing as needed for patch backports, so it's all good
<Ampelbein> bryce: correct patch added.
<Ampelbein> note to self: alaways run "debuild -S -sd" after changing something
<bryce> :-)
<Ampelbein> oh, you wanted a debdiff.
<Ampelbein> wait a second
<Ampelbein> debdiff attached
<bryce> awesome, pbuildering
<bryce> builds
<Superdweeb> hey guiz, I know this is a stupid, irrelevant, non-development question but..when we implement it,will plymouth work with a mobile radeon 7500?
<Ampelbein> i didn't figure out how to get rid of the missing symbols though. but they are in ALL previous builds
<Ampelbein> the missing dependency wasn't missing after all ;-)
<bryce> Ampelbein: ok looks good.  I added a mention of the rules changes in the changelog but otherwise looks good to go
<bryce> Ampelbein: upload sponsored, thanks :-)
<Ampelbein> damn. forgot that. ok then, will look at the other xserver-xorg-input-* packages tomorrow
<Ampelbein> it's 04:16AM here.
<Ampelbein> have to work at 10, so 4 hours sleep have to be enough ;-)
<Ampelbein> bryce: thanks for all the help. and hanks infinity for the different view on the patch-things
<Ampelbein> s/hanks/thanks.
<bryce> night Ampelbein
<Ampelbein> cu all.
<lfaraone> A
<YokoZar> Quick question: are the patch tagging guidelines at https://wiki.ubuntu.com/UbuntuDevelopment/PatchTaggingGuidelines just comments manually inserted to the top of a debdiff, or are they meant to go into the patch file inside the package itself?
<YokoZar> Nevermind it's almost surely the latter
<ScottK> YokoZar: It is the latter.
<YokoZar> So, I've added two patches to the main sponsorship queue, but in return I've cleared two things from the universe queue ;)
<Superdweeb> Does that mean...
<Superdweeb> You've..
<Superdweeb> OMG.
<Superdweeb> ZERO ENTROPY>
<Superdweeb> WORK DONE FOR NOTHING
<Superdweeb> ERROR IN MAIN DATABANKS.
<LordKow> is nautilus-actions not being maintained anymore upstream? i took a look at nautilus-act in GNOME's bugtracker and none of them are confirmed but all revolve around bug 341035
<ubottu> Launchpad bug 341035 in nautilus-actions "[jaunty] %d parameter returns nothing" [Undecided,New] https://launchpad.net/bugs/341035
<LordKow> i shouldn't say all of them. but a few of them.
<LordKow> heh yea the nautilus actions websites have not seen updates for at least a couple years.
<LordKow> oh it's a universe package, nm :-)
<dholbach> good morning
<fabrice_sp__> Hey dholbach!
<fabrice_sp__> good morning
<dholbach> hi fabrice_sp!
<pitti> Good morning
<dholbach> hum, why is pinentry-gtk2 suddenly installed on my machine? and gnupg-agent and gnupg and gnupg2, shouldn't gnupg and seahose be enough?
<dholbach> (just discovered when I had an ugly text box coming up for entering my gpg key)
<TheMuso> dholbach: So thats why the GPG signing dialog box changed. :)
 * TheMuso didn't really consider it, thought it was a change in gpg-agent or whatever got used.
<dholbach> TheMuso: I have no idea which upgrade pulled it in, but purging pinentry-gtk2 and gnupg-agent "fixed it for me"
<dholbach> still somewhat surprised about it and gnupg{,2} being around
<fabrice_sp> Hi pitti, it seems you uploaded the debdiff in Bug #338553, without changing what you put in your comment. Is it normal?
<ubottu> Launchpad bug 338553 in graphviz "[jaunty] libgv-python: Depends: python (< 2.6)" [Medium,Fix released] https://launchpad.net/bugs/338553
<pitti> fabrice_sp: sorry, what do you mean?
<pitti> dholbach: oh, I wondered about that yesterday
<dholbach> pitti: I didn't narrow down how that happenede
<pitti> dholbach: gnupg2 recommends gnupg-agent
<dholbach> pitti: do you know why we have the two gnupgs?
<pitti> dholbach: we have had them for ages
<pitti> primarily for kde
<dholbach> but both installed?
<pitti> purging gnupg2 would purge ecryptfs-utils and seahorse, hmm
<pitti> a-haa
<pitti> Package: libgpgme11
<pitti> Depends: libc6 (>= 2.8), libgpg-error0 (>= 1.4), libpth20 (>= 2.0.7), gnupg (>= 1.4.6-2), gnupg2 (>= 2.0.4)
<pitti> that should be an |, I guess
<pitti> also, why is a program a dependency of a library in the first place..
<pitti> I filed bug 352180
<ubottu> Launchpad bug 352180 in gpgme1.0 "libgpgme11 pulls in both gnupg and gnupg2" [Undecided,New] https://launchpad.net/bugs/352180
<pitti> slangasek: ^ that's responsible for at least 1.3 MB CD space
<slangasek> ah, cool
<pitti> a-ha
<pitti> http://launchpadlibrarian.net/24055413/gpgme1.0_1.1.8-2ubuntu1_1.1.8-2ubuntu2.diff.gz
<pitti> recent ubuntu specific change
<cody-somerville> pitti, depmod is failing to run with the new kernel (2.6.28-11.38) but apport says its not generating a report because "the error message indicates its a followup error from a previous failure".
<cody-somerville> pitti, Now its saying "No apport report written because MaxReports is reached already"
<pitti> cody-somerville: can you please ping mvo about it? that's from libapt
<cody-somerville> Okay.
<dholbach> can an ubuntu-release member follow up on bug 351591?
<ubottu> Launchpad bug 351591 in libpcap "Please sync libpcap 1.0.0-1 (main) from Debian unstable (main)" [Undecided,New] https://launchpad.net/bugs/351591
<pitti> dholbach: done, but what's to be done on it from a release hat?
<dholbach> pitti: I thought it needs an ACK at this point, no?
<pitti> dholbach: only freeze violations
<dholbach> ok
<pitti> dholbach: new gpgme uploaded; thanks for pointing out
 * pitti tosses more CD space to slangasek
 * dholbach hugs pitti
<dholbach> WOOHOO!
 * pitti hugs dholbach
<pitti> tkamppeter_: rejected foo2zjs from intrepid-proposed, no bug number in changelog
<tjaalton> nxvl: did you see my comment about aterm and the removal of /usr/bin/aterm?
<tkamppeter> pitti, sorry, will re-upload. Bug number for you to see the report already now: bug 351630
<ubottu> Launchpad bug 351630 in foo2zjs "[Intrepid] foo2zjs does not print with custom paper sizes" [Undecided,New] https://launchpad.net/bugs/351630
<tkamppeter> pitti, new version uploaded.
<ebroder> pitti: For bug 348865 the real symptoms are from the packages I listed that build-dep on libgsasl7-dev. Any chance that rebuilds of those could be uploaded to -proposed?
<ubottu> Launchpad bug 348865 in gsasl "[hardy] libgsasl7-dev missing dependencies on libntlm0-dev, libkrb5-dev" [Undecided,Fix committed] https://launchpad.net/bugs/348865
<ebroder> (the msmtp in -backports is what caused us to notice the bug initially)
<dholbach> can somebody moderate my mail on u-d-a?
<pitti> tkamppeter: is that fixed in jaunty already?
<pitti> dholbach: looking
<dholbach> thanks pitti
<pitti> dholbach: the "ÐÐÐ¡Ð¡ÐÐÐÐ¯ Ð ÐÐÐÐÐÐ"?
<dholbach> pitti: errrrrr, no :)
<pitti> the Ð ÐµkÐ»Ð°Ð¼Ð° Ð´Ð»Ñ ÐÐ°ÑÐµÐ¹ ÑÐ¸ÑÐ¼Ñ then?
<dholbach> pitti: no
 * pitti wonders why for some months we get 99% russian spam
<dholbach> pitti: something with Packaging Training? :)
<pitti> for those who don't speak Russian, that means "Advertisement for your company"
<pitti> at least you can't claim that they don't mark their spam appropriately
<pitti> dholbach: nudged
<dholbach> pitti: gracias!
<pitti> dholbach: de nada
<pitti> ebroder: once the -proposed version is in?
<pitti> ebroder: sure, if that's necessary, please explain in the bug and add tasks for the packages which need rebuilds; feel free to upload them already, we can accept them once the gsasl SRU is built and published
<tkamppeter> pitti, yes, it is fixed in Jaunty. Should I mark the main task of bug 351630 as "Fix Released" then?
<ubottu> Launchpad bug 351630 in foo2zjs "[Intrepid] foo2zjs does not print with custom paper sizes" [Undecided,New] https://launchpad.net/bugs/351630
<pitti> tkamppeter: yes, please
<pitti> tkamppeter: rejecting again; there's still no bug number in the changelog
<tkamppeter> pitti, bug updated.
<ebroder> pitti: I'll open the necessary bugs, but I'm not MOTU so I can't target or upload. Who should I subscribe to the bugs to get them dealt with?
<pitti> ebroder: motu-sru should already be subscribed, should be fine
<ebroder> Ok
<tkamppeter> pitti, in the notification I got there is a "(LP: #351630)", so I perhaps should send you the package by personal mail?
<tkamppeter> bug 351630
<ubottu> Launchpad bug 351630 in foo2zjs "[Intrepid] foo2zjs does not print with custom paper sizes" [Undecided,New] https://launchpad.net/bugs/351630
<pitti> tkamppeter: perhaps you accidentally uploaded the previous package again?
<tkamppeter> pitti, I will retry and after that report a bug in LP.
<pitti> tkamppeter: please look at the source.changes before uploading
<pitti> it should have the (LP: #12345) in it
<tkamppeter> pitti, it is exactly that.
<pitti> tkamppeter: ah, hang on
<tkamppeter> I have even verified the bug number with Ubotto
<pitti> tkamppeter: do you still have an .upload file around?
<tkamppeter> Yes.
<pitti> you need to delete this, otherwise dput will do nothing
<tkamppeter> I had done dput -f
<tkamppeter> and it showed that it uploaded files
<pitti> hmm
<pitti> let's just try it again then
<tkamppeter> I can simply raise the version number as a workaround for the LP bug
<pitti> tkamppeter: no, don't
<pitti> tkamppeter: ignore me
<mdke> seb128: around?
<pitti> I see the correct upload now
<tkamppeter> It always says
<tkamppeter> OK
<seb128> mdke: hi
<mdke> seb128: hi! I tried that fix for brasero and it works, but the debdiff is contaminated for some reason by the pot file for the help. I've attached it to bug 264314 anyway, let me know if you know why that has happened
<ubottu> Launchpad bug 264314 in brasero "Brasero documentation does not appear in Yelp search results" [Medium,Confirmed] https://launchpad.net/bugs/264314
<seb128> mdke: clean targets are buggy you probably did build clean and rebuild in the same directory
<seb128> mdke: you can edit the debdiff by hand or remove the template manually if you want
<mdke> seb128: aha. Ok, let me try
<mdke> seb128: ok, revised debdiff posted to the bug
<mdke> thanks
<seb128> mdke: thank you
<seb128> mdke: subscribe the sponsor team if you didn't, I will have a look later
<mdke> seb128: done
<slangasek> pitti: oh - I forgot that en is the only language with language-support on the CD... that means splitting gnome-user-guide buys us even more space than I thought, too :)
<directhex> yay, space
<pitti> slangasek: hehe
<pitti> even with the current dailies we have an impressive 11 MB (i386)/7 MB (amd64) free
<pitti> add another 1.3 for the gnupg2 fix
<pitti> yay
 * slangasek preemptively adds more langpacks in :)
<directhex> now just free up another 100 meg, and we're sorted for OpenJDK!
<Hobbsee> but didn't you know we have to add a whole bunch of otehr default wallpapers on?  apparently that's just *so* important, according to the bug about it...
<Mithrandir> Hobbsee: heh
<directhex> Hobbsee, well, whatever happened to monthly naked wallpapers, what's what i want to know!
<Hobbsee> directhex: they got moved to your friendly neighbourhood porn site, filtered by the Australian Minister for Censorship.
<directhex> Hobbsee, i thought only dissident thought was on the censorship ministry's filter list
<Hobbsee> directhex: that too.  There's a whole bunch of stuff on there that shouldn't be, it appears, from wikileaks
<directhex> is that the same ministry for censorship that feels the best way to protect children from violent videogames is to outright refuse to classify 18-rated games as 18+, and instead release them as 15+?
<seb128> pitti, slangasek: can we get a list of what language packs are on the CDs now and what else we could get with how much space?
<Hobbsee> directhex: i'm not sure.
<RAOF> They do refuse 18+ games, yes.  I'm not sure it's the same department.
<slangasek> seb128: 'grep Languages ship live'?
<slangasek> (for the first part)
<seb128> slangasek: right, thanks ;-)
<slangasek> still a short list, but looking better
<slangasek> knowing what we can get with more space will have to wait for another CD run with pitti's latest space-saving changes
<seb128> ok
<slangasek> French is safe on i386 desktop, anyway. :)  Still not on amd64 desktop yet
<ebroder> What causes...apt? dkpg? I guess I'm not sure which...to display the changelog entry and send mail to root@localhost?
<pitti> bryce: *wiping off a tear* Jesse Barnes' -intel patch turned my X from "several problems" into "work of perfection"
<seb128> pitti: what patch?
<seb128> pitti: does it fix intel crashing when closing an another session?
<pitti> seb128: https://bugs.freedesktop.org/show_bug.cgi?id=19304#c41
<ubottu> Freedesktop bug 19304 in Driver/intel "[i945 FBC] spontaneous black screen (major pipe-A underrun)" [Normal,Reopened]
<pitti> seb128: I didn't have that problem
<pitti> seb128: but I don't think so
<seb128> ok
<pitti> seb128: that patch fixes flickering in glxgears, and pipe underruns
<pitti> seb128: I did several guest sessions etc. yesterday, no crashes for me
<pitti> and so far it didn't freeze after suspend yet
<seb128> lucky you
<seb128> I can't use my laptop to do any user switching since jaunty
<seb128> it crashes on session closing with exa
<seb128> and on session opening with uxa
<pitti> bryce: apparently the "fix pipe underrun" patch I previously applied was more like a hack (static watermark levels), current one computes them dynamically
<pitti> seb128: is that bug upstream?
<pitti> I get quite a good responsiveness from them
<seb128> pitti: no, it's on https://bugs.edge.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/348428 but I will upstream it today if they don't
<ubottu> Ubuntu bug 348428 in xserver-xorg-video-intel "Swithing to another user and then to anything else, freezes laptop. Jaunty" [High,Confirmed]
<seb128> I've added stacktrace for the exa and uxa crashes there
<UBN2> why does python suck so much compared to all other languages???
<pitti> bah, shouldn't have said this too loudly, X hung again after suspend
<Hobbsee> it wanted to catch you out again...
<pitti> bah, not having suspend sucks
<pitti> especially on planes and conferences
<directhex> pitti, weren't you paying attention? jaunty boots so awesomely fast, you don't NEED suspend!
<pitti> seb128: just read the bug (also the upstream one, which is linked now); I don't get that, no
<pitti> directhex: now, if only we had session saving..
<seb128> pitti: ok
<directhex> pitti, still broken on jaunty?
<pitti> directhex: and "switch on" to "desktop" is still 2 minutes on my machine
<seb128> pitti: we have on logout ;-)
<pitti> seb128: session _saving_?
<pitti> I'm still starting my gsession.sh script after logging in
<pitti> but that only does half of the job
<hyperair> directhex: when you can boot in 3 seconds, tell me again that i don't need suspend
<directhex> hyperair, try BeOS ;)
<hyperair> that's not ubuntu
<seb128> pitti: yes
<hyperair> i want ubuntu damnit
<jamesh> pitti: thanks for landing that hal-info patch for me.
<pitti> jamesh: you're welcome
<jamesh> now we just need portable media players running UME
<RicardoPerez> pitti: ping
<pitti> RicardoPerez: http://err.no/personal/blog/2006/Oct/10
<RicardoPerez> pitti: oh, sorry, you are right :)
<RicardoPerez> pitti: bug #348225 seems not to be solved for me. translations are still inside .desktop files
<ubottu> Launchpad bug 348225 in synaptic "Remove inline translations from .desktop files" [Medium,Confirmed] https://launchpad.net/bugs/348225
<pitti> RicardoPerez: hm, worked on a local build
<pitti> RicardoPerez: I assume the buildd chroots have an outdated pkgbinarymangler then
<RicardoPerez> pitti: can I help in some way in order to fix it?
<pitti> RicardoPerez: can you please reopen the synaptic/s-c-p tasks and say so?
<RicardoPerez> pitti: right, they're already open
<pitti> infinity, lamont: it seems our buildd chroots have an outdated pkgbinarymangler; can you please upgrade them to version 57?
<infinity> pitti: They autoupgrade on build...
<pitti> that's what I thought as well..
<infinity> pitti: That said, there's no mangler upgrade being done in recent builds, so it's up-to-date in the chroots...
<infinity> pitti: Or not... *blink*
<pitti> weird, I looked at the synaptic build log, and there's no trace of the new code
<infinity> Oh, FFS.
<infinity> pitti: Someone demoted it to universe...
<infinity> pitti: On main builds, the chroots only have main in sources.list, so no upgrade.
<infinity> pitti: Why on earth was pkgbinarymangler demoted?
<pitti> WTH?
<pitti> infinity: I have no idea
 * pitti promotes
<pitti> infinity: perhaps it appeared in component-mismatches, and someone was too eager with cleaning it up
<RicardoPerez> I see pkgbinarymangler in universe, too
 * pitti seeds
<pitti> infinity: so once that's in main again, the chroots will upgrade them automatically?
<infinity> pitti: Yup.
<pitti> infinity: ok, thanks!
<infinity> pitti: I'll freshen them during my work hours tomorrow anyway, but the auto-upgrading should work once it's republished to main.
<infinity> Oh how I long for audit trails in soyuz, so I could tell WHO demoted it back in February. :/
<RicardoPerez> Thanks a lot to anybody helping to fix this bug :)
<RicardoPerez> pitti: can I disturb you with another "fixed" bug, not fixed really?
<pitti> RicardoPerez: sure
<RicardoPerez> pitti: bug #207677, I still can't see the "System policy prevents modifying the configuration" message translated when I click on any Unlock button.
<ubottu> Launchpad bug 207677 in system-tools-backends ""System policy prevents modifying the configuration" shows untranslated" [Medium,Confirmed] https://launchpad.net/bugs/207677
<pitti> RicardoPerez: I got your bug mail from that, will follow up soon
<RicardoPerez> pitti: Thanks very much! I stay tuned
<RicardoPerez> see you all, thanks again, and bye!
<directhex> time to do-release-upgrade
<directhex> for the 7th time since it was installed with hoary
<directhex> i DO with jaunty upgrades didn't sever network connectivity early on in the package installation
<directhex> wish
<cjwatson> ebroder: you have apt-listchanges installed, and configured to behave that way
<pitti> http://qa.ubuntu.com/reports/bug-fixing/jaunty-fixes-report.html
<pitti> I broke the 200 mark!
<cjwatson> damn you
<directhex> i have 10. 10 is loads!
<cjwatson> we're 21 short of intrepid
 * pitti throws the gauntlet to cjwatson
<pitti> cjwatson: still weird, I had expected that we'd fix much more in jaunty :(
<pitti> cjwatson: intrepid, is that including SRUs?
<pitti> the kernel SRUs alone probably account for something like 70 bug reports
<cjwatson> I'm not sure but I guess so
<cjwatson> much more> yes :(
<cjwatson> we still have a couple of weeks
<pitti> bryce: I just updated 339091 with some new investigations, and linked to a kernel bug; is it even possible that the kernel DRM regression in 2.6.29rc6 is responsible for this? IOW, did we pull the DRM bits from head into our kernel?
<tjaalton> pitti: it's possible
<pitti> tjaalton: ah, thanks; I updated the kernel, fd.o, and LP bug with my findings
<tjaalton> pitti: there were a few commits that were pulled from upstream, but they didn't solve vblank so it was disabled again in the DRI driver (mesa)
<tjaalton> but the kernel commits remained
<pitti> tjaalton: you mean the "trying to get vblank count for disabled pipe 1"? or the "Unknown parameter 6" thingies?
<tjaalton> pitti: I don't know if they are related
<ogra> is anyone objecting if i add armel to the list of arches in desktop for openoffice
 * ogra slaps forhead several times for that silly oversight
<ogra> (and indeed i need to upload -meta)
<tjaalton> pitti: hm, the patches are from the intel stable patchset for the kernel, so removing them now might cause other problems
<pitti> tjaalton: oh, I'm not suggesting we should ditch them; perhaps upstream can fix them
<tjaalton> pitti: but you could try mesa 7.4 from my ppa, it seems to solve at least some of my problems
<tjaalton> pitti: yeah, that should be the right approach :)
<pitti> tjaalton: oh, sure
<tjaalton> and we didn't pull any patches that weren't either in .29 or drm-next
<pitti> tjaalton: I know, but someone else confirmed that the regression happened between 2.6.29rc5 and rc6
<pitti> in fact, it was the original reporter of http://bugzilla.kernel.org/show_bug.cgi?id=12778
<tjaalton> I did propose a couple of patches related to vblank, but decided to disable it instead, since upstream couldn't decide how to fix it properly
<ubottu> bugzilla.kernel.org bug 12778 in Video(DRI) "suspend regression from 29rc5 to 29rc6" [Normal,Needinfo]
<tjaalton> yeah I saw that
<tjaalton> maybe reassign it to jbarnes?
<pitti> I don't think I'm eligible to assign bugs in bz.kernel.org..
<tjaalton> hmm ok
<tjaalton> but try the new mesa first
<pitti> trying your mesa now
<tjaalton> thanks
<pitti> thanks to you
<cjwatson> ogra: no objection here
<ogra> ok, already running ./update :)
<firefly2442> I'm looking for an online gettext translation system.  The Launchpad Rosetta project looks great but isn't Launchpad still closed source?  Are there any plans to spin Rosetta off into a separate standalone application?  Thanks.
<dholbach> firefly2442: try asking in #launchpad - launchpad including rosetta will be open-source in July (I think)
<firefly2442> yep, by July - https://dev.launchpad.net/OpenSourcing
<mdz> lool,ogra: with the latest jaunty UNR, I'm seeing gnome-do pop up unexpectedly on login.  this wasn't happening before.  are you already aware of it?
<ogra> mdz, i personally wasnt (StevenK cares for UNR)
<StevenK> mdz: Oh. I seeded it, but it popping up on login is unintended
<ogra> StevenK, does it actually need to be installed ? sounds like something that could go into ship
<StevenK> ogra: I'd like it seeded ...
<StevenK> Which is why it was, actually.
<ogra> ah
<cjwatson> TheMuso: does Ara's latest comment in bug 301755 represent a new bug, or a recurrence of the same bug?
<ubottu> Launchpad bug 301755 in pulseaudio "Crackling noise after update to pulseaudio" [High,Fix released] https://launchpad.net/bugs/301755
<lool> mdz: never seen that
<StevenK> lool: I seeded gnome-do early my afternoon
<lool> StevenK: Shall we defer its addition to karmic?
<lool> StevenK: or is this something the upstream UNR folks care a lot about?
<StevenK> lool: It's something *I* care about
<directhex> Do?
<StevenK> directhex: Do is Good
<directhex> StevenK, what have you seeded it onto?
<StevenK> directhex: ubuntu-netbook-remix
<directhex> oh, coolness!
<directhex> so how long before dell are shipping netbooks with Do by default? :p
<directhex> does the ubuntu buildd support packages in piped build-deps?
<directhex> i.e. does "debianfoo | ubuntufoo" work, or does it have that dreadful debian "ignore everything after the pipe" issue
<cjwatson> we use the first alternative that's installable
<directhex> okay, good. and i'm not misremembering that debian uses only the first alternative, am i?
<cjwatson> directhex: I believe that's still correct, and it certainly used to be the case
<directhex> okay, cool, i can use that to work around a marginally borked transition and still allow syncing
<directhex> cjwatson, oh, who's on the desktop team & organising things for UDS?
<cjwatson> directhex: my guess would be rickspencer3 (when online)
<cjwatson> directhex: or ask pitti
<mpt> asac, was it you who mentioned that most of the bugs reported against gnome-power-manager are actually kernel problems?
<asac> mpt: i dont think so
<asac> i probably said that about networkmanager bugs ;)
<mpt> ah, maybe :-)
<mpt> Well, it looks like a similar thing is happening with notify-osd
<asac> mpt: bugs due to graphics driver issues`
<asac> ?
<asac> about metacity + compositing? or compiz?
<mpt> No, but now that people are paying attention to the notification bubbles, they're reporting bugs about silly bubbles, and those bugs are actually in gnome-mount or pidgin-libnotify or network-manager or something else
<seb128> mpt: yeah there is lot of component in those cases
<StevenK> asac: Oh! I had a silly question why the NM icon for UNR Jaunty is the blue bars, where as Jaunty -desktop uses green curvyness?
<asac> StevenK: green curvyness? do you use a green monitor ;)?
<asac> StevenK: seriously. i guess you use a custom theme in jaunty?
<StevenK> asac: Oh, the NM icon is dictated by the icon theme?
<asac> StevenK: they honur icon themes, yes. most don't overload the signal strength one, but you can just do it
<StevenK> asac: The green one I've seen is shiny, but the default one is pretty good too
<asac> StevenK: can you give me a screenshot of the green?
<asac> i always want to see new ideas
<StevenK> asac: I'll get one, the laptop is friends and is packed up
<StevenK> a friends, sigh
<asac> StevenK: ok. thanks!
<jtholmes> are there any strong efforts to move to  cdebconf?
<cjwatson> jtholmes: back-burner but not strong. Why?
<mdz> StevenK: it's reproducible 2/2 attempts here
<StevenK> mdz: Yup. I need to figure out how to silence it.
<mdz> StevenK: is there an urgent need to add a new app to the default install three weeks before release?
<jtholmes> cjwatson, just wondered as i was poking around in debconf and found out about cdebconf
<StevenK> mdz: It's a nice to have only
<cjwatson> jtholmes: both of them are reasonably actively maintained in different ways. There's a long-term goal to switch to cdebconf but it's unlikely to be especially soon.
<jtholmes> cjwatson, yes too much cross dependency in the whole debconf area
<jtholmes> to move soon
<cjwatson> jtholmes: not really, almost all the dependencies have been fixed
<jtholmes> cjwatson, i know you are one of the main players in ubuntu wonder if you could look at bug 352348 and give me an idea where in debconf the problem is and i will attempt to fix it
<ubottu> Launchpad bug 352348 in ubiquity "weak password ubiquity yes/no button text incorrect" [Undecided,New] https://launchpad.net/bugs/352348
<cjwatson> jtholmes: the blocking issues are missing features in cdebconf itself
<cjwatson> jtholmes: nowhere in debconf at all
<jtholmes> then where
<cjwatson> jtholmes: ubiquity
<jtholmes> yes but doesnt the button text come from debconf template file?
<jtholmes> in qbiquity
<cjwatson> sure, but that's like asking where in the C compiler is the bug in a C program :-)
<jtholmes> ok i will poke around in the installer some more and see if i can locate the issue
<cjwatson> no need really, it's a typo
<cjwatson> that was supposed to be ubiquity/imported/yes rather than ubiquity/text/yes
<cjwatson> jtholmes: fixed in my tree, thanks for the heads-up
<jtholmes> cjwatson, where did you fix it what file?
<jtholmes> file name
<cjwatson> ubiquity/components/usersetup.py
<jtholmes> thanks need to know more about installer
<james_w> StevenK: /apps/gnome-do/preferences/core-preferences/QuietStart or -q in the autostart .desktop file should do it
 * lamont is reminded yet again part of why he hates {c,}dbs.
<lamont> wtf is the 'unpack and patch the source' target again?
 * lamont goes grepping
<cjwatson> jtholmes: http://bazaar.launchpad.net/~ubuntu-installer/ubiquity/trunk/revision/3152
<cjwatson> lamont: cdbs or dbs. which?
<lamont> cjwatson: well, actually looking at two packages, they use one each
<jtholmes> cjwatson, thanks
<lamont> though for my use, debian/rules build + ctl-C does the trick
<cjwatson> lamont: policy nowadays recommends 'debian/rules patch' so try that first (and also recommends debian/README.source). Older packages may not implement that yet
<lamont> yeah - patch is no such target in both coreutils and libnss-ldap
<sistpoty|work> lamont: cdbs should be apply-patches (I guess at least)
<lamont> sistpoty|work: yep
<lamont> ta
<sistpoty|work> np ;)
<cjwatson> somebody should fix cdbs to comply with policy
<cjwatson> actually, simple-patchsys already does
<cjwatson> simple-patchsys.mk:patch: apply-patches
<sistpoty|work> heh, just saw this as well
<cjwatson> as do dpatch.mk and patchsys-quilt.mk
<cjwatson> tarball.mk doesn't. See http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=485069
<ubottu> Debian bug 485069 in cdbs "cdbs: suggested text to be referenced from README.source" [Wishlist,Open]
<nxvl> tjaalton: which bug?
<tjaalton> nxvl: debian bug 518962
<ubottu> Debian bug 518962 in aterm "incorrect use of update-alternatives" [Serious,Closed] http://bugs.debian.org/518962
<tjaalton> nxvl: removing it was wrong
<nxvl> tjaalton: no it wasn't
<tjaalton> nxvl: please explain
<tjaalton> aterm never shipped /usr/bin/aterm
<tjaalton> but aterm-xterm
<nxvl> tjaalton: there is still a call to update-alternatives, there was just one that was wrong
<tjaalton> nxvl: no, /usr/bin/aterm was correctly handled by aterm or aterm-ml
<nxvl> tjaalton: and it was breaking the debian policy
<tjaalton> how so?
<nxvl> tjaalton: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=509667#10
<ubottu> Debian bug 509667 in terminator "terminator: incorrect use of update-alternatives" [Normal,Closed]
<tjaalton> not relevant, since aterm (or any other package for that matter) doesn't ship a binary called /usr/bin/aterm
<tjaalton> that u-a was just mistakenly copied from aterm
<tjaalton> and makes no sense in terminator AIUI, but there was no reason to remove it from aterm
<hyperair> pitti: i got a whole bunch of emails from rosetta regarding messed up .po files from nautilus-share. what should i do about it?
<hyperair> We were unable to import your translations because you did not update
<hyperair> the time stamp in its header to state when you added your translations.
<cjwatson> hyperair: nothing, it's an LP bug
<hyperair> ah i see
<tjaalton> nxvl: so, the change should be reverted
<nxvl> tjaalton: feel free to do so
<freinhard> hi!
<freinhard> is someone working on language-suppport-translations-* round?
<tjaalton> nxvl: ok, although I can't fix it in debian
<cjwatson> freinhard: ArneGoetje
<nxvl> tjaalton: me neither, i'm not a DD
<tjaalton> nxvl: and the package is orphaned ;)
<nxvl> yup
<freinhard> ArneGoetje: just did a update on kubuntu and wondered why i got some new gnome dependencies: does gnome-user-guide-* need to be in language-support-translations?
<ArneGoetje> freinhard: which language?
<rgreening> ArneGoetje: all
<rgreening> -en, -de, ...
<ArneGoetje> that should be a mistake
<freinhard> ArneGoetje: germa
<rgreening> yay
<cjwatson> ArneGoetje: hmm. how else are we going to get the appropriate version of the GNOME user guide installed?
<ArneGoetje> let me take a look
<rgreening> ArneGoetje: looks like "Ubuntu automatic language-pack builder" added it
<cjwatson> except perhaps by adding it to language-pack-gnome-foo, but I don't think that's appropriate
<cjwatson> we don't have gnome and kde variants of language-support-*
<ArneGoetje> cjwatson: well, the gnome-user-guide should definetely not go to kubuntu, don't you think?
<rgreening> thanks freinhard for pointing this out.
<freinhard> rgreening, ArneGoetje at least the ChangeLog states that the lang-pack builder is the bad guy
<rgreening> exactly. Should be "|" with something to make it not a requirement.
<cjwatson> ArneGoetje: sure, but that doesn't help to make sure that Ubuntu carries on working properly too
<cjwatson> certainly gnome-user-guide-* could have |-deps on language-support-translations-foo
<cjwatson> that's a hack but we've used the same hack elsewhere
<cjwatson> slangasek: could you look at bug 352034?
<ubottu> Launchpad bug 352034 in dell "grub2 can no longer show chinese characters" [High,Confirmed] https://launchpad.net/bugs/352034
<rgreening> the issue here is that adding this as is, will impact the CD/DVD size for Kubuntu and other non-gnome desktops
<rgreening> we are already having to lzma compress parts of KDE to fit.
<cjwatson> rgreening: we understand the issue
<rgreening> cool :P
<cjwatson> hmm, the |-deps won't help here since the package is big in itself
<cjwatson> the problem is that right now we have no particularly good mechanism for this
<cjwatson> getting into a situation where we are trading off CD space between Ubuntu and Kubuntu is not really going to help anyone :-)
<rgreening> cjwatson: the other issue is gnome user guide en provides no benefit to non gnome desktops and is a waste or resources
<cjwatson> rgreening: you can stop beating the dead horse :-)
<rgreening> It's not dead jim...
<rgreening> :)
<cjwatson> actually, gnome-user-guide-en is very small in itself
<cjwatson> Size: 42874
<ArneGoetje> cjwatson: is the gnome-user-guide a requirement on the desktop, or optional (suggests)?
<rgreening> but it has additional deps
<cjwatson> rgreening: yes I understand that
<cjwatson> that's why I said "in itself"
<rgreening> ah. k. got it. I'll just lurk :P
<cjwatson> ArneGoetje: it's a recommendation (i.e. removable), but it does need to be present in Ubuntu installations
<cjwatson> the language split was to save space on Ubuntu CDs by allowing us to control which translations are present
<ArneGoetje> cjwatson: can we add a suggests to language-pack-gnome-foo for this?
<cjwatson> ArneGoetje: to what end? the installer will ignore that
<cjwatson> ArneGoetje,slangasek: what do you think about moving the gnome-user-guide-LL dependency from language-support-translations-LL to language-pack-gnome-LL?
<ArneGoetje> cjwatson: and recommends?
<cjwatson> ArneGoetje: recommends would be fine I think, but why bother, it might as well be depends
<cjwatson> oh, recommends would make it removable
<ArneGoetje> cjwatson: if it should be removable?
<cjwatson> I think it's fine in language-pack-gnome-LL on the grounds that it was previously part of the desktop anyway
<cjwatson> so yes, I think that's probably the right answer here
<rgreening> awesome
<cjwatson> it's suboptimal because really that stuff ought to be in language-support-*
<rgreening> you guys rock
<cjwatson> but we can't make that flavour-specific
<cjwatson> so this might bloat up the Ubuntu CD a bit again
<cjwatson> I'm not sure how much
<ArneGoetje> cjwatson: does it need to be on the CD?
<cjwatson> ArneGoetje: the only way to make it not on the CD is to put it in language-support-*
<cjwatson> actually, it is false that this will have a significant effect on CD size for Kubuntu
<cjwatson> the only language-support-* that's on the Kubuntu CD is language-support-en
<cjwatson> so that's only 1.5MB or so
<ArneGoetje> cjwatson: how does the language-pack-gnome-LL package get pulled by the installer? I know we have some code in language-selector to pull those depending on the flavor, because we don't have depends.
<cjwatson> oh, hang on, gnome-user-guide pulls in scrollkeeper and yelp. bah
<cjwatson> ArneGoetje: language-pack-gnome-LL is selected per-flavour by preseeding, yes. There is no such mechanism for language-support-LL.
<freinhard> cjwatson: jupp, that's why i got concerned
<ArneGoetje> cjwatson: can we just add the gnome-user-guide-LL to that?
<cjwatson> ArneGoetje: isn't that what we were both suggesting above? :-)
<ArneGoetje> cjwatson: ah, you were talking about the pre-seeding... I though a recommends to the package...
<cjwatson> so the other approach would be to make the gnome-user-guide-LL packages depend on gnome-user-guide | language-support-translations-LL; that would still mean that Kubuntu users would get gnome-user-guide-LL (i.e. just the translations) installed if they ran the language selector post-installation, but they wouldn't get gnome-user-guide, scrollkeeper, yelp, etc.
<cjwatson> ArneGoetje: we were both talking about a recommends
<freinhard> all in all, should add ~30MB
<cjwatson> ArneGoetje: you asked how the installer selected language-pack-gnome-LL, and that's done by preseeding. This is orthogonal
<ArneGoetje> cjwatson: I was actually thinking to hack lp-o-matic to add the recommends to the l-p-gnome-LL package...
<cjwatson> ArneGoetje: yes, that's exactly what I was suggesting too ...
 * cjwatson feels there is not a little bit of confusion here
<cjwatson> freinhard: with |-deps on language-support-translations-LL, it would be a megabyte or so at most, actually. I agree that the current situation is a problem
<cjwatson> but, since we were already including gnome-user-guide in the stock Ubuntu desktop, I think a recommends from language-pack-gnome-LL is fine in this particular instance
<cjwatson> we may need to revisit that in the future
<ArneGoetje> cjwatson: ok, never mind. :)
<cjwatson> I sort of feel we ought to use special fields in the Packages file for all of this, rather than having a zillion metapackages
<ArneGoetje> cjwatson: +1
<cjwatson> Package: gnome-user-guide-fr Language: fr/translations/gnome, or something better-designed
<cjwatson> ArneGoetje: but yeah, in the meantime, can you make that langpack-o-matic adjustment to move gnome-user-guide-LL from l-s-t-* to l-p-gnome-*?
<ArneGoetje> cjwatson: yes, I will ask pitti about that.
<tkamppeter> pitti, I have problems with bug 348316 and its duplicates. Seems that the USB stack of the current kernel has lost compatibility with the CUPS USB backend.
<ubottu> Launchpad bug 348316 in cups "Printer (HWModel Name) May Not Be Connected" [Undecided,Confirmed] https://launchpad.net/bugs/348316
<\sh> guys, what was the magic for cdbs to tell cdbs "please add DEB_CONFIGURE_EXTRA_FLAGS=..." only when on arch != i386?
<tkamppeter> pitti, seems that half of the users get their printers detected but print jobs put the USB backend into an infinite loop (jobs never reach "Stopped" state or disappear).
<cody-somerville> \sh, you could conditionally declare DEB_CONFIGURE_EXTRA_FLAGS, no?
<\sh> cody-somerville: you mean standard make ifdef?
<\sh> yes..the easy way ,-)
<cody-somerville> ;)
<\sh> fixing google-perftools
<cjwatson> slangasek: (never mind, I gave Mario a suggested workaround which I think should work)
<pitti> hyperair: I usually ignore them
<pitti> tkamppeter: hm, weird; I just upgraded my wife's computer to current jaunty, maybe I can reproduce it there
<metellius> what are the chances that someone important actually decides the current 2.6.x intel drivers are too unstable and actually pull in 2.7 for a stable and smooth desktop, in time for jaunty?
<jdong> I'm no X developer, but looking at the release schedule, zero?
<\sh> pitti: any clue on http://launchpadlibrarian.net/24382167/buildlog_ubuntu-jaunty-amd64.im-sdk_12.3.91-6.3ubuntu1_FAILEDTOBUILD.txt.gz ? telling dh_strip to not build ddeb packages?
<hyperair> pitti: heh. alright then =p
<seb128> metellius: because 2.7 is the magical solution to all bugs? ;-)
<seb128> metellius: new version usually bring fixes and other issues and required testing it's not that easy
<hyperair> there's a 2.7?
<hyperair> does it fix all the performance regressions?
<pitti> tkamppeter: ah, saw your mail; did you try the new usb backend from 1.4?
<metellius> hyperair: there's an RC, and it stabilized uxa completely for me
<hyperair> metellius: really? cool!
<hyperair> metellius: you compiled?
<metellius> nope, got it from xorg-edgers
<hyperair> aah i see
<hyperair> cool
<hyperair> i should try it out
<metellius> deb http://ppa.launchpad.net/xorg-edgers/ppa/ubuntu/ jaun#ty main restricted universe multiverse
<hyperair> yes yes i know
<hyperair> s/#//
<metellius> indeed
<hyperair> mmhmm
<hyperair> but i don't have a live system at the moment
<hyperair> my cdrw's gone
<hyperair> won't get detected
<metellius> i'm so happy right now
<metellius> it all just works
<hyperair> hahah
<hyperair> i'm more interested in knowing whether it fixes performance regressions
<hyperair> UXA didn't really fix the regressions for me
<hyperair> with 2.6
<hyperair> i was getting framerates around 20FPS (intrepid gets 60FPS) for a game
<hyperair> it's playable, but everything moves so slowly
<metellius> I don't dare start up a game right now, I need to enjoy the smooth desktop before I let a possible crash bring down the ride
<pitti> tkamppeter: yes, happens for my samsung as well on jaunty
<pitti> tkamppeter: I'll take the bug and look into it ASAP
<radix> cjwatson: ping, do you have a moment to follow up on the discussion last week about inheriting environment variables and file descriptors in landscape-client?
<cjwatson> radix: sure
<radix> (about debconf)
<radix> cjwatson: okay, cool. so I've got it deleting DEBIAN_ and DEBCONF_ environment variables to avoid propagating those to further package installation processes, but I'm wondering about the file descriptor stuff you mentioned
<radix> cjwatson: you said that debconf opens some file descriptors which might be propagating to the child processes of the postinst script
<radix> (i think)
<radix> cjwatson: but I'm wondering if that's true. do you know how that file descriptor is being opened? it looks  like bash makes sure most file descriptors are not passed on to child processes, but some -- for example those created with "exec 7< whatever.txt", do get propagated
<cjwatson> /usr/share/debconf/confmodule opens fd 3 for communication from the "confmodule" (e.g. landscape-client.postinst) to the debconf frontend
<cjwatson> it is created using 'exec 3>&1'
<radix> oh, look at that :)
<cjwatson> I'm pretty sure that it isn't close-on-exec; I don't think a number of things would work if it were
<radix> hrmph. it's too bad that FD isn't cloexec.
<radix> ah
<cjwatson> yes, it is a bit inconvenient
<cjwatson> but really, it's good practice for daemons to close stray file descriptors on startup
<radix> yeah
<radix> it's just that figuring out how to do that with our existing daemonization code is becoming a bit difficult to do in time for jaunty :)
<cjwatson> frex, Stevens recommends it (APUE p.417)
<radix> cjwatson: do you know if there's a bashism or perhaps some tiny C wrapper program that can do that for me?
<abentley> superm1: I've just filed bug #352452, the fruit of a rather frustrating evening and morning.  If you have any questions, I'm happy to answer them.
<ubottu> Launchpad bug 352452 in fglrx-installer "mere presence of fglrx on system prevents OS drivers from working" [Undecided,New] https://launchpad.net/bugs/352452
<radix> like, "run-without-fds ./program"?
<cjwatson> radix: not in that form, but if it's just fd 3, then you could start landscape-client with 3>&-
<radix> hmm
<radix> yeah, that doesn't sound too scalable :)
<cjwatson> it's not, but there may not actually be all that many fds involved
<cjwatson> (don't use exec here, btw, just put that redirection on the line where landscape-client is invoked
<cjwatson> )
<radix> right
<radix> well, I'll consider that. I'll also give another bash at implement proper FD closing in landscape-client
<cjwatson> in principle, it's possible for somebody to use cdebconf, which opens a different set of fds
<cjwatson> but not really in practice right now
<radix> cjwatson: okay, I've learned what I wanted to know. Thanks very much for your help!
<cjwatson> you could look at /proc/$(pidof landscape-client)/fd to see whether which stray fds it has open
<radix> it'd be nice if I could determine whether a FD was inherited or opened in the current process, but I guess that's impossible
<pitti> tjaalton: FYI, with your mesa I also got a hang a bit after resuming, it just completely messes up screen
<radix> the landscape-client startup code is a bit poorly factored; it opens some important FDs *before* daemonizing, apparently
<superm1> abentley, there isn't any easy way to fix that since AMD provides replacement dri and glx libraries
<abentley> superm1: Does disabling fglrx in "Hardware Drivers" remove those packages?
<tjaalton> pitti: go intel..
<cjwatson> radix: you could probably close inherited fds before that, and before daemonising
<cjwatson> radix: after all you've already forked once
<cjwatson> it's not perfect but it would do for this purpose, wouldn't it?
<radix> hmm, probably
<radix> the main problem we have is that we try to report certain errors synchronously, I think
<cjwatson> radix: doesn't help with the "where do stdin/out/err go?" problem of course, but perhaps you already deal with that in some other way
<radix> so there's a significant amount of code that happens before daemonization
<abentley> superm1: My strong impression was that it does not, and I would never have hit up the X logs and apt if just disabling fglrx in "Hardware Drivers" (jockey?) had worked.
<lool> Is there some niver way than "`eval echo \\\$$c`" to get the value of a var named c in shell?
<lool> Sorry, of a var named $c
<\sh> holiday time...cu later :)
<pitti> tkamppeter: argh no, seems I have a completely different bug
<sistpoty|work> lool: as in... just $c?
<lool> sistpoty|work: No, rather ${$c} but that doesn't work
<cjwatson> lool: ${!c} but that's a bashism
<cjwatson> there's no nicer portable way
<lool> so eval ... hmm
<lool> cjwatson: thanks
<cjwatson> well, you can cut down on the backslashes
<cjwatson> "$(eval echo "\$$c")"
<lool> Right
<lool> I was at eval echo "\$`echo $c`"
<lool> which was just an useless use of `echo ` :)
 * Keybuk has a *weird* Python issue
<Keybuk> after upgrading from intrepid -> jaunty, nothing pythonic works until I dpkg-reconfigure it
<jdong> is that related to that python bug in the topic? </stupid wrong suggestion>
<Keybuk> I don't think so
<superm1> pitti, does disable fglrx in hardware drivers remove xorg-driver-fglrx and friends?
<superm1> or is it 'supposed to'?  i think to abentley's point above it should
<pitti> superm1: yes, it's supposed to
<superm1> abentley, well was that on intrepid or jaunty?  pitti when did it start doing it?
<pitti> superm1: it never did *not* do it
<pitti> superm1: what's the "& friends" part about?
<pitti> superm1: removing the driver will only remove xorg-driver-fglrx
<pitti> oh, and fglrx-kernel-source
<pitti> should it kill something else, too?
<superm1> no, i think that's sufficient.  i'm just a bit perplexed how abentley hit this then if he tried to disable it in hardware drivers
<james_w> Keybuk: I've been seeing parts of that. "pycentral pkginstall foo" is the critical missing bit it seems
<Keybuk> james_w: it's missing from every single package then
<james_w> not for me
<Keybuk> because I can replicate it by picking on just about everything
<Keybuk> >>> import fstab
<Keybuk> Traceback (most recent call last):
<Keybuk>   File "<stdin>", line 1, in <module>
<Keybuk> ImportError: No module named fstab
<james_w> python-zopeinterface and python-twisted-core on two machines for me
<Keybuk> cjwatson: any thoughts?
<mvo> Keybuk: that sounds like something for doko
<mvo> Keybuk: but if you mail the logs to me /var/log/dist-upgrade/* I can have a look
<Keybuk> mvo: I didn't use the dist-upgrader
<mvo> Keybuk: apt-get dist-upgrade? it should have /var/log/apt/term.log
<mvo> but then our python tools tend to not write out a lot of useful output :/
<Keybuk> mvo: yeah, can't see *anything* in that
<tkamppeter> pitti, I did not try the new backend yet. Could you try it?
<Keybuk> interestingly, none of the apparently affected packages were upgraded in the dist-upgrade
<pitti> tkamppeter: as I said, I can't reproduce it, but I can test it, of course
<pitti> tkamppeter: that's the one from 1.4?
<Keybuk> oh, no, python-tz and python-openid both were - and they're both broken now
<Keybuk> mvo: the dist-upgrader sadly never seems to work on my desktop
<Keybuk> I install too many bits from PPAs, and by-hand backports from jaunty, and stuff :p
<mvo> Keybuk: in what way does it not work?
<mvo> Keybuk: oh, ok
<Keybuk> mvo: this time it wanted to uninstall just about every package included ubuntu-minimal <g>
<mvo> Keybuk: *urgh* if you still have the logs of that (in /var/log/dist-upgrade/) then please mail it to me, it should not do that
<Keybuk> mvo: looking at why, it's perfectly reasonable that it wanted to do that
<Keybuk> I had a custom one installed that conflicted a few things :p
 * Keybuk has later version of upstart on here, which has different packages
<Stskeeps> ~
<Stskeeps> (ignore)
<cjwatson> Keybuk: did the new python package get configured?
<cjwatson> Keybuk: I think that currently it calls the rtupdate hooks, which are what are supposed to symlink modules around for the new version
<Ng> is there any particular disadvantage in defaulting to having lots of loop devices available? we seem to default to 8, the maximum the loop module will create is 256
<njpatel> (asking here in case it's a ubuntu thing) my compiz-enabled desktop switches workspaces whenever I scroll on an empty part of a gtkwindow i.e. the status area of the nautilus window
<njpatel> i can't remember this being the case in intrepid, and it's really annoying
<davidm> pitti, I ran the killall gnome-settings-daemon and got 3 I could not kill should I still try running the extra command??
<cjwatson> Ng: does making lots of them available cause all the device nodes to be created at boot?
<cjwatson> Ng: in any case I thought that nowadays new device nodes got autocreated somehow (I forget how)
<Ng> cjwatson: if I reload the module with max_loop=256 I immediately get 256 /dev/loopN devices
<Ng> I was just playing with something that uses a lot of loops and it complained that it couldn't get any more, but I'm doing horrible kernel mismatching (jaunty userspace, hardy kernel), so maybe that is preventing any automagic creation
<Ng> cjwatson: hrm, even with jaunty at both ends of the chain I don't see loop auto-creation (tested with for i in $(seq 1 10) ; do mkdir /tmp/lala$i ; sudo mount -o loop ubuntu-9.04-beta-desktop-i386.iso /tmp/lala$i ; done)
<davidm> pitti, bug updated
<pitti> davidm: yes, please; do you have so many other running user sessions?
<pitti> davidm: thanks
<davidm> pitti, I have my user logged on "davidm" and guest and I ran the bit's in guest.  Though I'm happy to log out of guest and only work in the "davidm" instance.
<cjwatson> Ng: problem with max_loop=256 then is that it will have a noticeable effect on boot time. We saw this with tty devices too
<cjwatson> Ng: I forget how device creation is supposed to happen, I thought losetup did it
<pitti> davidm: if you do "ps ux|grep gnome-settings", do you have a running daemon?
<pitti> davidm: either you have one which is unkillable, or you have none, and there's a d-bus problem
<pitti> davidm: I have a meeting in 2, so I'll continue the Q&A tomorrow
<davidm> I have 4
<seb128> pitti: what is the issue?
<davidm> See screenshot attached to bug
<pitti> seb128: bug 352362
<ubottu> Launchpad bug 352362 in gnome-settings-daemon "After upgrade to Jaunty Beta my machine shows different problems, , random high load, no meta key, etc." [Undecided,Incomplete] https://launchpad.net/bugs/352362
<pitti> davidm: all running as you?
<cjwatson> Ng: at any rate, if you create the device nodes manually, it should work
<davidm> yes
<davidm> all as davidm according to ps ux
<davidm> I can attach another screenshot if you like
<Ng> cjwatson: ok
<Keybuk> cjwatson: dpkg --configure -a does nothing
<davidm> pitti,  Now have 3
<davidm> Attaching a screen shot from davidm
<pitti> davidm: screenshot> ps ux output should do
<davidm> pitti, attached to bug now
<pitti> davidm: will you be in SF next week, @LF summit?
<abentley> superm1: I think at that point dpkg hadn't completed.  I was dumb enough to run the installer in a vnc server.
<superm1> abentley, okay well then for the common case - that someone removes it from jockey it does the right thing
<davidm> pitti, Yes I will be arriving on Sunday night
<davidm> I'll be at celf and LF summit
<abentley> superm1: No, I couldn't get to jockey initially.  Only after I'd apt-get-remove-purged the video driver could I even try jockey.
<pitti> davidm: rock, I'll see you there; if I don't figure it out tomorrow, I can hack on your machine as a last resort?
<davidm> I can carry my HD and laptop so you can indeed hack.
<abentley> superm1: Sorry to change my story.  It was late...
<davidm> I'm going to go out a buy a new HD so I can get working on my presentation for CELF that I have to present.
<pitti> ArneGoetje: you have an 855?
<pitti> bryce: ^
<pitti> ArneGoetje: I read in the bug report that uxa and some other xorg.conf option would make it work
<superm1> abentley, okay well still things are working as expected currently then.  I don't believe there is any way to make the experience better since AMD is requiring their own libdri and libglx
<ArneGoetje> pitti: I do
<ArneGoetje> pitti: and I'm running uxa
<pitti> davidm: urgh, 3 g-s-d's is certainly wrong
<abentley> superm1: Well, there are heroic measures-- if fglrx is installed, remove it on upgrade, try reinstalling it, and if it doesn't work fall back to the OS drivers.
<abentley> superm1: Even just removing it and telling the user they can try reinstalling it would be better, because bulletproof X would at least give them VESA.
<davidm> Yes, I gather that, I have no idea how that happens, it's only from the upgrade, everything is working correctly from the liveCD beta, which is really confusing to me.
<pitti> ArneGoetje: nice
<pitti> bryce: ScottK said that i865 "just works", and if we could make the 855 use uxa, and disable dri on the 845, we'd at least have a non-breaking upgrade; is that possible?
<ArneGoetje> pitti: no other config options set, just uxa.
<bryce> pitti: one of the big problems I'm having trying to get 304871 closed is that the original reporter does not respond
<pitti> bryce: well, if we have some other people with similar hw which can reproduce the bug and test the fix, that should be good enough?
<bryce> so through the bug there have been multiple solutions proposed, some of which solve the issue for certain people, but not others.  The original reporter never responds, so we never know if one of them would solve his problem.
<pitti> in that context, the original reporter is proably not "more" special than the other responders with the same chipset?
<bryce> pitti: so the point we're at now is chasing the lowest common denominator, which is looking like "nuke them all from orbit and let God sort them out"
<pitti> heh
<bryce> i.e. disable all features on 8xx
<pitti> bryce: with xx == {45,55}?
<bryce> which obviously is a poor solution, and is going to generate all manner of regression reports later
<pitti> or do you have reports about 865 failures as well?
<bryce> 865 too
<pitti> ugh
<pablo__> is ppp_generic module missing in jaunty ? i googled about, and i got this http://archives.free.net.ph/message/20081226.221035.2367e95e.de.html
<bryce> the problem is that given 3 people with 845, we get 3 completely different results
<pablo__> i need it to use a kernel firmware to connect ppp
<pitti> bryce: that's as diverse with 855 as well?
<cjwatson> pablo__: it's built into the kernel - you don't need a module
<bryce> pitti: apparently.
<bryce> pitti: normally, if this wasn't a targeted bug, I'd close the bug as expired since we've not heard from the original reporter, and ask others to file new bugs.
<pablo__> [cjwatson] i do not know very much, but i had a script that used that before. may be it was needed before
<Ng> bryce: fwiw I didn't see that bug on a thinkpad X40 (855GM)
<pablo__> well, im sure it was
<cjwatson> pablo__: yes, it used to be
<Ng> bryce: but afaics there is quite some variation between machines with seemingly identical intel graphics chips
<pablo__> i realized when i got an error message
<pablo__> [cjwatson] i try to know why my connection script does not work
<pablo__> i can connect without some workarrounds
<pitti> bryce: given how tangled it became, it's probably a good idea to split it up by hardware category anyway?
<pablo__> i have a usb connection
<bryce> Ng: yeah 855 seems in better shape; it's 845/865 where we have more reporters of this particular problem
<allquixotic> Does anyone know if you need to sign up for the packaging training sessions or whether you can just join the channel at the right time?
<hyperair> allquixotic: just join
<hyperair> allquixotic: or read the logs
<allquixotic> hyperair: Thanks :)
<hyperair> allquixotic: np
<bryce> pitti: okay.  The bug was opened against 845 originally, whereas all recent comments of "still problems" are from 865 users
<bryce> pitti: there are also some 855 users who say the issue is fixed by use of the Legacy3D option (for which we have a patch)
<bryce> pitti: so I think I'll put my patch in as the fix for 845, and split out the 865 and 855 issues to separate bugs.
<bryce> then we can finally get this one closed
<cjwatson> Caesar: what do you think of bug 74164?
<ubottu> Launchpad bug 74164 in dhcp3 "Request ntp-servers by default" [Wishlist,Confirmed] https://launchpad.net/bugs/74164
<cjwatson> Caesar: oh, hmm, that's Debian bug 407667, so it looks unintentional that this is missing
<ubottu> Debian bug 407667 in dhcp3-client "dhclient not requesting ntp-servers by default" [Unknown,Closed] http://bugs.debian.org/407667
<telexicon> whats up with this lintian warning whenever i build a package: debian-changelog-file-is-a-symlink ?
<cjwatson> telexicon: ... well, apparently your debian/changelog file is a symlink :-)
<cjwatson> it should be an ordinary file
<telexicon> cjwatson, well yeah i got that part :p but i didnt make it a symlink
<telexicon> its a multibinary from one source package and it symlinks the docs to the main dependency
<cjwatson> run lintian-info and copy and paste the line from lintian's output into it
<telexicon> CDBS does it automatically
<Laney> yeah, that's an ubuntu CDBS change
<Laney> for space-saving reasons - you can ignore it
<cjwatson> oh, that. well, it isn't your bug directly so you can ignore it. I think perhaps we ought not to do that for the changelog file though
<cjwatson> not sure
<telexicon> what about, not symlinking copyright and changelog
<telexicon> and then symlinking everything else
<cjwatson> you could do that in your package
<cjwatson> I'm not sure why cdbs doesn't do that, but cdbs does not stop you controlling the contents of your own package
<telexicon> yeah thats true, id just have to go look all that up
<cjwatson> actually, it would be better if cdbs symlinked the directories rather than the individual files, but IIRC there was some reason why that was problematic
<telexicon> cjwatson, yeah thats even what lintian suggests
<LordKow> i cant help but notice that http://brainstorm.ubuntu.com/idea/64/ pk ideas were set for jaunty but obviously are not happening.
<telexicon> is the goal to have all the packages use cdbs?
<Mithrandir> no
<blueyed> pitti: virtualbox-ose for amd64 on Hardy is still in the NEW queue: https://launchpad.net/ubuntu/hardy/+queue?queue_state=0&queue_text=
<jtholmes> cjwatson, i made the change to usersetup.py in my release and it worked fine thanks for the info BTW always to glad to help out
<directhex> pitti, are you arranging desktop related things at UDS?
<lool> cjwatson: Just a note that I'm pushing glibc_2.9-4ubuntu5.dsc which I've put up for review; it's the same as you reviewed earlier + a release commit
<lool> cjwatson: NCommander and myself tested; it would first segfault for NCommander, but he had unrelated issues on the system, his reinstalled system would work, and it worked fine on my babbage
<BUGabundo> anyone else working on bug 304871 ?
<ubottu> Launchpad bug 304871 in xserver-xorg-video-intel "[i845G] Fatal server error: Couldn't bind memory for BO front buffer (Jaunty)" [High,In progress] https://launchpad.net/bugs/304871
<YokoZar> http://www.yelp.com/biz/ubuntu-restaurant-and-yoga-studio-napa
<mvo> pitti: just fyi, I saw corrupted attachments for apport reported bugs for bug #352134 and #350866
<ubottu> Launchpad bug 352134 in r-base "package r-base-core 2.8.1-1 failed to install/upgrade: " [Undecided,New] https://launchpad.net/bugs/352134
<ubottu> Launchpad bug 350866 in python-defaults "package python 2.6.1-0ubuntu7 failed to install/upgrade: " [Undecided,Incomplete] https://launchpad.net/bugs/350866
<BUGabundo> can any one tell me how to use DRI ?
<cody-somerville> Folks in #ubuntu probably can :)
<BUGabundo> cody-somerville: never mind! i re-read the bug and copied a xorg from there
<slangasek> calc: what's the plan for OpenOffice.org on sparc?  Are you going to try lowering the optimization level as cjwatson suggested, or are we going to drop it?
<slangasek> calc: if the first, that should happen very soon; if the latter, I'd prefer it happen soon anyway so I can get the stale deps off the component-mismatches report :)
<slangasek> calc: ah, actually, the most recent OOo failure on sparc is just a plain old syntax error in the code, somehow...
<calc> slangasek: hmm, looking
<calc> slangasek: yea it was the previous upload that ICEd apparently, but the log is no longer available for it
<slangasek> right - but now we have a syntax bug, surely that's easier to fix? :)
<calc> probably once that is fixed it will just ICE again but i will look at it
<calc> it pretty much NEVER builds on sparc regardless of what is done :\
<calc> at one point i just had it disabled entirely on sparc but i apparently lost that on merge
<calc> i will check it out for my next upload
<slangasek> calc: ok, cool.  is the next upload scheduled?
<calc> should be in a few days
<calc> i'm waiting until at least the next LP rollout to fix an issue that caused the ppc build to fail
<calc> aiui that is tomorrow
<slangasek> ok
<slangasek> pitti: bug #345531 needs some more attention from someone well-versed in hal
<slangasek> (subscribed you)
<ubottu> Error: Could not parse data returned by Launchpad: The read operation timed out (https://launchpad.net/bugs/345531/+text)
<cjwatson> jtholmes: cool, thanks
<cjwatson> lool: thanks, pulled
<awe> brianchidester: one more favor to ask..
<brianchidester> awe:  go for it
<awe> ( just realized i'm in the wrong room )...doh
<brianchidester> awe: haha
<jtholmes> cjwatson, sure i actually want to get a little more involved but have to learn where things r first
<BUGabundo> seb128: bug 352681
<ubottu> Launchpad bug 352681 in nautilus "deleted files are not shown on Trash applet" [Undecided,New] https://launchpad.net/bugs/352681
<BUGabundo> some guys on +1 just found out that files are not being shown on the trash applet
<BUGabundo> for a sec i though they were being really deleted
<BUGabundo> but no... they are on .local/share/Trash
<seb128> BUGabundo: that's the directory the trash shows
<jtholmes> cjwatson, i plan to join the QA meeting tomorrow, i really want to talk about a more structured regression testing environment so we can hopefully reduce bugs up front
<BUGabundo> seb128: yes, but the trash applet, after clicked is Empty
<BUGabundo> and even the applet is not updated with the Full icon
<seb128> BUGabundo: what about the trash location in nautilus?
<BUGabundo> it wont open
<BUGabundo> when typed in nautilus trash:///
<seb128> your installation is screwed
<BUGabundo> liveusb
<BUGabundo> from today
<BUGabundo> and 2 days ago
<BUGabundo> not my system
<seb128> could be liveusb specific
<BUGabundo> not me to 1st complain
<seb128> obviously that works on a normal system
<seb128> we would have noticed otherwise
<BUGabundo> maco is now debuging with other users on +1
<BUGabundo> maco: cn u confirm?
<seb128> well it's easy, gvfsd-trash is a gvfs backend
<seb128> gvfs-ls trash:
<maco> huh?
<maco> oh
<maco> seb128: soemone with an installed system first reported it
<BUGabundo> and i just tested on 2 dailys images
<seb128> gvfs-ls trash:
<seb128> run that
<maco> BUGabundo's just the reproducer
<seb128> what does it list
<BUGabundo> nothing
<BUGabundo> but theres a folder in /home/ubuntu/.local/share/Trash/files/ef
<maco> mine is not empty, but my nautilus is also not at the latest version
<maco> perhaps its the most recent nautilus update?
<BUGabundo> i dont know
<BUGabundo> seb128 will now that better
<BUGabundo> my system is broken (wont reach gdm) so i cant test tehre
<BUGabundo> just running liveusb to test some stuff and installing a new test machice
<BUGabundo> well dinner time for me
<BUGabundo> i'll look at it tomorrow
<seb128> maco: iit's working fine on all my boxes and we got no bug until now
<maco> seb128: im installing updates to see if the workingness of my system changes after updates
<maco> seb128: empathy doesnt use the indicator applet yet, right?
<seb128> no
<johanbr> maco: https://bugs.launchpad.net/bugs/340180
<ubottu> Ubuntu bug 340180 in null "Please provide Empathy support" [Undecided,New]
<maco> i'm trying to make a list of apps that dont have indicator applet support but should
<seb128> all the IRC and IM clients ;-)
<seb128> and email clients
<seb128> only evolution and pidgin use it now
<maco> er..shouldnt that bug be on "Empathy (Ubuntu)" not just "Empathy"?
<maco> Ryan added it to Gwibber
<seb128> depend if you wish that upstream add that feature or it to be added by ubuntu
<maco> dont think that's packaged yet though
<maco> i thought since it's an ubuntu-specific experiment, it would go in the Ubuntu package
<seb128> it could
<seb128> you can open an ubuntu task for sure
<tedg> maco: Liferea too.
<maco> tedg: for the "52 million unread items" messages?
<tedg> maco: I practice RSS-zero ;)
<tedg> maco: Also, atleast for mail, we've been doing an "unviewed" count instead of "unread."  Kinda like how the liferea status icon works now.
<maco> tedg: i havent logged into gnome in a week or two, so i'm missing some context
<tedg> maco: Basically for Evolution we're showing the count of messages that you have gotten since the last time your read an e-mail in Evolution.
<maco> instead of the total?
<tedg> maco: Correct.  Figuring that most people don't do inbox-zero, so if we required it, we'd have no users :)
<maco> hehe
<maco> yeah im always going "ok..i had 235 last time i looked...i think...so i got....127 new?"
<tedg> Yeah, I've just given up counting.
<maco> ah! AFK meeting....late...bah
<maco> bye
#ubuntu-devel 2009-04-01
<ebroder> Could someone on motu retarget bug 343036 as not fixed in Hardy?
<ubottu> Launchpad bug 343036 in openafs "openafs-modules fails to build on 2.6.16.29-xenU" [Undecided,Fix committed] https://launchpad.net/bugs/343036
<mistya> hi there! I just installed ubuntu. it's fantastic! Thank's dev. Good Job
<jtholmes> can someone tell me where the name of the file containing  partman/filter_mounted is
<TheMuso> ARGH!
<TheMuso> cUploaded a test ppa to Ubuntu!! :S
<robert_ancell> does anyone know how to disable notify-osd?
<TheMuso> any archive admins around who could reject my upload? :S
<TheMuso> gah too late
<stgraber> TheMuso: looks that way :) Was a bit surprised seeing the changelog for that pulseaudio.
<TheMuso> stgraber: yeah. Need to default my dput config to my ppa from now on.
<stgraber> were you planning to get this one in Jaunty anyway ? might be a bit difficult to revert to the old one otherwise ...
<TheMuso> stgraber: no I wasn't, thats the damn problem!
<stgraber> ok, so pulse in jaunty will have a funny version number then :) as Jaunty's 0.9.14 will need to have a version number of at least 0.9.15
<TheMuso> Right
 * TheMuso feels really stupid right now
 * stgraber almost did it a few times .. that's the usual problem when maintaining a PPA with backports, another with test versions and also having the rights to upload to main (/me should also default to PPA ...)
<TheMuso> ok I rushed to do an epoch to fix it. Gah I'm clumsy today
<pwnguin> does pulseaudio sync from debian often anyways?
<TheMuso> pwnguin: We merge, but we haven't synced ever afaik.
<pwnguin> fun.
<TheMuso> pwnguin: Yeah.
<pwnguin> wacom is in a situation where i think someone bumped the epoch
<pwnguin> the results are unfun
<TheMuso> Well this is punishment for my lax in concentration and stupidity.
<TheMuso> heh its not all bad, the ppa version ended up as dependency wait.
 * TheMuso reckons soyuz should reject uploads with ppa in the version string that get accidentally uploaded to ubuntu proper.
<pwnguin> you're now at the blame stage of grieving
<TheMuso> pwnguin: Probably, but I still think its a good idea.
<TheMuso> Or... Depending on what can be done with the pre upload command in dput, have a check done there.
<Caesar> cjwatson: re those bugs
<Caesar> Yeah, I can fix it in Debian
<Caesar> I need to give the DHCP package a major overhaul
<Hobbsee> mmm...nice new irssi
<balarka> hello
<dholbach> good morning
<balarka> dholbach, good morning
<dholbach> hi balarka
<balarka> dholbach, hi!
<balarka> dholbach, i am new to ubuntu devel group
<balarka> dholbach, i am curious to know where to start in helping the community with my code
<balarka> dholbach, can you help me?
<dholbach> so you wrote some code and want it included in Ubuntu?
<balarka> nope
<balarka> just want to contribute
<balarka> to existing projects
<dholbach> ah excellent
<balarka> or new projects
<balarka> anything is fine
<dholbach> check out https://wiki.ubuntu.com/MOTU/GettingStarted then
<dholbach> it contains links to docs of our processes, our tools and where to find stuff to work on
<dholbach> I hope you don't mind some reading in the beginning :-)
<balarka> actually i went through most of them
<balarka> sure sure..
<balarka> no probelm
<dholbach> just ask your questions in #ubuntu-motu about packaging stuff
<dholbach> we have a bunch of helpful people in there
<dholbach> we also have some https://wiki.ubuntu.com/Packaging/Training sessions coming up soon
<balarka> ooh woow
<balarka> i came to know from the docs that..
<balarka> involvement starts from packaging?
<balarka> is that correct
<dholbach> packaging is basically "learning the tools"
<balarka> ooh
<dholbach> like how do I upgrade a package to a new upstream version or how do I get a patch included
<balarka> ooh
<dholbach> or what does it mean if "build fails due to XYZ" or "package is uninstallable for some reason"
<balarka> so when can someone involve writing code
<dholbach> there's lots of bug reports where just a bit of hacking (and knowing how to integrate it into the source package) is very very useful
<balarka> ooh
<balarka> got it
<dholbach> rock on! :)
<balarka> i am interested on java projects..
<balarka> you have any idea
<balarka> whom i need to contact
<balarka> i mean which channel
<dholbach> try hanging out in #ubuntu-java and ask the folks in there if they have open projects or open bugs that need resolving
<dholbach> ttx, doko and slytherin are people you could contact
<dtchen> e.g., updating eclipse
<balarka> ooh
<balarka> so which are do you work.?
<balarka> just curious to know..
<dholbach> "so which are do you work.?" - what do you mean?
<balarka> i am sorry
<balarka> which area do you work
<balarka> is my question
<balarka> in ubuntu
<dholbach> little bits of everything, I used to work on desktop stuff, but now I'm more generally trying to make it as fun and straight-forward as possible to be involved with Ubuntu Development :)
<balarka> woow
<balarka> thats exciting..
<balarka> so you are official devel for ubuntu is it?
<Amaranth> dholbach is one of the four horsemen :P
<balarka> oh cool
<dholbach> if you mean an approved member of the Ubuntu development team, than yes
<balarka> amazing..
<dholbach> s/than/then
<balarka> i seriously feel so glad being able to talk to a core ubuntu stud
<balarka> excellent!
<dholbach> haha
<balarka> nope.. i mean it.. i never come across anyone till now who works with devel of ubuntu
<balarka> so i am elated now
<balarka> :)
<pitti> Good morning
<Amaranth> balarka: This channel is full of such people :)
<balarka> hmm..
<pitti> bryce: split 8x5 issues> thanks; this will make it easier to track
<Amaranth> balarka: And with a little work you could be one of those people too
<balarka> i never knew that.. i was diverted to this by  a friend
<dholbach> balarka: you should definitely hang out in the Packaging Training sessions I talked about above
<balarka> coool.. i would dream to be
<balarka> dholbach, for sure..
<dholbach> rock and roll
<balarka> i am going thru the page now
<dholbach> take your time :)
<pitti> directhex: I'm certainly part of the desktop track planning, yes
<balarka> dholbach, so its gonna come this first thursday right?
<dholbach> yep
<balarka> cool
<pitti> slangasek: 345531> I'll have a look, and comment in the bug
<balarka> dholbach,  there is no one responding on #ubuntu-java channel
<balarka> dholbach, so what activities does packagin involve?
<balarka> dholbach, is that just getting dependencies solved, compiling.. makefile stuff?
<dholbach> balarka: just be patient, some of them might be sleeping and waking up later
<balarka> dholbach, or a lot more involved
<balarka> dholbach, sure.. hahah
<dholbach> balarka: check out the packaging guide, it's going to make things a lot clearer
<balarka> dholbach, did  you mean this one: https://wiki.ubuntu.com/PackagingGuide/Complete
<dholbach> yep
<balarka> cool
<balarka> will go thru it
<dholbach> super
<balarka> so will join the training channel on april 2nd then
<balarka> dholbach, and can meet you there with some questions.. after reading this link
<balarka> :)
<dholbach> balarka: if it's specific packaging stuff, just ask in #ubuntu-motu
<balarka> oh ok
<dholbach> also the other stuff on MOTU/GettingStarted is going to be interesting
<balarka> not much package specific
<balarka> am a new commer to open source development
<balarka> so wont have anything in depth kind of
<dholbach> that's great :-)
<balarka> but would certainly want to start my journey in open source
<dholbach> super
<balarka> yeah.. i am pretty excited about it
<dholbach> play around with the stuff on PackagingGuide/Recipes too
<dholbach> so you get an idea of how it all works
<balarka> perfect
<balarka> that should be nice resouces for a good start i guess
<directhex> pitti, can you avoid scheduling anything where mono might be discussed on the friday?
<pitti> directhex: it's a little too early for such request, scheduling will happen start of May or so
<pitti> directhex: you'll just mark yourself as not present on Friday, then we'll figure that out automatically
<directhex> pitti, already marked. i was just told to make sure the desktop team people were aware. so consider yourself aware!
<pitti> asac: hm, someone reopened bug 346835; do you think the remaining case is still RC? should it perhaps be split into a separate bug?
<ubottu> Launchpad bug 346835 in network-manager "MASTER - modems not detected - udev prober broken (Was: Huawei e169 doesn't connect + Globetrotter 3G+ card not recognized anymore)" [Critical,In progress] https://launchpad.net/bugs/346835
<slangasek> TheMuso: you've seen that the latest linux-ports FTBFS on hppa?
<slangasek> lool, NCommander, ogra: does texlive-bin still need the build-dep on g++-4.2?
<pitti> Riddell: do you know anyone working on bug 280762? seems this is not a jaunty regression, and it doesn't have an assignee
<ubottu> Launchpad bug 280762 in knetworkmanager "knetworkmanager under kde4 doesn't recognize the static IP connections that I have configured. " [High,Confirmed] https://launchpad.net/bugs/280762
<robert_ancell> what was the name of the program that would start a x server in a window?
<dholbach> robert_ancell: xnest something?
<robert_ancell> dholbach: thanks
<slangasek> cjwatson: do you know if there's an MIR for micro-evtd-udeb?
<dholbach> bryce and tjaalton: do you think you can take a look at bug 352335? it makes the package build again, but I dunno if all the quilt/xfsbs mumbo-jumbo is OK as it is
<ubottu> Launchpad bug 352335 in xserver-xorg-input-acecad "FTBFS due to xserver-1.6" [High,Confirmed] https://launchpad.net/bugs/352335
<tjaalton> dholbach: it could be synced from experimental
<dholbach> tjaalton: sounds good
<tjaalton> acecad/aiptek/fpit
<tjaalton> elographics/penmount/void once they are uploaded
<tjaalton> new upstream versions though, but mostly due to build issues
<tjaalton> so low/no risk
<TheMuso> slangasek: Yes, and I am pretty sure I know why, and I don't see a need to fix it until I have to rebase on another mainline jaunty upload, or someone wants it, or there is no more other linux-ports work needed
<slangasek> TheMuso: ah; it leaves NBS a mess in the meantime :(
<TheMuso> slangasek: Right, I can have a fix pushed in a matter of 5-10 mins if you'd like.
<slangasek> would be appreciated
<TheMuso> ok
<pitti> bryce: 322646> *hug* great!
<TheMuso> slangasek: uploaded
<bryce> pitti: fix uploaded
<asac> pitti: closed it again
<asac> pitti: usually reporters cannot read the bug title.
<StevenK> asac: The icon theme with the green NM icons is at http://www.gnome-look.org/content/show.php/GNOME-colors?content=82562
<StevenK> asac: If you look at the 3 previews, it's the bottom most right icon in all of them
<asac> StevenK: ah ok. cool
<cjwatson> slangasek: micro-evtd-udeb> I don't know - I could have sworn there was one at one point but couldn't see one last time I looked
<cjwatson> lool: ^- do you know?
<cjwatson> jtholmes: init.d/parted in the partman-base source package, but I'm just in the process of rewriting it right now to deal with bug 347916 ...
<ubottu> Launchpad bug 347916 in ubuntu-release-notes "Warns user about the fact that the installation medium is mounted" [Undecided,Fix committed] https://launchpad.net/bugs/347916
<cjwatson> TheMuso: an epoch for pulseaudio? erk. The right answer would have been 0.9.15~test7+really0.9.14-0ubuntu16 :-(
<cjwatson> TheMuso: now merge-o-matic will be permanently broken
<cjwatson> (or, well, will never show pulseaudio)
<pitti> asac: thanks
<pitti> bryce: rocking, thanks
<tkamppeter> pitti, bug 348316 seems to be a kernel issue. The users with problems have them with any backend: HAL, HPLIP, USB, unpatched USB ... The libusb-based USB backend I have in a modified CUPS package on my PPA now, but did not get any answer on that. Seems that this is really a Kernel problem ...
<ubottu> Launchpad bug 348316 in cups "Printer (HWModel Name) May Not Be Connected" [High,Incomplete] https://launchpad.net/bugs/348316
<pitti> tkamppeter: do you have a machine where this happens?
<pitti> tkamppeter: or anyone who could do an strace, or other helpful information?
<pitti> slangasek: bad news; we can't add gnome-user-guide-* to language-support-*, that's bad for Kubuntu (bug 352036); I'll have to add them to language-pack-gnome-*, which means that they'll get back on the CD
<ubottu> Launchpad bug 352036 in language-support-translations-en "language-support-translations-* depends on gnome-user-guide-*" [High,In progress] https://launchpad.net/bugs/352036
<pitti> slangasek: I don't see another way right now
<seb128> pitti: can't we use conditional depends?
<pitti> it would require "implication" depends
<seb128> what do you mean?
<pitti> i. e. "depends on gnome-user-guide-de if yelp is installed" or so
<pitti> seb128: what is a conditional dependency?
<cjwatson> seb128: no such facility
<cjwatson> pitti: not all of them will go back on the CD if you add them to language-pack-gnome-* - I was looking at this when we were talking about it on this channel yesterday
<tkamppeter> pitti, my second Jaunty box (i386) has also no problem to print via USB.
<cjwatson> pitti: I think we'll still have saved several megabytes
<seb128> pitti: well, "documentation | some_package_not_installed_in_ubuntu_but_$flavors_not_wanting_it"
<seb128> pitti: similar to the type-handling "depends | not-gnu" hacks
<cjwatson> the best long-term answer for this is to get rid of language-support-* entirely, use special fields in Packages instead, and teach tools to use that
<pitti> cjwatson: right, but for those that we ship on CDs
<pitti> seb128: that would break for boxes which have both installed, thuogh
<seb128> pitti: use a dummy package which is shipped on CDs only?
<cjwatson> seb128: at this point in jaunty, we should play safe and use techniques that we know to work
<pitti> cjwatson: for this particular case, I'd like bug 123020 to get implemented
<ubottu> Launchpad bug 123020 in pkgbinarymangler "support shipping verbatim files in the exported tarballs" [Wishlist,Triaged] https://launchpad.net/bugs/123020
<pitti> (in soyuz)
<cjwatson> when you get to the point of inventing dummy packages shipped only on CDs, that's an excellent sign that the discussion should have been had several months ago ;-)
<pitti> so that we can ship help translations, etc. directly in language-pack-*
<apachelogger_> mvo: can we make qt-langauage-selector not install language-support-translations-$iso? ... that metpackage depends on localization of which only 1/4 are useful on a default kubuntu, also that package now depends on gnome-user-guide-$iso, which pulls in half the gnome stack
<tkamppeter> pitti, any idea how to strace the CUPS backend when CUPS is executing a print job?
<cjwatson> pitti: well, OK, but the general problem still remains for language-support-*
<pitti> tkamppeter: sudo strace -o /tmp/trace -fv <pid>
<pitti> cjwatson: right
<cjwatson> pitti: (and note that that solution is no different in terms of space usage than simply having language-pack-gnome-* depend on things)
<pitti> cjwatson: right, but structurally easier
<pitti> cjwatson, seb128: I updated bug 352036 with the current plan; does that look okay to you?
<ubottu> Launchpad bug 352036 in language-support-translations-en "language-support-translations-* depends on gnome-user-guide-*" [High,In progress] https://launchpad.net/bugs/352036
<cjwatson> pitti: what I'd like to see is something like Package: openoffice.org-thesaurus-de Language: de/writing/gnome or similar
<cjwatson> seb128: yes, I think so
<cjwatson> oops
<cjwatson> pitti: ^-
<pitti> thanks
<cjwatson> basically this is working around the lack of language-support-gnome-translations-* but I'm *really* not keen on even more metapackages :-)
<pitti> I tried to avoid even bringing up this option..
<pitti> not only would it create even more package clutter, but also need installer and language-selector changes, etc.
<mvo> apachelogger_: sure, if ArneGoetje has no objections, that can be done (but a patch would be good, I'm pretty busy currently)
<cjwatson> right, I'd rather do it properly, with override fields rather than metapackages
<cjwatson> apachelogger_: see bug 352036 which should deal with the worst of the problems currently affecting Kubuntu
<ubottu> Launchpad bug 352036 in language-support-translations-en "language-support-translations-* depends on gnome-user-guide-*" [High,In progress] https://launchpad.net/bugs/352036
<cjwatson> apachelogger_: you came in in the middle of a conversation about it :)
<apachelogger_> oh, neato :)
<cjwatson> apachelogger_: long-term I'd prefer to see something more subtle than having to juggle metapackage requirements (see my comments above)
<apachelogger_> mvo: ok, we can target that change for 9.10 I suppose :)
<cjwatson> theoretically, it might even make sense for language-selector to do something like "install these support packages provided that all their dependencies without Language fields are already installed" - i.e. implement conditional dependencies outside apt
<kagou> Hi
<seb128> lut kagou
<kagou> Hi seb128
<kagou> is it possible to have a new upgrade for language-pack (1:9.04+20090320 for language-pack-gnome-fr-base) is 11 days old
<seb128> kagou: there was a ppa with daily updates, not sure if that's still active though
<seb128> pitti: ^
<pitti> didn't we get new langpacks just yesterday?
<kagou> yeah seb128, https://launchpad.net/ubuntu/+source/language-pack-gnome-fr-base
<pitti> Version: 1:9.04+20090330
<pitti> (language-pack-gnome-fr)
<kagou> I'm testing daily iso to find problem with translations
<cjwatson> indeed, we ship delta language packs rather than revving -base all the time
<kagou> pitti, ok for it but 20090320 for pack-gnome-fr-base
<freinhard> pitti: yes, gnome-user-guide shouldn't be in language-support-translations, that's what we had yesterday
<pitti> kagou: what cjwatson just said
<seb128> kagou: the translations as updated as delta in the non base package as just said
<cjwatson> kagou: the entire *point* of the split between LL-base and LL is that we don't have to update -base all the time
<seb128> kagou: ie you have translations dating from yesterday in jaunty
<seb128> or 2 days ago rather
<kagou> ok seb128 so we have some problems to investigate with translation team
<cjwatson> kagou: is it something in the installer? installer translations are updated by hand
<kagou> cjwatson, indeed
<cjwatson> kagou: which strings?
<apachelogger_> cjwatson: ultimately language-selector probably should have a list of applications (that use individual language packages), and only install the appropriate language packages if the applications are actually installed. that way $user always gets the right amount of localization, which is kind of difficult when using metapackages anyway
<cjwatson> apachelogger_: that information belongs in special fields in the override file, not hardcoded in language-selector, IMO
<cjwatson> apachelogger: that information belongs in special fields in the override file, not hardcoded in language-selector, IMO
<kagou> cjwatson, if you reed french ;) https://lists.ubuntu.com/archives/ubuntu-fr-l10n/2009-April/002918.html
<cjwatson> kagou: sufficiently to make that out, thanks
<kagou> your welcome cjwatson
<apachelogger> cjwatson: yeah, you are probably right on that :)
 * directhex speaks to travel agent
<directhex> this UDS stuff is rather exciting, really
<jpds> directhex: 'tis only just the beginning ;-)
 * Laney cuts you all
<directhex> jpds, yeah, but i've never been to a conference which wasn't mostly full of sales pitches
<StevenK> directhex: You'll be at UDS?
<directhex> StevenK, i will indeed
<StevenK> directhex: Awesome!
<biberao> hi
<biberao> pitti, you there?
<pitti> biberao: hi
<biberao> i was sent to you
<biberao> to ask 2 questions related to the guest user
<biberao> can i?
<pitti> biberao: just ask :)
<biberao> ok
<directhex> StevenK, i will be departing a day early though
<biberao> how can i not allow Guest User to login on gdm and remove it from fast user switch applet
<biberao> ?
<pitti> biberao: the user cannot log in through gdm by default
<pitti> "guest user", I mean
<biberao> pitti, but its logging there
<biberao> i dont know how
<pitti> biberao: logging?
<biberao> sorry my english
<biberao> :P
<biberao> it was logged in
<pitti> biberao: if you want to remove it from fusa, just uninstall gdm-guest-session to disable the functinoality completely
<directhex> oh, that's one thing that bugs me about the Guest User. i keep getting a contentless mythbuntu desktop, even though mydefault gdm session is gnome
<ogra> add some content then
<ogra> :P
<directhex> ogra, i'd prefer an ubuntu desktop
<biberao> ok removed gdm-guest-session
<pitti> directhex: please file a bug
<biberao> pitti, do you know why it lets log in
<biberao> ?
<pitti> biberao: "it" == ?
<pitti> biberao: please describe exactly what you see
<biberao> gdm
<biberao> when i came to the pc
<pitti> biberao: you shouldn't be able to log in as guest in gdm
<biberao> someone logged in with guest
<pitti> only through fusa (or by manually running the script)
<biberao> so it was from fusa
<biberao> so i guess it will be fixed
<biberao> but
<biberao> gdm actually allowed me when i typed guest
<biberao> to log in
<biberao> im going to reboot
<biberao> and test
<biberao> brb
<pitti> ugh
<ogra> pitti, well, what happens if i "adduser guest" :)
<ogra> he probably has an actual guest user
<ogra> or does adduser prevent this
<pitti> aah
<pitti> no, it doesn't
<directhex> hm, definitely have some kind of funny desktop when logging in as guest
<directhex> let me try my VM
<pitti> ArneGoetje: when do you plan the next language-pack-* update for jaunty?
<directhex> oh, my laptop also goes tits up when i log out of the guest session. that's not cool either
<pitti> ArneGoetje: I have the code ready for adding extra langpack recommends, and the list of those
<pitti> ArneGoetje: I wonder if I need to manually update the affected ones now, or just wait for the next langpack upload
<biberao> hi
<biberao> pitti,
<biberao> i think its all fixed now
<pitti> biberao: I see what you meant
<biberao> thanks
<pitti> biberao: do you have a "normal" guest user? what does "id guest" show?
<biberao> how do i check that?
<biberao> :X
<biberao> my guest account came default with ubuntu
<tkamppeter> pitti, thanks. I have added a comment to bug 348316
<ubottu> Launchpad bug 348316 in cups "Printer (HWModel Name) May Not Be Connected" [High,Incomplete] https://launchpad.net/bugs/348316
<ogra> open a terminal, type: id guest
<biberao> damn i need to remember my linux commands :P
<pitti> biberao: as I said, "id guest"
<biberao> sorry i just woke up 30 mins ago
<biberao> i didnt even see the quotes
<biberao> lol
<biberao> pitti, no such user
<pitti> biberao: okay
<pitti> biberao: so in which condition could you log into gdm as "guest"?
<biberao> pitti, i found out that you were right
<biberao> guest cant login unless using fusa
<pitti> right
<pitti> *phew*
<biberao> thanks
<biberao> since im here my pcs are slow
<biberao> and i have problems with usage of my ubuntu, these pcs looked faster with windows ihih
<biberao> should i use blackbox?
<pitti> tkamppeter: ah, great
<biberao> well
<biberao> gtg
<biberao> take care
<directhex> it's definitely using a mythbuntu session. mythfrontend spew in .xsession-errors
<directhex> how does the guest session pick which gdm session to use?
<pitti> ArneGoetje: nevermind, with some shell hackery I'll do a mass reupload of those 20ish language-pack-gnome-*
<pitti> directhex: it just runs /etc/gdm/Xsession
<RicardoPerez> pitti: hi! only one question: the drivers name in restricted-manager shows untranslated. Is it right?
<pitti> RicardoPerez: depends if it is translatable in the first place
<pitti> RicardoPerez: jockey attempts to translate it
<RicardoPerez> pitti: do you know which Launchpad template has the driver names? I'd like to check it...
<pitti> RicardoPerez: "jockey"
<directhex> i have two combined issues which make debugging awkward. my guest user's session seems to use mythbuntu, no matter what is configured in gdmsetup; and logging out as guest causes the screen to lock up with lots of crap on it
<RicardoPerez> pitti: OK, so it seems to be a problem in the tool...
<RicardoPerez> pitti: jockey template is fully translated, including the drivers names...
<RicardoPerez> pitti: for example, restricted manager shows "NVIDIA accelerated graphics driver", instead of "Controlador para tarjetas grÃ¡ficas NVIDIA" in Spanish... The translation is here: https://translations.launchpad.net/ubuntu/jaunty/+source/jockey/+pots/jockey/es/82/+translate since 2008
<RicardoPerez> pitti: I'll submit a bugreport about that, but I don't know against what package. restricted-manager or jockey?
<mvo> apachelogger: it should be relatively easy to fix/change
<pitti> RicardoPerez: ubuntu-bug jockey-gtk
<RicardoPerez> pitti: ok, thanks a lot
<jtholmes> cjwatson, ping  weak password
<jpds> mvo: can you please confirm if bug #18645 has really been fixed?
<ubottu> Launchpad bug 18645 in apt "apt does not handle HTTP redirects" [Wishlist,Confirmed] https://launchpad.net/bugs/18645
<mvo> jpds: that is fixed
<mvo> jpds: I don't think it got a lot of testing yet though, but it should be there now
<jpds> mvo: OK - I'll mark it as fix released, wanted to check with you first.
<mvo> thanks jpds
<pitti> BWAH LP! stop eating my comments when I add an invalid assignee
<jpds> mvo: no problem.
<mdke> mvo: I've encountered a problem with gdebi where it forcibly uninstalls rarian-compat and installs scrollkeeper when I use it to install gnome-user-docs or ubuntu-docs
<mdke> mvo: it's described in comments 13 and 14 of bug 281277
<ubottu> Launchpad bug 281277 in gnome-user-docs "[Intrepid] "Assistive Tool" string shows untranslated" [Undecided,Confirmed] https://launchpad.net/bugs/281277
<mdke> mvo: do you have a bug report for that already or any guidance about what information I need to submit with a new report?
<mvo> mdke: let me try to reproduce
<mdke> mvo: thanks. you should be able to reproduce it with this - http://launchpadlibrarian.net/24562564/ubuntu-docs_9.04.6_all.deb
<mvo> mdke: I just did in a chroot, thanks
<mvo> mdke: if you could file a new bug that would be nice, just paste the information in comment 13, that should be enough
<mdke> mvo: ok, thanks
<mvo> mdke: and please give me the bugnumber when its there :)
<cjwatson> jtholmes: can you pick just one channel for your question and stick to it? :-)
<Riddell> mvo: in bug 348704 how did you do the upgrade?
<ubottu> Launchpad bug 348704 in python-qt4 "/var/lib/python-support/python2.6/dbus/mainloop/qt.so missing after upgrade" [High,Incomplete] https://launchpad.net/bugs/348704
<mvo> Riddell: in a automatic kvm upgrade and in a pbuilder chroot
<mvo> Riddell: but was not able to reproduce :( you can always reproduce it?
<Riddell> mvo: always upgrading using DistUpgrade tool from a fresh intrepid install
<Riddell> but I can't understand what the issue would be, they're just symlinks
<Riddell> there's no postinst script to do something wrong that I can see
<mvo> Riddell: problably a bug in python-support, but I need to reproduce it first
<mdke> mvo: it's bug 353088
<ubottu> Launchpad bug 353088 in gdebi "gdebi forcibly uninstalls rarian-compat" [Undecided,Confirmed] https://launchpad.net/bugs/353088
<cjwatson> kagou: brief summary of your translation problems: 1) fix committed; 2) can't do much about that, firefox translations are in language packs 3) newish string and unfortunately will change again but I'll try to make sure to import translations 4) untranslatable, ubiquity bug 5/6) probably need translation in gparted upstream, or else are due to a missing language pack on the live filesystem 7) partly fixed but the last ...
<ubottu> Bug 5 on http://launchpad.net/bugs/5 is private
<cjwatson> ... translation export I have doesn't have a French translation for the "Use weak password?" title 8) untranslatable, ubiquity bug 9/10) these are weird because those strings seem to be translated in apt and apt's translations aren't stripped for language packs
<ubottu> Launchpad bug 9 in rosetta "Rosetta's po parser is too strict" [Medium,Fix released] https://launchpad.net/bugs/9
<cjwatson> shut up, ubottu
<cjwatson> kagou: 9/10 might be something to do with the locale not being set yet
<seb128> cjwatson: do you need somebody to open bugs about the ubiquity bugs?
<cjwatson> seb128: they have TODO comments in the source already
<seb128> ok
<cjwatson> so don't really need bugs as well
<seb128> likely to be fixed for jaunty?
<seb128> ok, who is our dbus expert there? ;-)
<cjwatson> probably not
<cjwatson> too many RC thngs
<cjwatson> things
<seb128> Keybuk, pitti: would it make sense to let gnome-session start the session bus? I think we have been coming forth and back on that
<seb128> right now gvfs is dbus spawned
<seb128> but the dbus session bus environment has the wrong SSH_* variable
<seb128> ie not the gnome-keyring one
<seb128> which means GNOME doesn't use the keyring in nautilus for example
<pitti> seb128: instead of Xsession.d/?
<Mithrandir> seb128: it actually seems quite right in jaunty, since it then uses my gpg-agent ssh support.
<pitti> seb128: seems quite late for such a change, since it most likely would affect derivatives?
<seb128> Mithrandir: it should be using gnome-keyring
<pitti> Mithrandir: that was fixed yesterday
<pitti> gnupg2 and gpg-agent was accidentally pulled into GNOME
<pitti> (by default)
<pitti> and thus pinentry got used
<Mithrandir> pitti: I'm installing them here manually anyway.
<Mithrandir> since gnome-keyring doesn't seem to talk to my smart card.
<seb128> pitti: could we try to identify gnome session in 75dbus_dbus-launch and not start it in such cases?
<pitti> seb128: if that's possible easily, sure
<pitti> seb128: nautilus uses it for ssh/sftp/smb passwords, etc.?
<seb128> pitti: ssh, my only issue there is that nautilus doesn't use the gnome-keyring ssh agent
<seb128> pitti: the SSH_* point to ssh-agent and not gnome-keyring
<seb128> look to /proc/$(pidof gvfsd)/environ
<pitti> seb128: well, does the Xsession.d script have enough information about which program to run the session as?
<pitti> or is that only determined later?
<seb128> pitti: I'm not sure actually
 * ogra mumbles ... so creating a vfat image from an iso with identical size and then using mcopy to copy the content over gets me a "disk full" error if i use -s with mcopy (recursive copying) ... how can that be
<pitti> mdz: thanks for the apport fixes
<pitti> mdz: would you mind if I move attach_media_build() to general-hooks/ubuntu.py, since it's ubuntu specific?
<mdz> pitti: np, it was a pleasure to do some small programming
<mdz> pitti: not at all; that was what gave me the idea
<mdz> pitti: but I didn't want to commit an architectural change like that without discussing with you
<pitti> I like the idea of general-hooks/ubuntu.py
<mdz> ogra: iso is more space efficient
<ogra> ah
 * ogra tries du on the unpacked iso for determining the needed vfat size ...
<pitti> mdz: BTW, I haven't forgotten about your "apport generic hook?" mail, it's just lower prio
<ArneGoetje> pitti: next full export will happen on 10th.
<pitti> ArneGoetje: ok, thanks; it's all fixed now, anyway
<Unggnu> hi all
<Unggnu> I wanted to make a bug report but I thought it might be better to recheck with your opinion
<Unggnu> I think the gksu password caching is a security risk
<Unggnu> if you use one system app from start menu the pass phrase is saved for a long time and every app started from menu or panel have root right if started with gksu
<Unggnu> so basically a worm with user rights just have to wait until gksu is run, for updating or similar and it has root rights
<Unggnu> Another issue is, why does every user home directory is readable for anyone except of some stuff like ssh or gpg?
<reduz> hi
<BUGabundo> pitti: ping
<BUGabundo> do you have a few moments to help reduz with jokey and nvidia driver on jaunty?
<Unggnu> And security updates should be downloaded automatically on desktop in the default configuration. What do you think?
<cjwatson> bug 48734
<ubottu> Launchpad bug 48734 in adduser "Home permissions too open" [Medium,Invalid] https://launchpad.net/bugs/48734
<cjwatson> Unggnu: I put a detailed explanation of why the home directory is that way in that bug ^-
<Unggnu> cjwatson: thx
<reduz> BUGabundo, jockey just says activating driver, but nothing really happens and if i enter/exit X, it still uses the xorg one
<pitti> reduz: can you please put /var/log/jockey.log somewhere? (pastebin or attach to a bug report)
<Unggnu> cjwatson: But Ubuntu is designed for desktop users afaik and in this case it makes sense. You want your own stuff private without changing permissions. Atm you are not asked and there is a reason why Windows has this feature since using NTFS. Everyone in community environment can change it.
<cjwatson> Unggnu: bug 18905 would probably be worth fixing, but any worm that has access to your X display can already do whatever it wants, including hijacking a window running as root
<ubottu> Launchpad bug 18905 in gksu "gksudo should notify users that the password is being remembered and used" [Wishlist,Confirmed] https://launchpad.net/bugs/18905
<pitti> reduz: tail /var/log/jockey.log should tell what it's doing right now
<cjwatson> Unggnu: I have said my piece in that bug report and it's based on long experience; I do not expect to be persuaded
<Unggnu> cjwatson: I think policy kit should be used for all this things so the passphrase is only cached for one app or saved.
<cjwatson> sentences that start with "Ubuntu is designed for" are often false :-)
<reduz> pitti:
<reduz> 2009-04-01 10:26:46,191 DEBUG: Installing package: nvidia-glx-177
<reduz> 2009-04-01 10:26:47,546 WARNING: modinfo for module nvidia failed: modinfo: could not find module nvidia
<Unggnu> :)
<pitti> reduz: hm, it doesn't seem to start installing then
<cjwatson> Unggnu: policykit> yes, in most cases applications still running entirely as root should be converted to policykit
<pitti> reduz: you don't happen to have synaptic or apt or any other package manager running?
<reduz> pitti, nope
<reduz> clean opened session
<pitti> oh, hang on, it's not live any more
<Unggnu> cjwatson: I just like security by design, especially if it has no penalties for a newbie.
<pitti> reduz: ps aux|grep dpkg has anything?
<cjwatson> Unggnu: of course it has penalties
<cjwatson> Unggnu: if home directories are world-readable, it's harder for me to share a file with my wife using the same computer
<reduz> pitti, nothing
<Unggnu> cjwatson: use the same account if you have nothing to hide
<cjwatson> Unggnu: as soon as this requirement comes up, people disable all the "security by design"
 * Hobbsee adds a "not" into cjwatson's sentence
<cjwatson> Unggnu: I have nothing to hide, but we have different desktop preferences and so it makes sense to have separate accounts
<pitti> reduz: if you do this: sudo strace -v `pidof jockey-backend`
<pitti> reduz: do you get an endless stream of stuff, or just a single call which it hangs on?
<Unggnu> cjwatson: so if a newbie makes home readable for all it wouldn't hurt but ok
<reduz> pitti, the strace help :)
<cjwatson> Unggnu: like I say, except in the case of multi-user systems with dedicated system administration, there is typically a level of trust among people using the same computer. Excessively zealous security is worse than nothing.
<reduz> pitti, jockey-backend seems to be running, though
<Unggnu> cjwatson: I mean 90% of the computer os market handle it "zealous secure" and nearly no one grumps
<pitti> reduz: oh, sorry
<Unggnu> cjwatson: but more important is the gksu issue
<ogra> mdz, thanks, adding a bit of buffer space helped
<cjwatson> no-one grumps> wow, you must never talk to anyone :)
<pitti> reduz: sudo strace -v `ps aux|grep jockey-backend | grep -v grep | awk '{print $2}'`
<Unggnu> not about this feature cjwatson :)
 * pitti grumvles at ps for not DWIM
<cjwatson> perhaps they invent crazy schemes involving mailing their files to each other when they're already on the same computer
<Unggnu> cjwatson: :-D
<cjwatson> or use Samba, or similar
<reduz> pitti, strace: 4179: command not found
<cjwatson> but in any case I don't think you can hold Windows up as a paragon of user security. It's well-known that people just open it up until it does what they need
<pitti> reduz: sudo strace -v -p `ps aux|grep jockey-backend | grep -v grep | awk '{print $2}'`
<cjwatson> which is no better than starting out open, and less convenient
<pitti> reduz: sorry (I'm busy with something else); this should work
<Keybuk> seb128: if you start dbus from gnome-session, how do you get the address of the dbus socket to everything else?
<reduz> pitti, not doing much
<pitti> reduz: please pastebin the output
<reduz> Process 4179 attached - interrupt to quit
<reduz> restart_syscall(<... resuming interrupted call ...>
<pitti> reduz: hm, looks like a deadlock then
<pitti> reduz: can you always reproduce this, or did it just happen once?
<reduz> pitti, booted twice, and both times i tried to run it, the same happened
<pitti> reduz: let me /msg you to not spam the channel
<reduz> pitti, sure
<Unggnu> cjwatson: I am not sure with the paragon. It just bothers me that everyone tells Linux is more secure than Windows but atm Vista is more secure by design than Ubuntu. Data execution prevention, stack canaries, not readable user directory if not asked, no admin caching, autoupdates, browser runs with lower rights and so on. The biggest problem of Vista and later is the high market share so everyone interested tries to find and uses security hole
<Unggnu> s.
<Keybuk> seb128: how is gnome-keyring started?
<Unggnu> cjwatson: They have made their homework imho. We shouldn't cound on a low market share => no risk.
<Unggnu> *count
<seb128> Keybuk: I'm discussing it with halfline on #gnome-hackers now
<seb128> Keybuk: seems that gnome-keyring or gnome-session should use UpdateActivationEnvironment
<BUGabundo> seb128: is bug 353131 one of yours or asac turf? already asked the user to install libbrasero-media0-dbgsym
<ubottu> Launchpad bug 353131 in nautilus "nautilus crashed with SIGSEGV in start_thread()" [Undecided,New] https://launchpad.net/bugs/353131
<asac> nautilus usually isn't me ;)
<BUGabundo> I know asac, but its when pluging a 3g modem
<ogra> asac, we could change that
<BUGabundo> not seen by udev
<asac> ogra: ;)
 * BUGabundo seats and watchs asac punch ogra
<asac> BUGabundo: lets wait for the retracers to kick in first
<BUGabundo> okay
<BUGabundo> in the mean time, I'll see if the user gets the debug symbols on his local system
<ogra> BUGabundo, well, he mainly only cares for two packages :) that little browser thingie and this other program for networks
<asac> BUGabundo: well. lets wait. if the retrace is good he doesnt need to install all the dbg packages
<asac> ogra: i also have font stuff now ;)
<ogra> ah, right
<BUGabundo> ogra: ahaahah
<BUGabundo> ogra: how many do you handle?
<asac> ogra has always been lazy ;)
<ogra> yeah, i'm only slacking through life here all day ...
<ogra> just chatting on IRC from morning to evening ...
<ogra> BUGabundo, currently i'm handling a full subarch
<ogra> and the packages i touched last
<seb128> BUGabundo: none of use and no need to ask anything while it has not been retraced
<BUGabundo> ok seb128
<seb128> use -> us
<Unggnu> cjwatson: I have added a suggestion to the home directory bug report. What do you think. Anyway I guess it is to late for Jaunty.
<cjwatson> Unggnu: no, I'm afraid I'm not going to add such a question to the installer; that's final
<cjwatson> we have debated this endlessly for years
<Unggnu> cjwatson: Do you have a link?
<cjwatson> no
<Unggnu> I don't get the problem of one checkbox line, but Ok. I guess there is a reason.
<cjwatson> Ubuntu already has data execution prevention and stack canaries, which you incorrectly described as features of Vista over Ubuntu
<cjwatson> I do tend to agree that we should ask about automatic updates somewhere; the alternate/server installer already does
<Unggnu> cjwatson: it has, but it is disabled
<BUGabundo> cjwatson: is there a blueprint for that?
<cjwatson> problem of one checkbox line> in the alternate/server installer, that's one extra point of user interaction; in the desktop installer, the user page is already the biggest page on the installer and its visual size causes problems
<cjwatson> BUGabundo: no, and it's not necessary for there to be
<Unggnu> cjwatson: I know that a linux server with some configuration is at least as secure and most likely more secure.
 * BUGabundo points that the Installer desktop on VESA is close to impossible
<ogra> ??
<mdke> slangasek: I think your recent change to gnome-user-docs may have introduced a problem - the omf files for the documents are no longer installed in /usr/share/omf as they should be, so none of the documents appear in yelp and all links to them are broken
<cjwatson> Unggnu: PAE (for NX support) is problematic in terms of hardware support, that's true, so it does depend on which kernel you have installed. But I am not aware of stack canaries being disabled
<ogra> BUGabundo, i'm running it on an 800x600  framebuffer desktop here and it works fine
<mdke> slangasek: I'll file a bug and assign it to you, if you don't mind
<Unggnu> cjwatson: All important Ubuntu apps are compiled with stack canaries?
<cjwatson> ogra: yeah, that's only because the user page is currently in a scrolled window, which (a) looks pretty crap and (b) causes the timezone map to be too small for bigger screens
<BUGabundo> ogra: yesterday I add a dell gx270 with the affected intel 865
<BUGabundo> only VESA would login... 30% of the installer would not be seen
<cjwatson> Unggnu: our gcc has used -fstack-protector by default since 6.10. See https://wiki.ubuntu.com/CompilerFlags
<jelmer> seb128: ping
<ogra> cjwatson, right, i agree about a ... b should be fixed by scaling
<Unggnu> cjwatson: cool, thanks
<seb128> jelmer: hello
<jelmer> seb128: I've looked at OpenChange 0.8.2, but it includes some new libraries since 0.8.0 used by the server side
<jelmer> seb128: would that be a problem for Ubuntu?
<seb128> jelmer: I don't think so
<seb128> jelmer: evolution-mapi is not usuable now so we need an update anyway I think
<mdke> slangasek: ok, it's bug 353154 - I will also see if I can figure out how to fix it a bit later
<ubottu> Launchpad bug 353154 in gnome-user-docs "gnome-user-docs 2.26.0+svn20090323ubuntu2 has broken all documents in yelp" [Medium,Confirmed] https://launchpad.net/bugs/353154
<jelmer> seb128: cool, thanks
<directhex> hm, i wonder why i can't get evolution-mapi working
<seb128> is it crashing?
<directhex> hangs for ages then spits out an error "MAPI_E_NETWORK_ERROR"
<ogra> mdz, while your hint was helpful .... ogra@antimony:~$ ls -l iso/ubuntu
<ogra> lrwxrwxrwx 1 ogra warthogs 1 2009-03-24 12:53 iso/ubuntu -> .
<directhex> when trying to add the account
<ogra> thats why it died
<mdz> that would do it too
<seb128> hum
<cjwatson> ogra: what's wrong with that?
<ogra> cjwatson, vfat isnt actually symlink friendly but mcopy follows them ...
<cjwatson> ah
<ogra> so that like copies the content over and over until my image is full
<ogra> s/like/link/
<directhex> i might be misunderstanding how to use it, but it definitely just hangs here
<seb128> directhex: open an upstream bug?
<Unggnu> Btw. is it final that the 2.6.28 ath5k driver stays in Jaunty? It seem to have many problems.
<Unggnu> They are fixed with the backport modules package or by using 2.6.29 but Jaunty isn't even released so a patch might be appropriate.
<pitti> tseliot: thanks for the patch in bug 320632; did you get any feedback on it?
<ubottu> Launchpad bug 320632 in xfree86-driver-synaptics "tap-to-click and edge-scrolling broken in Jaunty" [Medium,In progress] https://launchpad.net/bugs/320632
<tseliot> pitti: no, maybe I should package it and make it available in my PPA, otherwise people won't test it
<pitti> tseliot: that would be nice; please also consider mailing u-devel@ for a call for testing, since it becomes a bit pressing now, time-wise
<tseliot> pitti: ok
<kagou> cjwatson, indeed :) -> <cjwatson> 14:43:43> +kagou: 9/10 might be something to do with the locale not being set yet
<ni|> hey, whats the remote desktop system in jackalope
<ni|> VNC?
<maco> think so
<BUGabundo> vino ?
<ogra> ltsp !
<ogra> (ok, not really :) )
<BUGabundo> I have set my own ltsp system one day
<kees> Unggnu: some of your questions are addressed here: https://wiki.ubuntu.com/SecurityTeam/FAQ
<BUGabundo> last time I tried it, it was a fuss... to much work to put it running
<ogra> nice
<ogra> when did you try it last time ?
<BUGabundo> the best of Edubuntu got lost
<BUGabundo> 1y ago
<BUGabundo> hardy I think
<ogra> no, it didnt get lost
<ogra> all ltsp bits moved 1:1 from edubuntu into ubuntu
<BUGabundo> there should be a TaskSel for it
<BUGabundo> making it stupid-easy
<BUGabundo> one click, and you are done
<ogra> no, it needs special treatment, there is a udeb for it
<ogra> right
<BUGabundo> with just a question or two
<ogra> use the laternate CD and use the F4 menu to select "install ltsp server"
<BUGabundo> 1) Is this server or client
<ogra> and it asks no questions at all
<BUGabundo> 2) where to connect
<BUGabundo> ahh nice
<ogra> 1 is irrelevant
<BUGabundo> didn't know that
<Unggnu> kees: thx
<ogra> clients netboot from the server
<BUGabundo> time to set up 3 more VMs
<slangasek> mdke: I'm on it
<ogra> BUGabundo, https://help.ubuntu.com/community/UbuntuLTSP/LTSPQuickInstall
<BUGabundo> I already have a DHCP in the network... gonna need to hack it to set the TFTP
<slangasek> pitti: having the relevant gnome-user-guide-* versions back on the CD isn't a terrible loss, it won't cost us more than a couple meg anyway :)
 * BUGabundo rumbels something about ISA server
<BUGabundo> ogra: thanks for the link
<pitti> slangasek: you say that so light-heartedly..
<slangasek> pitti: easy come easy go!
<pitti> heh
<ogra> BUGabundo, more background info on https://help.ubuntu.com/community/UbuntuLTSP
<BUGabundo> do we have rsync running as a service now?
<BUGabundo> a user said it came with ubutnu-standard seed
<BUGabundo> and was running as service
<mdke> slangasek: thanks a lot
<ogra> BUGabundo, the initscript is there since forever, but its a no-op since forever as well
<BUGabundo> ok
<tseliot> cjwatson: are @canonical.com addresses whitelisted in ubuntu-devel@lists.ubuntu.com ?
<BUGabundo> ogra: its just that the insists its running on is system
<dholbach> tseliot: nope
<dholbach> tseliot: just ~ubuntu-dev people AFAIK
<tseliot> dholbach: ok, I'll keep using my old address then. Thanks for your reply
<kees> cjwatson: do you feel that this section correctly captures your feelings on the subject? https://wiki.ubuntu.com/SecurityTeam/FAQ#Permissive%20Home%20Directory%20Permissions
<ogra> BUGabundo, well, its initscript is started but doesnt run any process
<kees> (we wrote it during the Sprint because, well, it was a f.a.q.)
<cjwatson> tseliot: not in general; some are
<cjwatson> tseliot: Ubuntu developers are whitelisted, and there's a fairly lengthy manual list as well
<cjwatson> I don't think it's appropriate to have a blanket whitelist for @canonical.com personally
<cjwatson> kees: yes, thanks - I looked for that but obviously missed it
<tseliot> cjwatson: ok, thanks for your answer
<kees> cjwatson: well, it wasn't in the FAQ until about 3 minutes ago -- it was on another page, but it belongs there.  (I added the bug link just now too)
<cjwatson> kees: ah, heh
<pitti> kees: hm, Private/ doesn't exist by default, only with ecryptfs
<mathiaz> sbeattie: how well does apport support disconnect mode (ie the system doesn't have a network connection to lp)?
<ka6sox-work> cjwatson, I spoke with davidm @ SCALE about the potential for leaving update-manager-core as the only thing in a unsupported distro (ie edgy, feisty) so that you don't have to manually upgrade 2-3 revisions to use do-upgrade.
<kees> pitti: oh? I thought it was part of the xdg-whatever package that creates Music, Pictures, etc?
<kees> xdg-user-dirs ?
<pitti> not that I know of
<cjwatson> ka6sox-work: I'm not sure that's actually possible; doesn't update-manager know how to switch to old-releases?
<pitti> kees: I just know it in the context of ecryptfs
<sbeattie> mathiaz: let me verify, but I *think* it lets you save the report to file later/from a different location.
<cjwatson> ka6sox-work: anyway, update-manager is mvo's business
<kees> pitti: well, for ecryptfs, it's considered "Encrypted Private"
<cjwatson> kees: it's ecryptfs-only, as pitti says
<pitti> kees: right, so I don't think this FAQ and Private/ have anything to do with each other
<kees> cjwatson, pitti: yup, you are absolutely right.
<ka6sox-work> okay thanks..I'll wait around for mvo.
<mathiaz> sbeattie: this is my main concern to installing apport by default on ubuntu-server
<pitti> kees: perhaps just point out to make files/dirs 700?
<cjwatson> but of course you can always create one
<mathiaz> sbeattie: another minor concern is that it bloats the default installation
<kees> I would really like to see Private in xdg-user-dirs.  dang, I thought that's where it ended up.
<kees> FAQ adjusted
<seb128> kees: xdg-user-dirs and xdg-user-dirs-gtk handle those special directories
<mvo> ka6sox-work: update-manager needs backports for the code that switches to old-releases. that is currently not done because of time constrains :/
<sistpoty|work> scott_ev: please don't change the status of FFe bugs (bugs where motu-release is subscribed). we (motu-release) use "confirmed" to denote that a freeze exception is granted. Thanks
<kees> seb128: yeah, just found it.  I've opened bug 353231 for it.
<ubottu> Launchpad bug 353231 in xdg-user-dirs "mode 0700 "Private" directory should be included" [Undecided,New] https://launchpad.net/bugs/353231
<seb128> kees: nobody is working on it so the bug is likely going to stay there is you don't write the patch yourself for it ;-)
<mathiaz> sbeattie: IMO the major use case for apport on server is that ubuntu-bug will be run on a sysadmin workstation to report a bug that happened on another server system.
<mathiaz> sbeattie: does apport support this use case?
<kees> seb128: right, I just wanted to get it filed.
<sbeattie> mathiaz: it's supposed to, but saving the report isn't working for me for some reason.
<freinhard> ArneGoetje, cjwatson: nice, gnome-user-guide just got uninstalled! don't know who exactly fixed it: thx!
<pitti> seb128: ok, instead of crashing with KeyError, apport-retrace now DTRT (see bug 349833)
<ubottu> Bug 349833 on http://launchpad.net/bugs/349833 is private
<seb128> pitti: you rock!
<pitti> apw: do you have any preference wrt. the tag alternatives in bug 349621?
<ubottu> Launchpad bug 349621 in apport "real kerneloops and suspend/hibernate/resume bugs are hard to separate" [Medium,In progress] https://launchpad.net/bugs/349621
<pitti> apw: for backwards compatible LP search I'm inclined to keep apport-kerneloops for real oopses at least
<slangasek> mdke: gnome-user-docs fix uploading, new merge proposal sent
<apw> pitti, a tricky one, hard to be compatible with both searches
<apw> breaking mine is the newer one
<pitti> apw: the second option wouldn't break either
<ArneGoetje> freinhard: pitti did.
<pitti> apw: AFAIUI, it would just add "panic-oops" tag to real oopses
<mdke> slangasek: thanks very much.
<mdke> how long does it take for a binary to appear on LP or in the archive after a build finishes?
<pitti> apw: i. e apport-kerneloops would be the general class (which should ideally be called "apport-kernel"), and "panic-oops" vs. "resume" tell you the subclass
<pitti> mdke: short answer: two to three hours
<freinhard> pitti: you're the man! :D
<apw> yeah if you are happy it works ok for me
<apw> pitti, if we later sanitise them, they can do a DB update for change them
<pitti> apw: I don't mind either way, just trying to think about what existing searches folks use
<mdke> pitti: whoosh, that's a long time
<apw> yeah i concor on them
<pitti> freinhard: not sure what it's about, but if you mean gnome-user-guide-*, well, I broke it, I fix it :)
<pitti> apw: do you happen to have a real kerneloops bug?
<pitti> apw: or, can you confirm that a kernel oops really calls /usr/share/apport/kernel_oops ?
<pitti> (as opposed to creating a .crash file all by itself in some way)
<apw> pitti, there is a real way to trigger one, which works all the way to kerneloops and gets hidden automatically
<apw> lieb, can you point pitti to the crasher tester thing
<pitti> apw: ah, I know about that one
<pitti> I was just lazy
 * pitti RTFS
 * apw is lazy too
 * maco wishes kernel panics generated .crash's too
<pitti> apw: got it, bug 286389 is one
<ubottu> Launchpad bug 286389 in linux "WARNING: at /build/buildd/linux-2.6.27/arch/x86/kernel/cpu/mtrr/main.c:1500 mtrr_trim_uncached_memory+0x153/0x386()" [Low,Triaged] https://launchpad.net/bugs/286389
<pitti> maco: they do if you have kerneloops installed
<sbeattie> pitti: is apport-cli/ubuntu-bug's "keep report for later" option unimplemented? I always get "Problem report file: None" when I try to keep a report for later.
<maco> pitti: only some of the types of panics i get do
<maco> the ones where it just spins up the cpu and stops responding to input (including magic sysrq)...nothing for those
<maco> and the last one that included flashing caps didnt either. but some have in the past.
<TheMuso> cjwatson: You don'tneed to tell me that. :) In my panic it was the first thing I thought of, and I was reminded of such a solution afterwards. :S
<pitti> apw: should the tag really be called "panic-oops", given that many oopses aren't panic?
<pitti> apw: there are already 55 bugs tagged "kernel-oops", should it rather use that one?
<apw> that would be more sensible yes
<pitti> sbeattie: sorry, which option?
<sbeattie> selecting K for keep report for later when using apport-cli
<pitti> sbeattie: ah, I see; it's meant to work, mind filing a bug about it?
<sbeattie> pitti: will do, thanks!
<cjwatson> TheMuso: *nod*
 * ogra wonders if anyone from ubuntu-mir could finally approve redboot-imx and redboot-tools
<ogra> the latter will break flash-kernel and armel imx51 installs if its not in main soon
<broonie> OOI are you guys working on pushing the i.MX kernel towards mainline or are you carrying the diff?
<ogra> its going into mainline
<amitk> broonie: I am breaking it into tiny bits for mainline
<kees> ogra, NCommander: RedBoot-imx> this needed in main because it will appear on a liveCD?  or is it only used to *create* the liveCD?
<ogra> the latter
<NCommander> the later
<kees> in that last, does it need to be in main?
<NCommander> oh, ogra beat me to it
<ogra> in karmic we'll provide something like grub-install for it
<ogra> would be good to have it in main, makes it easier to install it on the cd creation machines
<broonie> amitk: Oh, wow - excellent news.
<broonie> amitk: Any audio stuff coming?
<ogra> kees, else the image creation script needs to hack around that and i'll make cjwatson unhappy with my weird script hacks
<kees> my knowledge is a bit thin in this area.  :)
<kees> I thought we could create images when things are in universe now?
<ogra> kees, for official images all packages going on these images need to be in main
<amitk> broonie: thats upto freescale mostly
<kees> ah-ha
<broonie> amitk: Ah, so unlikely to happen then.
<ogra> for unofficial ones universe can be used
<ogra> imx51/babbage has to be official
<kees> cjwatson: do you think we should add "official image support" to the Rationale list on https://wiki.ubuntu.com/UbuntuMainInclusionRequirements ?
<Superdweeb> hi guiz, is mark shuttleworth in the room?
<Superdweeb> awake, possibly?
<sbeattie> pitti: bug 353253
<ubottu> Launchpad bug 353253 in apport "ubuntu-bug/apport-cli offers to save a report for later, but always fails to do so" [Undecided,New] https://launchpad.net/bugs/353253
<cjwatson> kees: wouldn't hurt; I think it morally comes under build-dependency [of our CD images]
<cjwatson> Superdweeb: he's a busy man. What do you want?
<Superdweeb> I want something really easy to handle and simple to fix.
<Superdweeb> I mean I want it fixed.
<Superdweeb> It wont take a moment to give the order.
<ogra> and you think mark can fix it for you ?
<Superdweeb> I think he would and can give the order to have it done by release.
<kees> cjwatson: is some person/group in charge of the MIR requirements list besides the MIR team?
<kees> I just want to clarify the language
<cjwatson> kees: go ahead and edit it
<kees> cool
<cjwatson> Superdweeb: do you often find that the CEO of anything other than a tiny company takes all the decisions himself?
<Superdweeb> I think this decision would be a simple one to make and, rationally, a clean, unobscured ripple.
<Superdweeb> It would make about as much sense as the cool new notification system.
<Superdweeb> Which was on his blog.
<cjwatson> yes, Mark takes a personal interest in desktop experience, but in general the way to request changes is not to contact the founder of Ubuntu, but to file a bug
<Superdweeb> I'm not going to file a bug about this, because it's been around since the very beginning of ubuntu, and it's so trivial, everyone has overlooked it.
<Superdweeb> But it's also very important.
<cjwatson> and the way to escalate problems goes through developers with an interest in the package, through the team with a general responsibility for the package, to the technical board
<cjwatson> it does not involve everyone contacting Mark directly, since that wouldn't scale
<Superdweeb> I'm told by the responsible developers, erm, artists, that this is in the hands of upstream gnome.
<Superdweeb> I'd like to shoot upstream gnome, take it out of their hands, and have this dealt with.
<cjwatson> your attitude is not appropriate, so I'm not surprised you aren't getting traction
<Superdweeb> I promise, this is such a SIMPLE problem nobody wants to have anything to do with it.
<jameswf> can the 9.04 login screen look like http://www.live.com/
<cjwatson> please follow the code of conduct and deal respectfully with other developers, including those in GNOME
<Chipzz> or you could just request ubuntu to patch it, and leave upstream out of it?
<Superdweeb> Yes.
<Superdweeb> I just want to patch it here.
<cjwatson> what IS the problem?
<Keybuk> Superdweeb: what do you want to patch?
<Superdweeb> Gnome-panel handles.
<Superdweeb> Resize your panel.
<Chipzz> then what's with the shooting of upstream? been playing too much CS? :)
<Superdweeb> Now make it transparent.
<Superdweeb> IT's super dooper how much you guys have put into this, the entire notification area handles transparency perfectly.
<Keybuk> Superdweeb: I believe there's already a bug about that one upstream
<Superdweeb> well, it needs to be stopped. this is ugly. it dates back to the neo-lithic era of gtk 1.0.
<cjwatson> it's not in general economic for us to patch *everything* in Ubuntu, unless it's actually important to us
<Keybuk> Superdweeb: do you have a patch for it?
<Superdweeb> I'm just an idiot.
<Superdweeb> DO you think I have access to the gnome sources?
<Keybuk> Superdweeb: yes, everyone does
<Keybuk> Superdweeb: ftp://ftp.gnome.org/pub/GNOME/sources/
<Superdweeb> I'm just a user who happens to be a geek who knows enough about ubuntu to hack a bit on getting all his family applications working on wine. I have been taking college programming, but what they have taught me so far is mostly VB and cobol. I'm hoping to move to a larger college and learn something useful like C, but very simply..
<Superdweeb> I asked you to handle this.
<Superdweeb> Just like everyone else, you are telling me to do it myself.
<Superdweeb> This is GTK 1.0.
<Superdweeb> In an interface where ALL windows have rounded corners.
<Superdweeb> Where we have so many brilliant edits to the appearance.
<Keybuk> Superdweeb: no, I was just asking you whether you had a patch for it
<Keybuk> maybe you've seen one elsewhere?
<Superdweeb> Never.
<Keybuk> or if you've talked to other people, they've pointed you at one
<Superdweeb> I was told to edit the gtkrc file in a theme, but I never got anywhere.
<Keybuk> if you could file a bug in Launchpad, that would be appreciated
 * ogra starts to develop a passionate hate for jauntys constant crashyness
<Keybuk> it may be that it's fixed by replacing the GNOME panel
<Superdweeb> I will file 500 bugs.
<Keybuk> since that seems to be the general plan
<Keybuk> Superdweeb: just one will do
<Superdweeb> I'm scared keybuk.
<Superdweeb> They say they are replacing the gnome interface with something totally new.
<Keybuk> in fact
<Keybuk> there's already a bug
<Keybuk> bug #46659
<ubottu> Launchpad bug 46659 in gnome-panel "Buttons for hiding needs to be transparent" [Unknown,Confirmed] https://launchpad.net/bugs/46659
<Chipzz> but anyway
<Keybuk> if you subscribe to that, you'll be notified of any work in this area
<Chipzz> wouldn't #dx be more appropriate?
<Superdweeb> I'll be notified.
<Superdweeb> The bug was filed 3 years ago.
<Superdweeb> Still hasn't been dealt with.
<Chipzz> write a patch? :)
<Superdweeb> This is jaunty now, we have SUPERNESS in our distro.
<azeem> or pay somebody to write a patch
<Superdweeb> I'll pay you $10 US.
<Superdweeb> paypal.
<Superdweeb> right now,
<Superdweeb> What do you say?
<Chipzz> I'ld say you're a cheapskate ;)
<Chipzz> $10 is about 1h of work
<Chipzz> less
<Superdweeb> I'd up it to 20 but my monthly allowance for food is 50.
<Chipzz> writing it, submitting it, getting it integrated would take way longer than 1h
<Superdweeb> I was payed 20 dollars this week by a client, erm, a friend, who asked me to fix her computer.
<Superdweeb> I installed spybot s and d, firefox, and handed her an 8.10 disk and asked her to take a look at it sometime.
<azeem> Superdweeb: that's off-topic here
<Superdweeb> IT is?
<Superdweeb> I contributed time and effort to your cause, my cause, our cause.
<Chipzz> Superdweeb: azeem has other duties he has to attend to
<Superdweeb> super.
<Chipzz> and as a matter of fact, so do I :) which I'm going to do
<Superdweeb> Are you absolutely sure mark can't schedule me in for a few minutes sometime?
<Chipzz> yes
<Superdweeb> by appointment, even?
<Chipzz> this was explained quite clearly to you above
<Chipzz> surely you read that?
<Superdweeb> It was explained that he was a busy man.
<kees> Superdweeb: the best place to get leverage would be here: http://mail.gnome.org/mailman/listinfo/desktop-devel-list
<azeem> euh
<Superdweeb> Your pointing me upstream again.
<Superdweeb> Lets not go there.
<Superdweeb> But sure.
<Superdweeb> I'll email them right now.
<ogra> kees, thanks a lot for the two approvals ... the mobile team will pay you a beer from the team cash at UDS :)
<kees> \o/
<Chipzz> Superdweeb: also, like I said, the best place to discuss this is #dx (desktop experience)
<Chipzz> please take the discussion there
<Superdweeb> Is that an ubuntu-specific channel?
<Chipzz> not entirely sure but I think it is
<pitti> sbeattie: thank
<Superdweeb> I see kenvandine there, didn't he part foresight for ubuntu?
<Superdweeb> I'll go there
<Superdweeb> bye for now, I will be back, better get to work on my patch, you bunch of dammed code monkies.
<pitti> bdmurray: oh, congratulations to your new MOTU badge!
<TheMuso> bdmurray: Yeah congrats!
<bdmurray> pitti, TheMuso: Thanks!
<apachelogger> could someone please take a look at bug 330419 and tell me if kwin is supposed to send some signal to get gnome to draw the desktops?
<ubottu> Launchpad bug 330419 in kdebase-workspace "GNOME+Kwin: desktops aren't drawn" [Undecided,New] https://launchpad.net/bugs/330419
<mdke> Keybuk: double bluff april fool, nice one. That had me going
<superm1> asac, ping.  i wanted to ask about that dnsmasq-base bug for NM.  it got triaged a while back, but not with a definitive plan as I can tell. is there a particular reason to not add it as recommends?
<asac> superm1: its not a recommends ?
<nixternal> hahahaha Keybuk!!!!
<superm1> asac, well it's not in the default install from a recent live disk, so I'd suppose it's not still
<asac> yeah should be added
<mathiaz> Is a third-party package that installs most of its files in /opt allowed to put files in /usr/sbin (for example) too?
<asac> superm1: does dnsmasq-base ship this ugly resolvconf stuff?
<superm1> asac, I don't think so. all I see is a /usr/sbin/dnsmasq binary in the package
<asac> superm1: nah. what i mean, does it depend on resolvconf and then replace resolv.conf with "127.0.0.1"? or is that just dnsmasq (main) package?
<superm1> asac, oh no it doesn't.  i just installed it on afresh install, it has no additional dependencies
<superm1> so resolvconf doesn't come in
<asac> superm1: good. then i will add that now to recommends
<superm1> asac, and it's still using my standard name servers in /etc/resolv.conf
<superm1> asac, great thanks.  will finally be able to do connection sharing out of the box then :)
<asac> good thanks for checking the resolvconf thing
<asac> superm1: committed. rev 37
<asac> next update will get this
<asac> superm1: did we hav a bug id for that?
<superm1> asac, yeah we did. let me see if i can find it
<superm1> bug 269963
<ubottu> Launchpad bug 269963 in network-manager "[intrepid] network-manager should recommend or suggest dnsmasq" [Medium,Triaged] https://launchpad.net/bugs/269963
<lool> cjwatson: Hi, I'm on a show today; just got network now and can't stay much longer, is there anything you'd need me to look at now?
<lool> slangasek: No idea about texlive-bin
<lool> NCommander: Could you please try building texlive-bin with the current gcc to check whether the g++-4.2 is still needed?
 * ogra wonders why slangasek specifically asked us
<NCommander> lool, on which architecture?
<lool> ogra: Probably an armel change?
<cjwatson> lool: ... sorry, lost context. About what?
<lool>   * use gcc/g++-4.2 on armel to fix FTBFS (closes: #483939) (thanks Adeodato)
<lool>  -- Norbert Preining <preining@debian.org>  Sun, 01 Jun 2008 16:29:49 +0200
<lool> texlive-bin (2007.dfsg.1-4) unstable; urgency=low
<NCommander> ah, fair enough
<lool> cjwatson: In general, anything :)
<lool> cjwatson:  micro-evtd-udeb?
<lool> No idea about this
<cjwatson> oh, well, somebody needs to sort that out yes
<NCommander> lool, do you want me to attempt to fix the build with 4.3 if it fails?
<lool> NCommander: Happy to yes
<calc> nice rsync'ing a i386 cd from an amd64 cd had a 1.81 speedup :)
<lool> cjwatson: ah it needs to be promoted
<lool> NCommander: Do you think you could write a MIR for micro-evtd-udeb??
<lool> s/??/?
<NCommander> I did
<NCommander> Ages ago...
<NCommander> lool, https://wiki.ubuntu.com/MainInclusionReportMicroEvtd
<NCommander> wait
<NCommander> you did, I just bookmarked it
<NCommander> actually, we both did looking at the history page ...
<lool> NCommander: is there a bug?
<lool> I don't recall writing it, can't believe it
<NCommander> lool, I wrote it, you revised it according to the history
<NCommander> (you did the source code review)
<lool> Right
<lool> NCommander: Could you bug that please?
<NCommander> I don't think its going to pass a MIR with a security issue ...
<lool> Just so that I think of looking at it tomorrow, don't have much time here, and it will take me a couple of hours to go home; it's already 7pm
<NCommander> fair enough.
<mvo> doko: if you could have a look at bug #353251 that would be appreciated
<ubottu> Launchpad bug 353251 in python-central "does not provide 2.6 symlinks for python-fstab (and others?) when python2.6 gets installed" [High,New] https://launchpad.net/bugs/353251
<mbana> how do i reset the sound preferences page to default, as in, system->prefs->sound (on ubuntu)
<Keybuk> tests/type_wrapper.c:449: error: assignment makes integer from pointer without a cast
<Keybuk> *sigh* there's nothing worse than errors in auto-generated code
<Keybuk> the damned C file VANISHES once make has done with it
<cjwatson> they're great, you can fix thousands of them at once
<cjwatson> Keybuk: mark them .SECONDARY?
<Keybuk> cjwatson: in this case, it's more of a general annoyance
<Keybuk> though I have briefly thought of doing the __LINE__ trick
<NCommander> slangasek, texlive ICEs with GCC 4.2 :-/
<NCommander> er
<NCommander> 4.3
<calc> pitti: does bug 348667 just need to be kicked to be retraced again?
<ubottu> Bug 348667 on http://launchpad.net/bugs/348667 is private
<mvo> Riddell, scottk: i suspect the missing qt.so link is due to bug #353251
<ubottu> Launchpad bug 353251 in python-central "does not provide 2.6 symlinks for python-fstab (and others?) when python2.6 gets installed" [High,New] https://launchpad.net/bugs/353251
<Bluehorn> hey everybody
<Bluehorn> Perhaps somebody here can help me: I want to update the packaging of my Debian ddclient package.
<Bluehorn> And I'd like to have it in bzr.
<maxb> Bluehorn: Hi! General packaging help and discussion of Ubuntu universe packages is more on topic in #ubuntu-motu
<Bluehorn> Now I am wondering if the tool generating package-import.ubuntu.com is available somewhere.
<Bluehorn> maxb: That's a misunderstanding, I do not need help with the packaging itself. I just want to use bzr as the VCS and have no idea how to import my history into it.
<maxb> Ah
<maxb> I don't know what drives package-import.u.c, but have you seen bzr-builddeb's import-dsc command?
<Bluehorn> ah
<Bluehorn> maxb: just found it on https://wiki.edubuntu.org/DistributedDevelopment/Specification
<Bluehorn> maxb: thanks for the pointer!
 * NCommander thinks shadow's manpage reads like a legal document
<seb128> slangasek: GNOME 2.16.1 will have a standing freeze exception right?
<kenvandine_wk> seb128: yay... gnome 2.16.1 was a great version :)
<seb128> 2.26.1
<maxb> Hi, bzr 1.13.1 is in unstable. should I file a new sync request / FFe, or take over bug 341501 which is about 1.13rc1 but never got closed?
<ubottu> Launchpad bug 341501 in bzr "Freeze exception for bzr 1.13rc1" [Undecided,Confirmed] https://launchpad.net/bugs/341501
* mthaddon changed the topic of #ubuntu-devel to: Launchpad is going down from 22:00 UTC April 1st until 01:00 UTC April 2nd for a code update | Python 2.6 issue #349467 | Archive: feature freeze | Ubuntu 9.04 Beta released! | Development of Ubuntu (not support, not app development on Ubuntu) | #ubuntu for support and general discussion for dapper-intrepid | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs f
<slangasek> seb128: yes
<seb128> slangasek: tarball will be available after the rc freeze that's no issue? just making sure ;-)
<slangasek> seb128: hmm, eew :(  none of them are available until that week?
<seb128> slangasek: no, they are due on monday 13 april
<seb128> usually GNOME roll on their tarball on the due day
<seb128> if we want to lower changes I can snapshot the svn for the few components which got quite some commits
<seb128> so we have easier review after the freeze
<slangasek> I'm mostly concerned about having the buildds be that busy right before RC
<seb128> slangasek: I don't expect they will roll tarballs for everything so we should have the updates in jaunty on monday evening
<slangasek> wok
<slangasek> ok
<NCommander> cjwatson, I've been working on debugging #349504 since I worked out what was causing the issue , and I was curious if you'd be interesting in sponsoring the fix-it upload
 * NCommander pokes the bot
<cjwatson> NCommander: I'm happy to review a patch. (And for the record I knew the problem was in useradd not adduser, that's why I asked ogra to file the bug on shadow ;-) )
<cjwatson> NCommander: I'm not sure I wouldn't be more comfortable with useradd setting it to 1 rather than 0 at this point, though. Do we *know* that everything handles an empty sp_lstchg right?
<NCommander> cjwatson, er, its not setting it to one
<NCommander> cjwatson, its leaving the field blank
<NCommander> Which is what it should do if there is no exp
<cjwatson> that's what you're suggesting it should do, yes
 * NCommander traced this through libshadow
<NCommander> Oh
<NCommander> sorry, misread
<NCommander> (long day)
<cjwatson> I'm suggesting that maybe spotting current-time==0 and special-casing that to 1 would be safer
<cjwatson> anyway, it's the end of my day, happy to look at it tomorrow
<NCommander> We could put in a special usecase where if both expiration date, and last password equal zero, it will ignore the reset
<NCommander> That being said, any app working through libshadow works correctly
<cjwatson> unlike, for example, pam? :-)
<NCommander> cjwatson, I tested it on real hardware without any issues
<cjwatson> the common interface to the shadow file is not libshadow, but getspent and friends in libc (and that doesn't really define semantics, just syntax)
<NCommander> But I see your point.
<cjwatson> NCommander: I understand, but I am trying to ensure that we don't run into problems with things that you didn't think to test
<cjwatson> anyway; will review patch tomorrow if you post it
<NCommander> So its do the right solution which might break broken implementations, or the wrong solution which makes the possibly broken one work
<NCommander> :-/
<cjwatson> pretending that time cannot be any less than 1 day post-epoch is hardly all that wrong
<cjwatson> anyway, I haven't checked whether empty sp_lstchg is safe, that's all
<cjwatson> post the patch you have and we can talk about it based on that
<NCommander> cjwatson, I'm waiting for my build to finish, but I can also cook a solution to libshadow just as easily
<LordMetroid> Anyone got an idea on how hard it would be to make S-video automount?
<slangasek> what do you mean, "automount"?
<slangasek> mounting is something you do with disks, not video
<LordMetroid> yes, I mean work automatically when you plug the s-video cable in
<directhex> that's driver-dependent
<bluszcz> hi
<bluszcz> i am trying to find policy about truetype packaging, but there is no word about it: http://www.debian.org/doc/debian-policy/ch-customized-programs.html#s11.8.5 - is there any ubuntu specific document?
<bluszcz> i also found something like this:
<bluszcz> http://www.mail-archive.com/debian-x@lists.debian.org/msg04524.html
<bluszcz> ;)
<slangasek> hrm, didn't you ask this same question a couple days ago?
<bluszcz> i asked about fonts generally, AFAIR
<bluszcz> but it is possible, that i am wrong ;)
<bluszcz> anyway - i tried today another with ttf and failed
<bluszcz> i can debug actual packages, butt...
<bluszcz> http://www.archivum.info/debian-policy@lists.debian.org/2008-07/msg00206.html
<slangasek> well, the policy is "install your fonts in a per-package directory under /usr/share/fonts/truetype"
<bluszcz> and what should be run after it?
<bluszcz> take a look:
<bluszcz> http://pastebin.com/m269a659b
<slangasek> that part is less clear than it should be :/
<bluszcz> sorry, but where did you found "install your fonts in a per-package directory under /usr/share/fonts/truetype" phrase?
<slangasek> when I say that it's the "policy", I mean it's what everyone does
<slangasek> it's not written in policy, which as Russ says in the link you posted, is a bug
<bluszcz> ok
<bluszcz> i think i had to submit a bug
<bluszcz> in launchpad
<bluszcz> Launchpad is offline for scheduled maintenance. We should be back soon.
<bluszcz> gods left me off.
<maxb> james_w: Hi, are you around? I wanted to ask whether bug 341501 (https://staging.launchpad.net/bugs/341501/) still being open means you have an eye on the bzr 1.13.1 sync needed, or if another bug should be filed?
<ubottu> Ubuntu bug 341501 in bzr "Freeze exception for bzr 1.13rc1" [Undecided,Confirmed]
<ubottu> Launchpad bug 341501 in bzr "Freeze exception for bzr 1.13rc1" [Undecided,Confirmed] https://launchpad.net/bugs/341501
<maxb> huh, how did ubottu manage that
<slangasek> bluszcz: this isn't something that's a good candidate for a bug report; it's a policy discussion
<bluszcz> slangasek: lack of documentation is a bug
<slangasek> bluszcz: my first choice would be to see this resolved in Debian where it can find its way down into Ubuntu automatically; otherwise, I think it ought to be a blueprint
<bluszcz> hm
<bluszcz> i found good template
<bluszcz> package is called ttf-engadget
<bluszcz> very simple
<slangasek> of course it's a bug.  It's just not useful to handle a policy bug in the LP bug tracker, because you won't get the right set of people considering it
<bluszcz> ok
<bluszcz> very clear debian/rules :)
<james_w> maxb: they should probably be closed now. Thanks for the reminder about the sync though. Are you interested in working on it?
<LordMetroid> directhex, even though it is driver dependant, it should be possible right?
<bdmurray> sparc is a port now right?
<bdmurray> https://wiki.ubuntu.com/UbuntuDevelopment/PackageArchive#Architectures
<LordMetroid> directhex, at least some kind of configuration GUI would ease the utilisation of S-video
<slangasek> bdmurray: yes
<maxb> james_w: Well, I haven't tested it *yet*, but I'm interested enough to look into it if it turns out to actually require any work.
<maxb> OK, I will close that bug when LP comes back up and file a suitable new one.
<slangasek> LordMetroid: for drivers supporting xrandr, that should already be handled through System -> Preferences -> Display, I think?  But I'm not sure whether that works to make it persistent across sessions
<LordMetroid> xrandr just tells me off when I try to run it
<seb128> slangasek: display changes are written on the disk and loaded at login
<slangasek> bluszcz: ttf-engadget doesn't look like a very good template to me; the fonts are registered with neither defoma or fontconfig
<slangasek> LordMetroid: well, what video driver do you have and what's the process for getting S-Video configured on your system *non*-automatically?
<LordMetroid> I got some older ati card
<LordMetroid> Dunno what it is
<LordMetroid> nor do I know what driver it is, I have no idea about how to get s-video running
<james_w> maxb: thanks. It should be quite straightforward, let me know if you hit any trouble
<LordMetroid> And I am an experienced programmer, normal common Joe would have no chance in hell to get their S-video running
<LordMetroid> It needs to be remedied
<slangasek> LordMetroid: ok, that's a much larger problem than "getting it working automatically", then; for all I know, that means the S-Video output isn't supported by the driver...
<bluszcz> slangasek: #
<bluszcz> dh_installtex - register Type 1 fonts, languages, or formats with TeX
<bluszcz> #
<bluszcz> dh_installxfonts - register X fonts
<slangasek> LordMetroid: but you should probably talk to folks in #ubuntu-x
<bluszcz> only these two helpers...
<bluszcz> none of found examples use it ;)
<slangasek> bluszcz: neither of those are relevant; you would want dh_installdefoma, and also something that registers with fontconfig, but I don't see a helper for that
#ubuntu-devel 2009-04-02
<directhex> ooh, may presents many opportunities for keysigning. how enormously exciting
<YokoZar> haha so this page is rather inflated by the 100+ instances of "awkward punctuation in "about Ubuntu" docs" filed against every package http://qa.ubuntu.com/reports/bug-fixing/jaunty-fixes-report.html
<YokoZar> actually that might just be launchpad vomitting
<directhex> oh dear. madwifi no longer works on the acer aspire one in jaunty
<maxb> Did it work in Intrepid?
<maxb> I didn't think so.
<directhex> yeah, it did
<directhex> ath5k is also busted
<maxb> ath5k WJFFM
<maxb> madwifi very definitely *doesn't* work on Intrepid for me
<maxb> (Well, a new enough snapshot from upstream does, but not the l-r-m one)
<directhex> hm, wiki suggests blacklisting a module
<directhex> that did the trick
<maxb> which module?
<directhex> acer_wmi
<directhex> completely breaks ath5k
<dtchen> directhex: see http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-jaunty.git;a=commitdiff;h=ee830266b8f7780717796fea891ae35fe48c2fdf
<directhex> dtchen, oh, neat. will that make it into the kernel that ships on jaunty (or into backports-modules)?
<dtchen> directhex: probably into jaunty proper
<directhex> afaik that would leave only hotplugging woe with the card reader as a "big"  AA1 glitch
<directhex> hm, fan seems to be not spinning, that was an annoyance in intrepid
* mthaddon changed the topic of #ubuntu-devel to: Python 2.6 issue #349467 | Archive: feature freeze | Ubuntu 9.04 Beta released! | Development of Ubuntu (not support, not app development on Ubuntu) | #ubuntu for support and general discussion for dapper-intrepid | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs
<maxb> Hmm, I just used requestsync, but it subscribed ubuntu-release, not ubuntu-main-sponsors, despite the fact I used -s and am not a core-dev
<maxb> that's a bug?
<neatojones> Hello.  I'm running Jaunty with latest updates and can't get the kernel module "loop" to load.  It doesn't appear to be in the kernel modules.  Does anyone know where I could get this for Jaunty?
<neatojones> I was expecting the module to be in /lib/modules/2.6.28-7-generic/kernel/drivers/block/loop.ko
<dtchen> neatojones: CONFIG_BLK_DEV_LOOP=y
<neatojones> So, I need to recompile the kernel with that?
<maxb> No, it means it's builtin
<dtchen> neatojones: no, it's compiled in now and hence not a module.
<maxb> 2.6.28-7-generic is far away from the latest updates, btw
<neatojones> oh. So, just run that command?
<dtchen> it was changed in 2.6.28-4.5
<dtchen> it's not a command; it's from the kernel configuration
<dtchen> i.e., you don't need to modprobe loop. it's already loaded.
<neatojones> thanks
<neatojones> I keep getting errors sayign that it isn't loaded
<neatojones> which is why I thought I needed to  load it.
<neatojones> ...but no wonder modprobe wasn't working :)
<neatojones> My script is returning this error:  raise OSError("Error loading kernel module %s" % (mod,))
<neatojones> oops...wrong part.
<neatojones> OSError: Error loading kernel module loop
<neatojones> maxb-sorry.  I misspoke on that :( I do have the new kernel.
<doctormo> Hey guys, I'm looking for translation tools for svg files.
<johanbr> doctormo: I'd be surprised if such a thing exists.
<johanbr> You can always make a script that replaces <text> tags in the svg file, I guess.
<doctormo> johanbr: Er, I'm after something that uses switch tags and languageSetting attributes propperly. svg does support i18n, just getting those into the launchpad translations is hard.
<johanbr> doctormo: oh, I see
<doctormo> johanbr: indeed, infact editing language specific text works in inkscape, it's just a matter of being able to generate a pot file and then recombine the po files back into the svg.
<dtchen> directhex: yes, the fix is available in -11.39-generic
<dholbach> good morning
<mrsteveman1> is functionality similar to delta rpms available in deb based systems like ubuntu, is such functionality planned, or is it not worth the potential problems it may cause?
<StevenK> mrsteveman1: Such as 'debdiff' ?
<LaserJock> StevenK: I think mrsteveman1 mean binary (.deb) diffs, like for -updates
<StevenK> Oh, so you only download the differences? Ick.
<LaserJock> that's how openSUSE does updates as an example
<mrsteveman1> does that just make things more difficult?
<mrsteveman1> i imagine there are moderate bandwidth gains to be had
<mrsteveman1> and lower costs for repo hosts
<YokoZar> mrsteveman1: lower bandwidth costs, higher storage costs (especially when you start storing large deltas)
<YokoZar> or rather large numbers of deltas
<pitti> Good morning
<pitti> calc: 348667> I'll look
<pitti> calc: hm, seems it didn't work well last time, so another retracing won't gain much, I'm afraid
<pitti> calc: it could be done manually with a few more debug symbols etc., but that's hard work
<pitti> I hope that this bzr branch & rosetta marriage in LP wasn't just an April's fool, this sounds like a great feature
<pitti> mvo: bug 348301 sounds a bit like interference with update-manager's changing of /etc/default/apport to enable it for upgrades?
<ubottu> Launchpad bug 348301 in apport "intrepid --> jaunty: apport wants to have user input" [Undecided,Confirmed] https://launchpad.net/bugs/348301
<pitti> mvo: I wonder what to do about it
<pitti> mvo: if u-m changes the file in exactly the way the new package ships it, it shouldn't prompt, right?
<mvo> pitti: right
<mvo> pitti: I can do that.
<pitti> mvo: how do you modify the file right now?
<pitti> mvo: just s/enabled=0/enabled=1/ ?
<pitti> mvo: I just wonder how we handle this for the final release, since we'll disable apport for it
<pitti> mvo: will you disable the temporary apport enabling in u-m too for final, or will that stay?
<slangasek> mdke: wow; I knew it was safer to rmdir in the postinst, but I didn't realize it would be proven that quickly :-)
<mvo> pitti: I want to disalbe the enabling of apport  for RC
<pitti> ah, ok
<mvo> pitti: yes, just the sed equivalent in python
<pitti> mvo: hm, I wonder what it's complaining at then
<mvo> pitti: its modifiyng the intrepid file, but the jaunty file has a addtional line in it
<pitti> ah, of course
<pitti> # you can temporarily override this with
<pitti> # sudo force_start=1 /etc/init.d/apport start
<mvo> yes
<mvo> I can copy the jaunty version over and modify that, that should work
<mvo> eh, no need to modify :)
<mvo> but copy it iover
<pitti> mvo: good idea, you'd extract it from the .deb?
<mvo> pitti: good idea, then it would also automatically  be disabled when you disable it in the deb
<mvo> pitti: I check it out how robust this will be, I do not want to add late breakage :)
<pitti> mvo: it indeed sounds intrusive, downloading that deb first, extracting, etc.
<pitti> mvo: perhaps just add the current jaunty conffile for now, and disable the code for final?
<mvo> pitti: yeah, and the more sophicstiacted code for karmic
<mvo> thanks pitti!
<pitti> mvo: also, I don't plan to change that conffile again for karmic (except for enabling/disabling)
 * pitti hugs mvo, danke
<pitti> mvo: erm, hang on
 * mvo hangs
<pitti> mvo: why do we have to change the conffile in the first place?
<pitti> # you can temporarily override this with
<pitti> # sudo force_start=1 /etc/init.d/apport start
<pitti> it could just call that?
<pitti> mvo: or does libapt read the conffile itself?
<mvo> pitti: this is not available in intrepid yet, is it? I need to start the intrepid version
<pitti> mvo: dang, you are right
<pitti> also, this force_start won't trigger python
<pitti> nevermind for now
<mvo> ok
<Mez> bug 350732
<ubottu> Launchpad bug 350732 in asterisk "IAX2 encryption: calls end abrutly due to normal packet loss" [Undecided,Confirmed] https://launchpad.net/bugs/350732
<pitti> seb128: the retracers all break down due to new LP and p-lp-bugs
<pitti> seb128: the heck with it, I'm working on the launchpadlib migration now
<seb128> great ...
<seb128> pitti: thanks
<pitti> let's not waste any more time on fixing plpbugs
 * pitti invokes a new PPA bzr commit -m 'lazily log into Launchpad, so that bug reporting does not need it'
<pitti> WTH?
<pitti> https://edge.launchpad.net/~pitti/+archive/apport-retracer I meant to copy
<pitti> that's how you reveal s3kr1ts, copy&paste errors..
<directhex> the great thing about having 2 clipboards is you can never be sure which one gets used!
<pitti> cprov: multi-ppa and copying between them is soooo awesome!
 * pitti hugs cprov
<seb128> pitti, mvo, slangasek: ok, so gnome-screensaver breaks after 2.24 to 2.26 updates
<seb128> ie if you still have the old version running after upgrade and lock the screen it doesn't unlock
<seb128> but display a flickering screen with no password entry
<seb128> I didn't upload 2.26 yet due to that
<seb128> do you think it's a blocker (ie we should not update until that's solved)?
<pitti> seb128: asked the other way around, what would we lose by not updating?
<seb128> pitti: NEWS summary is on bug #345107
<ubottu> Launchpad bug 345107 in gnome-screensaver "Please, sponsor gnome-screensaver 2.26.0 to jaunty" [Wishlist,Triaged] https://launchpad.net/bugs/345107
<seb128> several bug fixes but nothing crutial I think
<seb128> we don't want to stay on 2.24 for ever
<seb128> but we can for sure wait next cycle and see if somebody fixes the issue or have the cycle to work on it
<pitti> if we can't find a way to kill the old screensaver on upgrade and start the new one (if the old one was running), I guess that's a valid fallback
<seb128> that would unlock locked session
<Mithrandir> pitti: you're on vendor-sec, aren't you?  What's the address?
<directhex> seb128, so do it in reverse. is it possible to start the new daemon then kill the old one, leaving no period of unwanted unlockedness?
<pitti> Mithrandir: I haven't been any more for years
<seb128> directhex: you can't have 2 instances running no
<seb128> directhex: and how would you make sure that nobody open a menu or something during the split second when there is no screensaver which would prevent locking
<directhex> seb128, well, that's why i'm suggesting that having two instances briefly is better than no instances briefly
<seb128> doesn't work
<seb128> you can't run 2 instances and the first one already grab the screen, would be complicated to do
 * pitti happily sees the apport python dup checker run with launchpadlib
<tseliot> pitti: I've sent an email to the mailing list about bug 320632 as you suggested. Just FYI
<ubottu> Launchpad bug 320632 in xfree86-driver-synaptics "tap-to-click and edge-scrolling broken in Jaunty" [Medium,In progress] https://launchpad.net/bugs/320632
<pitti> tseliot: great, thanks!
<tseliot> np
 * ogra wonders why ubiquity never selects "nodeadkeys" by default in german installs
<thekorn> pitti, great news, so apport is not depending on py-lp-bugs anymore?
<pitti> thekorn: it still does in jaunty
<pitti> thekorn: but I uploaded the launchpadlib branch packages to https://edge.launchpad.net/~pitti/+archive/apport-retracer now
<pitti> thekorn: and I'm in the middle of deploying those to the retracers
<gopogo> hi
<pitti> thekorn: uploading this to jaunty involves a FF and a MIR for python-launchpadlib
<pitti> I'll file those, but I wanted to roll this out now
<pitti> thekorn: since p-lp-bugs is broken again with today's LP rollout
<gopogo> Can I use Ubuntu remix on standard laptop
<pitti> jaunty chroots now seem to work as well
<thekorn> pitti, broken p-lp-bugs, I know :(
<gopogo> I want to install on my dads laptop
<pitti> thekorn: but now I don't care any more :)
<ogra> does any gernam in her use the default german Xorg keymap instead of nodeadkeys ?
<thekorn> pitti, :) that's fine
<pitti> ogra: nodeadkeys FTW (but I'm usually using US layout)
<ogra> pitti, right, its the only default i have to change in all my live installation tests and i was wondering if selecting nodeadkeys as a default wouldnt be cleverer
<ogra> i personally dont know anyone not using nodeadkeys
<pitti> well, I find it a "programmers" vs. "letter writers" issue
<pitti> my wife occasionally needs accents
<pitti> and she doesn't do shell backticks, etc.
<ogra> hmm
<ogra> i wonder if we should do a strawpoll on the de ML
<pitti> I have no strong opinion about the default, but it's easy enough to change in ubiquity, thus *shrug*
<gopogo> Can I use Ubuntu remix on standard laptop ..........I want use it on Dads 15 inch centrino laptop with 1 gb ram
<ogra> i know historically in dexconf it was alway defaulting to nodeadkeys
<dholbach> ogra: the answer will depend on where you ask, I guess :)
<ogra> *always
<pitti> gopogo: I don't see why not; -> #ubuntu please, though
<gopogo> i am invisible ;-
<ogra> dholbach, yeah, its tricky
<ogra> but i remember all my debian installs as well as all my early ubuntu installs defaulted to it ... i think that change came with ubiquity
<gopogo> pitti: can UNR run on non atom cpu like centrino
<ogra> gopogo, thats really a question for #ubuntu
<gopogo> i dont think anybody knows there
<cjwatson> ogra: no, it did not come with ubiquity.
<cjwatson> ogra: console-setup is more likely
<ogra> cjwatson, ah
<ogra> do we inherit it from debian ?
<cjwatson> ish
<cjwatson> it's a complete rewrite of the old console keyboard handling infrastructure
<ogra> ah, k, then i wont complain ...
<cjwatson> and it does affect how the X keymap is chosen
<ogra> i just notice that i always have to do these two extra clicks if i do test installs
<cjwatson> well, it sounds like a legitimate complaint, I'm just explaining how it came about
<ogra> yeah
<ogra> pitti is right though, it migth be different for textwriters
<cjwatson> although for the record I can't find any evidence that nodeadkeys used to be used by default
<ogra> hard to judge from a programmers POV :)
<cjwatson> still looking around and trying to remember how the old stuff works
<pitti> ogra: dead keys are a programmer's nightmare, but so is the entire German layout in the first place :)
<ogra> heh
<ogra> well, depends :)
<ogra> cjwatson, it was seeded by dexconf iirc
<pitti> because vim keybindings, C/Python operators, LaTeX commands etc. were all designed to be convenient to type on the US keyboard
<cjwatson> ogra: no
<cjwatson> ogra: xserver-xorg.postinst chose deadkeys or not based on the installer-selected keymap
<ogra> ah
<ogra> i thought i saw something hardcoded in dexconf, but i might misremember
<ogra> its a while ago i looked at it
<cjwatson> ogra: ah, here we go, you're right, it did use to be nodeadkeys by default
<ogra> right
<cjwatson> console-keymaps-at/keymap's Choices has de-latin1-nodeadkeys and not de/de-latin1
<ogra> at least in my debian installs i'm sure
<cjwatson> ogra: I'd like to have the output of a straw poll of course
<ogra> yeah, i'll do one though i'm not actually sure where ... ubuntu-de might generate different output than ubuntu-devel ... the latter surely reaches more people
<ogra> (or -devel-discuss)
 * ogra thinks he'll do two 
<cjwatson> I care more about "typical" German users than developers
<cjwatson> whatever "typical" might mean
<gopogo>  can UNR run on non atom cpu like centrino  ?
<directhex> gopogo, absolutely
<gopogo> thanks
<directhex> gopogo, the unr images on cdimage are for i386 or amd64, and will run on any system regular ubuntu does
<liw> ime developers tend to prefer non-localized systems, or only lightly localized systems, and have an unnaturaly fancy towards non-standarda layouts :P
<gopogo> can I convert unr iso to usb img ?
<directhex> why not doenload the usb image?
<directhex> http://cdimage.ubuntu.com/releases/9.04/beta/ubuntu-9.04-beta-netbook-remix-i386.img
<mdz> mvo: which dist-upgrader log file would show the conffile prompts?
<liw> mdz, I _think_ it's term.log
<mdz> liw: ah, yes it is, I found an example. thanks
<mvo> mdz: main.log will have it
<mvo> (and term.log as well)
<cjwatson> so I've been a little worried about our bug-fixing performance over time, and regenerated my graph of bug-fixes-uploaded-per-month a few days back to have another look at it
<cjwatson> http://people.ubuntu.com/~cjwatson/bugfix-history/plots/month-fixed.png
<cjwatson> look at that spike last month! and I'm not sure that even includes most of the post-beta fixes
<dholbach> holy moly!
<cjwatson> (generated based on whatever was in my mailbox at 2009-03-27 19:43 local)
<dholbach> good work everybody :)
<gopogo> is webkitkde in ubuntu repo ?
<mdz> cjwatson: nice!
<pitti> heh, nice december UDS/christmas break
<cjwatson> yes, some events are very visible on this kind of graph
 * cjwatson regenerates it. Takes a while since it has to plough through lots of mailboxes
<liw> I'm supposed to be able to edit the kernel command line in grub, right? whatever I try ends up in rebooting directly into BIOS
<liw> hm, no, I can delete an argument ("quiet") and that works...
<mdz> liw: worked for me last time I checked
<liw> perhaps it _is_ the arguments I am trying ("iommu=soft" and "ata_ignore_hpa=0") then
<liw> or perhaps Ubuntu really, really hates me, and not just my hard disks *sigh*
<directhex> it's totally personal
<pitti> seb128_: okay, please delete all apport cron mail you got until now
<seb128_> pitti: ok
<seb128_> pitti: did you manage to fix the retracers?
<pitti> seb128_: I just finished with upgrading them all to launchpadlib
<pitti> there was some fallout
<pitti> seb128_: if you ever have to fix something, https://edge.launchpad.net/~pitti/+archive/apport-retracer has the extra packages now
<pitti> seb128_: launchpadlib/wadllib backports, and apport packages from the launchpadlib branch for all supported releases
<seb128_> pitti: ok
<pitti> all retracers are on auto again
<pitti> seb128_: due to the backport, hardy/intrepid now get the "autoclosing on obsolete pacakges" and some robustness fixes as well now
<pitti> seb128_: I'll have lunch now, and deal with potential fallout in an hour
<pitti> until then, all retracers should have run at least once
<seb128_> exellent
 * seb128_ hugs pitti
<seb128_> good work!
<pitti> *phew*
<pitti> it was overdue
<pitti> but quite some work
<pitti> seb128_: I'm glad that Spads responded immediately to fix ronne's firewall rules
<kwwii> hey seb128_, I subscribed you to the bug about the murrine engine version, so you don't forget ;)
<seb128_> kwwii: I don't forget but I though you said they would roll a tarball?
<kwwii> seb128_: not that I know of, all I know is that it is fixed in svn
<seb128_> ok
<kwwii> someone might have a package ready, let me ask around
<seb128_> it's easy enough to backport a change
<seb128_> I was just waiting on a new tarball
<kwwii> seb128_: seems like someone did it already...https://launchpad.net/%7Esuraia/+archive/ppa/+files/gtk2-engines-murrine_0.90.1-0suraia1~jaunty1_0.90.2-0ubuntu1+svn170~jaunty1.diff.gz
<seb128_> well they should open a sponsoring request bug then
<seb128_> it will be faster for me to backport the svn change than to chase ppa versions
<kwwii> hrm, ok...so what should I do? what would be faster/better?
<seb128> nothing?
<kwwii> lol
<seb128> if you know the guy who has the ppa you can ask him to open a sponsoring request
<seb128> if he doesn't I will just backport the change later today
<kwwii> don't know him, and his email address isn't public, but I am sending him an email through launchpad, I'll get back to you
<seb128> ok
<cjwatson> http://people.ubuntu.com/~cjwatson/bugfix-history/plots/month-fixed.png updated; those extra four days at the end of the month gave us another 200 bugs fixed or so
<cjwatson> obviously it drops way down again since April only just started
<cjwatson> IOW last month we fixed around 60% more bugs than any previous month on record
<liw> yay for bug fixing
<mdz> mvo: when you have a moment, could you have a look at bug 353768?
<ubottu> Launchpad bug 353768 in ekiga "Upgrade from 3.0.1-1ubuntu2 to 3.2.0-0ubuntu1 held back" [Undecided,New] https://launchpad.net/bugs/353768
<mvo> mdz: sure
 * mvo looks
<pitti> seb128: argh, now the launchpadlib errors start to strike
<mvo> mdz: hm, tricky, trivial to workaround with the release-upgrader, but there should be a better generic way
<mdz> mvo: should I go ahead and force the upgrade on my system, or is there useful debugging I could do?
<mvo> mdz: forcing it should be fine, I can reproduce it here
<seb128> kenvandine_wk: ^
<kenvandine_wk> seb128: thx :)
<calc> pitti: oh ok, np
<pitti> seb128: ok, please delete retracer cron mails again; should be fixed now *knocks on wood*
 * seb128 hugs pitti
<NCommander> cjwatson, good morning (or afternoon), did you get a chance to look over the possible solutions for shadow? (my patch didn't work after shadow finished building so back to square one for me)
<cjwatson> not yet
<cjwatson> I've been trying to fix RC installer bugs all day
<NCommander> That Wubi one looks like a pain
<cjwatson> NCommander: oh, that one I'm leaving alone
<kwwii> seb128: bug made for sponsoring the murrine engine from the private ppa #353832
<seb128> kwwii: thanks
<RicardoPerez> tedg: Hi. I have a problem with indicator-applet. I've Evolution & Pidgin running, and both apps appears in the applet menu. However, sometimes one of them dissappears. Now, for example, Pidgin is running but its menu option has gone, so I can't select it in the applet and therefore I can't open the buddy list. This morning happens with Evolution, too
<RicardoPerez> tedg: Do you know if this is a known issue?
<tedg> RicardoPerez: Yes, it's a known problem, there's a fix in trunk, but I haven't made a release yet as I'm working on other fixes.
<RicardoPerez> tedg: Great, so I don't need to submit a new bugreport, right?
<tedg> RicardoPerez: It involves system and session bus ids matching and removing each other.  So if you don't log out and log in often, it should happen less :)
<tedg> RicardoPerez: No, you shouldn't need to.  You're welcome to comment on bug 345599 though.
<ubottu> Launchpad bug 345599 in indicator-applet "indicator applet disappears" [High,In progress] https://launchpad.net/bugs/345599
<RicardoPerez> tedg: Oh, well, actually I never log out after rebooting or shutdown-restart...
<tedg> RicardoPerez: Rebooting is your problem there.  Don't do that, no kernel upgrades ;)
<RicardoPerez> tedg: Peeking into it
<RicardoPerez> tedg: Mmmm... According to the bug 345599, it seems that the problem is notification icon dissappearing. My issue is that a menu entry dissappears, not the icon
<ubottu> Launchpad bug 345599 in indicator-applet "indicator applet disappears" [High,In progress] https://launchpad.net/bugs/345599
<tedg> RicardoPerez: It's the same in that if you only have one of the two apps running, the whole thing will disappear.
<RicardoPerez> tedg: Oh, that sounds reasonable :) Can I try and test the trunk version in order to make sure?
<tedg> RicardoPerez: Sure!  bzr branch lp:indicator-applet
<RicardoPerez> tedg: That command downloads the source, right? Can I build a .deb binary package using that source?
<tedg> RicardoPerez: Not directly.  I haven't merged it into the packaging branch.
<RicardoPerez> tedg: But I can "make install" without fear, don't me? ;)
<tedg> RicardoPerez: Heh, a healthy amount of fear would probably be good ;)
<tedg> I wouldn't do it on a production system or anything like that.
<RicardoPerez> tedg: Mmmm... I'll try to do it, I'm brave :) Thanks a lot!
<mdz> mvo: regarding bug 349725, do we actually allow upgrades from 8.04 to 9.04 in one step?
<ubottu> Launchpad bug 349725 in doc-base "8.04->9.04-beta updgrade: Could not install 'base-passwd'" [High,Triaged] https://launchpad.net/bugs/349725
<mvo> mdz: kubuntu requested it
<mvo> mdz: they want to support kde3 -> kde4 upgrades without going over intrepid
<mvo> we will also need it for the next lts
<mdz> mvo: interesting, I see
 * mvo was a bit suprised aobut this too
<calc> Riddell: shouldn't konqueror be registering alternatives for www-browser and x-www-browser?
<Riddell> calc: yes, bug 353678
<ubottu> Launchpad bug 353678 in kdebase "Konqueror does not appear as a choice in update-alternatives" [Low,Confirmed] https://launchpad.net/bugs/353678
<calc> Riddell: ok
<calc> Riddell: also seems that sensible-browser is bunged
<calc> sensible-browser is only special cased for gnome and does not use xdg-open at all
<LaserJock> mdke: around?
<mdke> LaserJock: (In case I'm not around at the moment, please provide a bit of information about what you want and I will respond when I get back)
 * LaserJock curses mdke's autoresponder
<sabdfl> james_w, kenvandine_wk: apparently you rock! re gajim. thanks.
<kady> calc: hello
<calc> kady: hello
<kady> calc: how are You?
<calc> kady: ok, who are you? :)
<kady> Just checking of you are the person to talk to about state of OO.o ?
<kenvandine_wk> sabdfl: thanks... i want to see more stuff using the cool indicator stuff!
<calc> kady: yes
<calc> kady: whats up?
<kady> calc: what is the state of the KDE 4 builds
<kady> I heard they are turned off due to problems ?
<calc> kady: there is no KDE 4 support in OOo period
<NCommander> cjwatson, so I determined the reason behind the 0 for password expiration age getting written to the shadow file; we set that via login.defs, but removing unfortunately does not solve the issue. It seems if password age == 0, you MUST change your password even if the password aging fields are blank.
<calc> kady: at the source level, so no way to really enable it for builds, it only halfway worked to compile but it didn't actually function properly since OOo does not support KDE4
<kady> calc: not even disabled?
<kady> calc: any plans to?
<calc> kady: no there is no code written to support KDE4 in OOo
<calc> kady: maybe long term, there is a novell guy who does all the KDE support, but he does a lot of other work too so hasn't had time to write kde4 support for OOo
<calc> kady: if you want to write the support you are welcome to :)
<kady> calc: That's what I was trying to get to who is in charge of that
<kady> there is a kde.oo.o site that hasn't been touched for years
<NCommander> cjwatson, thats an intentional behavior, so now the question is; what do we do to get that field blank?
<kady> the "team" is dead
<kady> ?
<kady> sounds like it if the one person who can do anything is not even working on OO.o
<calc> kady: jan holesovsky (Kendy on irc) is who works on it, the official novell build is called go-oo / ooo-build which is available at go-oo.org
<kady> go-oo is what Ubuntu uses I heard
<kady> No idea of the truth of that
<calc> kady: yes it is
<calc> kady: he's mentioned on that page you linked to: "Jan Holesovsky /kendy at openoffice org/"
<kady> ok thanks
<calc> he still does a lot of work on OOo but just doesn't have time to fix up for KDE4
<calc> i think Novell doesn't ship kde4
<kady> Do you know what were the problems they were having
<kady> calc: They have nightly builds of KDE4 so ....
<calc> kady: ah ok
<calc> kady: i think its just a time issue of he hasn't had time to write the kde4 file dialog and maybe some other stuff
<calc> i do know at least that the kde4 file dialog is not done
<kady> calc: might be better to try and build somethign a little more long term than a 2 week push then
<kady> KDE4 is still in flux and I would expect thigns needt o get tweaked as time goes by and OO.o and KDE4 improve
<kady> might make more sense to try and get three interested people to work with this
<kady> thanks
<kady> I'll try and contact him
<calc> ok
<kady> calc: Does Ubuntu plan to package OO.o extentions they way they do FF ?
<askand> Hi!  I remember seeing a nice tool that helps you get the right format in the changelogfile? what was that?
<LaserJock> askand: dch ?
<calc> kady: if someone wants to do it they can
<calc> kady: i have no plans to package all the extensions in the world myself
<calc> kady: we have a few extensions packaged and maybe a few with each new release will be done, but not all of them by any stretch
<askand> LaserJock: thanks
<kady> calc: oh no not at all :) packaging all the FF extensions would be an exercise in exhaustion that I hope would be done as a sacrifice in the name of science :)
<kady> but the idea is to provide useful functionality without having people wander around the net installing things
<kady> I would argue that OO.o is probably more in need of that service than FF
<lamont> ubuntu-bug /usr/bin/xvnc4viewer
<lamont> Error showing url: Failed to execute child process "/usr/lib/firefox/firefox" (No such file or directory)
<lamont> does that mean it filed the bug? (which would really be better with _some_ form of content...
<ogra> lamont, from my experience it treis to log in with your browser and makes you add subject and description
<ogra> *tries
<lamont> ah, so that'll be _2_ bugs to file manually. kewl
<ogra> so i would doubt it filed anything
<lamont> searching lp for bugs in the package in question yielded a clean slate, wasn't sure if it was using the mail interface, or just completely faceplanting
<ogra> i would guess it uses SENSIBLE_BROWSER ot x-www-browser
<ogra> just a guess but i think w3m or lynx might work as well
<lamont> it's probably related more to the fact that there are 2 instances of firefox (aka SENSIBLE_BROWSER) in 2 profiles running
<sabdfl> kenvandine_wk: you and me both :-)
<lamont> morning sabdfl
<sabdfl> hiya lamont, 's a good season for firefighting :-)
<kenvandine_wk> sabdfl: got other things you can suggest?
<lamont> 'struth
<sabdfl> kenvandine_wk: is gwibber using the Messaging Menu?
<greg-g> segphault has a bzr branch for that support
<sabdfl> love to see that in the default install for 9.10 :-_)
<greg-g> sabdfl: we'll see what he and the team can do :)
<kenvandine_wk> sabdfl: there is a branch, yes
<kenvandine_wk> sabdfl: i am using it :)
<greg-g> kenvandine_wk: this one right?  https://code.edge.launchpad.net/~segphault/gwibber/gwibber-indicate
<kenvandine_wk> and providing some feedback to ryan :)
<kenvandine_wk> greg-g: yes... if you have indicate-python installed
 * greg-g nods
<kenvandine_wk> sabdfl: once i get those python bindings sponsored :)
<Laney> kenvandine_wk: If you want that in Jaunty you should seek a freeze exception
<Laney> but it is now exceptionally late
<Laney> i'm happy to review it after that though
<kenvandine_wk> ok
<jcastro> sabdfl: ryan is merging messaging indicator support today or tomorrow, should be in jaunty this week if all goes well.
<jcastro> sabdfl: pending the python bindings of course
<sabdfl> rockalong
<askand> Who has the final saying on what should be included by default in Ubuntu?
<sabdfl> FINAL say?
<sabdfl> me
<sabdfl> but there are quite a few better places to start.
<askand> sabdfl: I have posted to the ubuntu-devel-discussion list :)
<askand> I was just curious
<sabdfl> that's a very good place to start.
<askand> sabdfl: Haha, didn't know that you were the founder of Ubuntu and actually the one who has the final say, thought you were just some random helpful guy with hybris :)
<sabdfl> tada, i'm both ;-)
<highvoltage> askand: he also says that "Linux is a phenomenal facebook device" :)
<calc> anyone know if there is way to use evolution to send an email from the command line?
<calc> i need to reset my debian password but i don't have local mta setup which aiui is what 'mail' requires
<azeem> why is sending an email from the command-line required to reset your debian password?
<calc> azeem: apparently you have to do the following: https://db.debian.org/doc-mail.html
<calc> echo "Please change my Debian password" | gpg --clearsign | mail chpasswd@db.debian.org
<bryce> sabdfl: :-)
<calc> i suppose possibly typing that in and making evolution do the equivalent of clearsign will work as well
<walters> calc: like 5 years ago i successfully used evolution's gpg signature stuff to do that, but i wouldn't be surprised if it regressed now
 * calc isn't sure if there is an easy way to do that in evolution
<azeem> calc: or just c&p the first two pipes into evolution's new mail body?
<azeem> but I'd try what happens if you just send a signed mail first
<calc> azeem: iirc i've tried that but it doesn't quite work for some reason
<calc> but haven't tried just a signed email
<calc> walters: ah it did work with just signing it :)
<slangasek> NCommander: so, texlive-bin still ICEs on arm with gcc 4.3; are there optimization tweaks we could try in order to get it building?  I'm not keen to have to re-promote gcc-4.2 to main for a single package
<NCommander> slangasek, I can mess around with it, no promises if I can fix it though :-/
<slangasek> I just got access back to an arm again, I'm poking at it a bi
<slangasek> t
<NCommander> slangasek, if you want superuser access to an ARM box, you can use one of mine.
<slangasek> already sorted here
<NCommander> slangasek, ah good
<directhex> at least ARM works in qemu
<directhex> i could never get sparc/ppc going
<mdke> LaserJock: now I am
<mdke> LaserJock: I guess for the edubuntu-docs upload, you'll need to ship the symlink at /usr/share/gnome/help/libs to point at /usr/share/ubuntu-docs/libs and install the edubuntu libs there, to cater for the case where edubuntu-docs are installed on their own
<maco> tedg: i'm in gnome now, and yes the envelope is visible
<tedg> maco: Great!
<maco> tedg: is there a bug filed for the "is online" notifications going to the indicator applet instead of only the messaging notifications going there, for pidgin?
<tedg> maco: It's not a bug, it's a requested feature!  Basically so you can respond to them quickly if they're important.
<maco> oh
<tedg> maco: They disappear pretty quickly.
<maco> they disappear out of there?
<maco> i thought the stuff in the indicator applet was supposed to persist
<tedg> Yes, it's only recent logins.
<maco> ah ok
<maco> nice
<tedg> There's a request to increase the length of time, so I'll probably do that here shortly.
<tedg> They're only there for 15 seconds now.
<maco> also, does new gdm know how to handle user switching and logouts and things using dbus? or is it still the domain sockets I saw comments in FUSA's code alluding to?
<tedg> Yes.  The current gdm is sockets, the new one is DBus.
<maco> is jaunty current or new?
<tedg> Current in Jaunty.  GNOME upstream is actually a different one.  We're lagging.
<tedg> GNOME upstream is "new".
<maco> ok. and fusa should be updated to use the dbus stuff in karmic then, so it stops crashing when it cant find domain sockets in kdm?
<tedg> The plan is for Karmic to make it understand both GDM and KDM so that users don't have to worry about that anymore.
<maco> yay!
<LaserJock> mdke: I think I'll rather just not use libs/ unless you have an  objection
<LaserJock> mdke: we're only shipping one doc these days, I don't see as much value in using "common" files these days
<mdke> LaserJock: so you'll just stop using entities at all?
<mdke> LaserJock: or ship them in the document itself?
<LaserJock> mdke: the easiest would be to just ship them with the doc itself
<LaserJock> you end up having a copy for each translation, but I'm not sure if that's a big deal
<LaserJock> *or* I could ship the .ents in /usr/share/edubuntu-docs/
<LaserJock> I just don't think we necessarily need to overlap namespace
<mdke> pitti: no docs for UNR as far as I know yet
<askand> tedg: It's not a bug, it's a requested feature, but is there a bug filed for the "is online" notifications going to the indicator applet  anyway? :)
<tedg> askand: I don't think so.  Feel free to start one. :)
<askand> tedg: nah, it propably will not be changed so close to release anyway, I think I can learn to live with it :)
<maco> i vote in favor of configuration options next time
<maco> and im totally a gnome user at the moment, so no kde comments!
<maco> :P
<maco> uh....i also dont recommend trying to launch xmonad while a gnome session is running O_O
<kirkland> pitti: cool, working on the update-notifier ecryptfs bits ... let me know if you need my help!
<NCommander> cjwatson, I'm just been made aware that we're having build queue issues with armel; if you upload anything thats important for arm (like installer bits), I'll be around for most of the day/night so feel free to ping me for rescores (I'm rescoring your last uploads)
<NCommander> cjwatson, I also uploaded a potential fix for the useradd issue
<infinity> NCommander: Well, the "issue" is that there are 3 giant sources building right now.  Hard to fix that, unless we want them killed.
<NCommander> infinity, I've gotten reports that builds are getting stuck in the queue; base-installer for instance didn't build infront of the mass rebuilds.
<infinity> NCommander: Yeah, that sometimes happens too.  Especially if a package is given-back in the web UI and gets a score of 0. :/
<NCommander> infinity, yeah, I keep pushing builds to the front of the queue, like KDE :-/
<xq> is there a definite issue, that has been confirmed, with the usb boot build of jaunty beta?
<slangasek> lool, NCommander: texlive-bin builds fine on armel, with gcc-4.3 -O0, fails with -O1; any objections to making that change?
<superm1> slangasek, have you been doing much experimentation with already installed systems switching to grub-pc?
<slangasek> superm1: not yet; you?
<superm1> slangasek, well I did back in 8.04, and it was OK.  I was just doing some experimentation with 9.04 stuff and it's looking like it's not defining the root line properly wrg to UUIDs now
<NCommander> slangasek, no objections here
<slangasek> superm1: ah; I think UUID handling is an open item in the spec, isn't it?
<superm1> slangasek, no I had thought upstream integrated UUID support, but maybe so maybe it's just something wrong with the postinst
<slangasek> I thought the syntax between the two is different
<superm1> slangasek, and if I skip grub1 and install grub2, it uses UUIDs and does the right thing.  it's just when transitioning, something doesn't get written out write in grub1's menu.lst
 * slangasek nods
<slangasek> what's the authoritative way to find out what optimizations a given -O level implies?
<slangasek> (since g++-4.3's manpage appears not to accurately define these for armel)
<azeem> slangasek: -dumpspecs maybe?
<azeem> sorry
<mathiaz> sbeattie: just installed apport on one of my jaunty vm - gdb was pulled in.
<mathiaz> sbeattie: I'm not sure we want to have gdb installed by default on every server install (in the case we choose to install apport by default)
<mathiaz> sbeattie: same comment for python-xdg
<sbeattie> mathiaz: hrm, okay. I wonder how needed it is for the backtrace.
<sbeattie> mathiaz: can you file a bug on those against apport and subscribe me to it? Thanks.
<mathiaz> sbeattie: ok
<slangasek> azeem: "sorry"?  (nothing in -dumpspecs seems to cover this, anyway)
<azeem> "sorry" for saying something without checking first
<sbeattie> mathiaz: I'll talk to pitti about it and the issue I have saving reports; I really think it would be valuable to have apport installed on the server by default, particularly if we get more per-package apport hooks -- look at the ones for apparmor and mdadm for the kinds of information we can collect.
<mathiaz> sbeattie: agreed.
<cjwatson> NCommander: there's no special rush for installer builds just now
 * sbeattie has a goal of increasing the number of apport hooks for server packages in the kranky kitty devel cycle.
<cjwatson> NCommander: I can rescore them myself if I need to, too ;-)
<cjwatson> slangasek: the info documentation isn't all that bad is it?
<superm1> slangasek, well this takes care of the problem http://pastebin.com/f3a9badc8 , but ignores the situation of people who go and use a separate root line in menu.lst (whereas the previous approach ignored the more common case of people who used UUIDs)
<mathiaz> sbeattie: bug 354172 for your pleasure
<ubottu> Launchpad bug 354172 in apport "gdb and python-xdg required dependencies for apport?" [Undecided,New] https://launchpad.net/bugs/354172
<cjwatson> NCommander: (thanks, though)
<sbeattie> mathiaz: thanks.
<slangasek> cjwatson: is it guaranteed to be authoritative?  I'm trying to find the key optimization causing an ICE on armel, and the manpage claims -O1 is equal to a set of optimizations which is clearly incomplete
<mathiaz> sbeattie: so if I want to write hooks for mysql-dfsg-5.0, what would be the name of the apport hook file?
<mathiaz> sbeattie: source_mysql-dfsg-5.0.py?
<NCommander> cjwatson, I didn't know you were a buildd admin
<cjwatson> NCommander: tech board
<cjwatson> slangasek: no, I wouldn't like to say guaranteed
<NCommander> I didn't know the tech board were in the buildd admin group
<cjwatson> the tech board *owns* the buildd admin group
<NCommander> I didn't know the tech board owned the buildd admin group ;-)
<sbeattie> mathiaz: yes, source_[source_package_name].py
<the_dark_warrio> when running 'gksu gedit', the screen should get faded by a semi-transparent window, but it isn't covering my hole screen, which I think is due to the high res (1680x1050). Is this a known bug? Should I report it?
<slangasek> superm1: brain is returning ENOSPC; file bug + target?
<superm1> slangasek, sure will do
<slangasek> cjwatson: right, the info docs lie in the same way as the manpage
<cjwatson> d'oh, sorry for misdirecting you then
<slangasek> n/p
<slangasek> would be nice if there were a commandline arg to gcc/g++ to spit it out :/
<cjwatson> I think some of the optimisations don't actually correspond to independent -O options
<slangasek> heh - indeed, apparently -O1 -fno-tree-ter works, but -O0 -ftree-ter also works
<TheMuso> /c/c
<cjwatson> NCommander: quick glance over my comments on bug 349504? might be able to upload tonight if you can sign off the last point
<ubottu> Launchpad bug 349504 in shadow "if system date is set to 01-01-1970 users are enforced to update their password" [High,In progress] https://launchpad.net/bugs/349504
<NCommander> Oh ****
<NCommander> I respan the debdiff to fix that
<NCommander> I guess I uploaded the old one by mistake
#ubuntu-devel 2009-04-03
<cjwatson> I don't mind, I can easily munge it to fix that. More interested in the question about the other shadow tools
<NCommander> Looking at them now
<NCommander> Don't see anything that jumps out at me, I just need to skim usermod before I say yes
<cjwatson> well, put it this way, I know that some of them will suffer from the same kind of bug, but want to know whether we care :)
<NCommander> cjwatson, usermod doesn't, userdel doesn't care
<NCommander> passwd is the only other one
<NCommander> It probably has the same issue
<cjwatson> chpasswd?
<cjwatson> we use that in the installer
<NCommander> no, just regular password
<NCommander> *passwd
<NCommander> Oh
<NCommander> ILet me check both
<cjwatson> ./src/chpasswd.c:324:   long now = time ((long *) 0) / (24L * 3600L);
<NCommander> Anything that will update the password field might be affected
<cjwatson> and later on:
<cjwatson>                         newsp.sp_lstchg = now;
<NCommander> Yeah, that would do it
<NCommander> Same with passwd.c
<NCommander> Sorry, I had a brainfart and forgot to check the rest :-/
<cjwatson> libmisc/pwd2spwd.c, src/newusers.c, and src/pwconv.c too
<cjwatson> though I doubt that those would actually be used in practice
<cjwatson> (in this kind of context)
<NCommander> Does GDM gracefully handle password changes?
<NCommander> Actually
<cjwatson> well, not used in the installer, but of course somebody could call them by hand
<cjwatson> no idea but it uses PAM
<NCommander> if you change your passwd on 01-01-1970, it could be a problem
<NCommander> Because it could get stuck always prompting you to change the password until the clock is changed
 * NCommander would run into that problem on a Babbage board with a broken RTC
<NCommander> Let me respin the patch
<NCommander> This probably should go upstream
<cjwatson> change your password> well, right, hence why passwd needs to be fixed
<cjwatson> go upstream> yes, please do send it
<NCommander> cjwatson, I've got passwd, and chpasswd fixed
<slangasek> dendrobates: who's responsible for bug #347622?  marked critical, no assignee?
<ubottu> Launchpad bug 347622 in eucalyptus "in SYSTEM mode, VM ips are not automatically discovered by CC or NC on switched networks" [Critical,Confirmed] https://launchpad.net/bugs/347622
<NCommander> cjwatson, here's my current debdiff http://paste.ubuntu.com/143165/
 * NCommander is not sure how that bug meets the definition of an Ubuntu critical bug ...
<cjwatson> NCommander: still has the tab damage
<cjwatson> NCommander: and the duplicate patch file
<slangasek> pitti: would it be reasonable/appropriate to work around bug #336055 by forcing an iwlist wlan0 in pm-utils resume.d?  (I've considered doing this locally, since it's what I end up typing at the commandline after each resume anyway :P)
<ubottu> Launchpad bug 336055 in linux "Wifi driver fixes for age scan" [High,Confirmed] https://launchpad.net/bugs/336055
<NCommander> cjwatson, WTF? ...
<NCommander> argh
<NCommander> cjwatson, are we looking at the same patch?
<NCommander> oh wait
<NCommander> I'm a freaking idiot
<NCommander> cjwatson, http://paste.ubuntu.com/143171/ - I apologize, I'm freaking fried. Tab damage properly fixed, testing now
<cjwatson> NCommander: couple more bits of tab damage in passwd.c and newusers.c, but I can fix those - just in case you're sending upstream
<NCommander> cjwatson, I'll get it. I thought I nailed all the tab damage. What are you using to see it? (I turned on the vi tab ... thingy which highlights the difference)
<cjwatson> NCommander: rest looks fine
<cjwatson> NCommander: I'm just looking at the URL you posted, you can see it by the alignment
<NCommander> Its been too many hours in the day :-/
<cjwatson> no worries
<cjwatson> like I say, can fix it up at my end if your tests pass
<NCommander> as a general rule of thumb, I perfer to fix it on my end.
 * NCommander hates pushing work onto other's people plates
<cjwatson> sure, I don't like making people respin for trivial whitespace changes either though :)
<NCommander> cjwatson, where is upstream for shadow anyway?
<cjwatson> NCommander: a list on alioth.d.o apparently; README has details
<cjwatson> calc: can you explain to me the difference between myspell-en-us and hunspell-en-us?
 * NCommander orders dinner while this builds
<cjwatson> calc: bug 327821 appears to be because (a) myspell-en-us is installed as part of desktop, presumably due to a dependency from (lots of stuff) -> hunspell -> myspell-en-us | myspell-dictionary | hunspell-dictionary; (b) language-support-writing-en Depends: hunspell-en-us which Replaces: and Conflicts: myspell-en-us
<ubottu> Launchpad bug 327821 in livecd-rootfs "residual config in myspell-en-us after fresh install" [Undecided,New] https://launchpad.net/bugs/327821
<NCommander> *sighs*
<cjwatson> calc: the Replaces and Conflicts seems to suggest that hunspell-en-us is considered better in some way, but in that case I'm curious why it isn't hunspell's preferred alternative
<NCommander> I'm really fried, I just put my name where the credit card number supposed to go ...
 * NCommander found a bug ...
<reduz> dudes! dudes! I've been trying out the latest version of ubuntu 9.04 beta, which i upgraded to some days ago.. and out of nowhere the mouse went crazy and started to move around all by itself clicking everywhere! it even copypasted text all around between windows!!
<directhex> reduz, physical mouse, or laptop touchpad?
<reduz> physical regular everyday mouse
<reduz> the pointer, of course, i'm not drunk :)
<reduz> killed X (exited session) and started again and now it's fine
<NCommander> reduz, I think he meant was it a normal mouse or trackpad; I've had that issue with trackpads, but I haven't seen it with a normal mouse
<cjwatson> I find that once in a blue moon a mouse button gets stuck, and I need to whack random buttons a few times to unstick it
<reduz> ah yeah it's a regular standard $10 optical mouse
 * NCommander does a rmmod psmouse && modprobe psmouse to get his laptop's trackpad going again
 * TheMuso has had control/shift/alt buttons sticking, not physically, but in the computer's memory a fair bit, but thats often been a11y related./
<reduz> but here it's like, the mouse cursor starts moving by itself pushing all buttons
<reduz> only restarting X fixed it
<NCommander> TheMuso, can't be as bad my old laptop
<NCommander> TheMuso, having -8 memory errors is a bad thing :-)
<TheMuso> NCommander: SOunds like it.
<reduz> if it happens again, any idea what kind of info i can collect to pinpoint the problem?
<NCommander> cjwatson, chpasswd works, but it spits out a warning each time it updates a user so I need to move the warning code; same with pwconv. Will ubiquity freak out if there is any strerr output?
<cjwatson> NCommander: if ubiquity cares about the presence of stderr output in any way, it's a bug and I'll fix it
<cjwatson> it shouldn't
<NCommander> cjwatson, also, recommendations on how to better phrase the warning?
<NCommander> (or print it?)
<cjwatson> it seemed OK to me
<NCommander> It comes out like:
<NCommander> ystem clock set to Januar
<NCommander> ield will be omitted from
<NCommander> l be disabled on this acc
<NCommander> ...
<NCommander> copy and paste failure
<nohup> Hey, is this the right channel to ask about packaging a certain open source program?
<ScottK> nohup: #ubuntu-motu is better.
<nohup> ScottK, what does motu mean?
<ScottK-desktop> It means that's a better channel to ask about packaging a certain open source program.
<Snova> nohup: Masters Of The Universe. :) Packagers, though I'm not certain exactly what they do.
<nohup> haha, thanks Snova.
<akgraner> nohup: https://wiki.ubuntu.com/MOTU
<nohup> thanks akgraner
<akgraner> nohup: your welcome..
 * TheMuso likes Xubuntu's login artwork/layout change.
<NCommander> TheMuso, your running Xubuntu?
<NCommander> cjwatson, if your still awake, I posted a revised debdiff, tested to make sure it works as expected, and testbuilt in pbuilder. I also made sure the warning one printed once :-)
<TheMuso> NCommander: just looking at a few things a11y wise.
<calc> cjwatson: looking
<calc> cjwatson: the only difference appears to be that myspell-en-us has iceape/icedove/iceweasel in the dictionary
<calc> cjwatson: looks like we could drop hunspell-en-us afaict
<calc> well there is also a file naming difference in /usr/share/myspell/infos/ooo/(blah)-en-us
<calc> cjwatson:  4 files changed, 7 insertions(+), 1 deletion(-)
<calc> cjwatson: that was after deleting the doc dir which had the debian changelog, etc
<calc> cjwatson: i messaged rene to see if he knows why it still exists as a package, doesn't seem to have any real use
<calc> one of the two probably should cease to exist, but i am not sure which one he would choose, heh
<IsmailBhai> hi
<pitti> Good morning
<kees> pitti: any thoughts on 346846 ?  hal shows my esata luks partition, but I don't get prompted for it.  *scratch head*
<pitti> kirkland: I'll get to it today
<kees> pitti: oh!  I wasn't expecting you to be up yet!  :)
<kees> good morning.  :)
<pitti> slangasek: ah, I'm bitten by this as well; an iwlist is fairly harmless (as opposed to some ifdown/ifup hacks we did in the past), so I'm all for it
<pitti> kees: good morning! early bird catches the worm :)
<kees> pitti: indeed!  :)
<pitti> and I still have a ton of stuff to do before I leave for the LF summit
<pitti> kees: ah, you can reproduce it?
<pitti> kees: is that only for esata, or also for USB disks?
<kees> pitti: yes.  if I plug in this drive via USB, I am prompted.  via esata, I'm not.
<pitti> kees: od you get an icon on the desktop/computer place?
<pitti> kees: my gut feeling is that it is detected as an internal, non-removable disk
<pitti> kees: look at the lshal stanza, .hotpluggable/.removable
<kees> pitti: I don't get any icon for esata.  (lshal shows the raw luks partition, though)
<ka6sox-work> kees, do you work on update-manager?
<kees> ka6sox-work: nope, sorry.
<kees> pitti: I don't see those two items.
<bluefoxicy> so guys
<bluefoxicy> I put elevator=as on my kernel command line in Jaunty
<kees> pitti: I can't say if it worked in earlier alphas (as the original reporter says)
<bluefoxicy> Jaunty now has ceased to behave like Windows Vista on a 486 with 32 megs of RAM
<pitti> kees: these are on the device (sda), not on the partition (sda1)
<bluefoxicy> i.e. it's actually usable and not lagging like hell
<kees> pitti: if I try "gnome-mount" from the command line, it always fails.
<pitti> kees: storage.hotpluggable and storage.removable
<kees> pitti: ah! one sec
<bluefoxicy> apparently CFQ is now total garbage.  Should I file this as a bug?
<kees> pitti: har har:    storage.hotpluggable = false  (bool)
<kees>   storage.removable = false  (bool)
<kees>   storage.removable.media_available = true  (bool)
<pitti> kees: that's it then
<pitti> kees: can you please paste this to the bug?
<kees> pitti: the sde stanza?
<pitti> yes
<pwnguin> bluefoxicy: you'd proably get more traction on kernel performance in #ubuntu-kernel, during whatever counts as business hours
<pitti> kees: does gnome-mount -vbd /dev/sde1 work?
<bluefoxicy> pwnguin: possibly
<pitti> kees: (please paste the output to the bug, too)
<kees> hm
<kees> rg.freedesktop.Hal.Device.PermissionDeniedByPolicy : org.freedesktop.hal.storage.crypto-setup-fixed auth_admin_keep_always <-- (action, result)
<kees> pitti: oh, dur.  "sudo gnome-mount ..." worked
<sbeattie> kees: are you watching bug 352779? Mind if I assign it to you for now?
<ubottu> Launchpad bug 352779 in dhcp3 "Bad MTU for eth0 in 9.04 amd64" [High,Incomplete] https://launchpad.net/bugs/352779
<pitti> kees: argh, DSL reconnect; did you say something after my "please attach hal debug output"?
<kees> sbeattie: sure, no problem.
<kees> pitti: yeah, I realized I needed to do "sudo gnome-mount ..." after seeing:  org.freedesktop.Hal.Device.PermissionDeniedByPolicy : org.freedesktop.hal.storage.crypto-setup-fixed auth_admin_keep_always <-- (action, result)
<pitti> kees: you shouldn't really
<pitti> kees: it should ask you for admin password through policykit
<kees> pitti: it doesn't seem to do that -- it just wanted the luks password
<pitti> kees: it works with sudo?
<kees> pitti: yup
<pitti> kees: I'm interested in the hal output for both cases (sudo and user)
<pitti> interesting
<kees> pitti: hal output from what?
<pitti> kees: the hal debugging output
<pitti> didn't that come through any more?
<kees> you mean the gnome-mount output?
<pitti> <pitti> kees: can you please do this again with a hal debu
<pitti> gging output (https://wiki.ubuntu.com/DebuggingHal#How%20to%20file) and attach i
<pitti> t?
<kees> oh! I never saw that.
<pitti> kees: tomorrow I have to get up at 4:30 am, good time to reset my dsl router to have the reconnect in the middle of the night henceforth :)
<pitti> kees: I just tried mounting an unencrypted internal partition as user, and it worked (through PK), so it seems the issue is only with luks encrypted ones
<pitti> that sounds tractable to fix
<kees> cool.
<pitti> kees: so, please submit the hal debugging output, for both non-sudo and sudo gnome-mount
<pitti> kees: and also supply the output of "gnome-mount -vbud /dev/sde1" (-u -> unmount), which should work as normal user; if not, try again with root
<kees> okay -- is it sane to restart hal several times while I have Xorg running?
<pitti> kees: yes, you can restart hal without problems
<pitti> kees: but once in debugging mode you can just leave it running
<pitti> no need to restart between above attempts
<pitti> kees: just don't touch dbus
<kees> okay, let me collect that stuff.
<kees> heh
<showers> hello?
<showers> Even as we speak, ubuntu is downloading (utorrent, pretty good speed) and I may need just a little assistance
<dholbach> good morning
<showers> To set up the dual boot
<showers> Basically, there are two hard drives - one win xp and the other empty except for my data backup files
<showers> i partitioned the almost empty drive into the data backup (5 gigs) and the unused space
<showers> it would be nice if ubuntu would install into the unused part of the backup disk
<showers> will there be any problems?
<showers> Because it is going into only part of a drive it will probably be a 'manual install.'
<showers> from my previous experience with linux it needs three partitions. Still True?
<dholbach> showers: did you try asking in #ubuntu?
<showers> will have to do the iso burn thing first, and all that. The only thing which gave me trouble ... eh? asking in ubuntu, you say? Well, to be sure.
<showers> join/#ubuntu
<showers> join #ubuntu
<showers> #ubuntu
<dholbach>  /join #ubuntu
<showers> of course. thanks
<kees> pitti: okay, everything attached.
<dholbach> bryce, tjaalton: will you guys take care of 352335 and bug 326050?
<ubottu> Launchpad bug 326050 in xserver-xorg-input-vmmouse "vmmouse is out of date" [Undecided,Confirmed] https://launchpad.net/bugs/326050
<dholbach> bug
<dholbach> bug 352335
<ubottu> Launchpad bug 352335 in xserver-xorg-input-acecad "FTBFS due to xserver-1.6" [High,Confirmed] https://launchpad.net/bugs/352335
<bryce> dholbach: timo has been afk due to ill children
<tjaalton> dholbach: sure
<tjaalton> hehe
<tjaalton> back :)
<bryce> wb :-)
<Amaranth> ill children will almost certainly end up with an ill timo
 * dholbach hugs the dynamic duo :)
<tjaalton> Amaranth: maybe after the incubation time is over ;)
<dholbach> bryce, tjaalton: and bug 317127 too :)
<ubottu> Launchpad bug 317127 in xf86-input-evtouch "evtouch calibrate tool does not detect mouse position" [Undecided,Confirmed] https://launchpad.net/bugs/317127
<dholbach> ivoks: do you know who usually takes care of ebox stuff?
<dholbach> ivoks: it seems the upstream maintainer is looking for a sponsor: bug 345150 and bug 350452
<ubottu> Launchpad bug 345150 in network-manager-openvpn "network-manager-openvpn fails if "System setting" checked in Intrepid" [Undecided,New] https://launchpad.net/bugs/345150
<ubottu> Launchpad bug 350452 in ebox-usersandgroups "custom LDAP ACLs are not set properly" [Undecided,Confirmed] https://launchpad.net/bugs/350452
<dholbach> ivoks: he seems to be a good guy, knowing his way around
<bryce> dholbach: why these bugs in particular?
<dholbach> bryce: they're all on the sponsors list
<tjaalton> bryce: I guess because they have patches
<bryce> ahh
<ivoks> dholbach: hm...
<tjaalton> the FTBFS' should be synced, although they need a FFe
<dholbach> ivoks: sorry, the first one should have been bug 354150
<ubottu> Launchpad bug 354150 in ebox-samba "samba tries to start TLS on unix socket" [Undecided,Confirmed] https://launchpad.net/bugs/354150
<bryce> hum, weird, I *just* went through harvest yesterday top to bottom sponsoring patches, odd I didn't run across those
<dholbach> hiya ttx
<ttx> hey dholbach !
<dholbach> ttx: do you know anything about bug 345562 and the progress there?
<ubottu> Launchpad bug 345562 in netbeans "Add important patches for NetBeans 6.5 in Jaunty" [Undecided,Confirmed] https://launchpad.net/bugs/345562
<ttx> dholbach: no, but I can have a look.
<dholbach> super
<ivoks> dholbach: server team does it, there's no one particulary responsible for it, iirc
<dholbach> ah ok
<bryce> tjaalton: you doing evtouch and vmmouse both, or should I take one or the other?
<tjaalton> bryce: I can take care of them
<bryce> thanks
<ivoks> dholbach: javier is upstream, so i would trust his patches :)
<dholbach> ivoks: yeah, I noticed - so will you sponsor them? :)
<ivoks> dholbach: sure
<dholbach> I'm trying to get  http://people.ubuntu.com/~dholbach/sponsoring/  down to 0 :)
<dholbach> we're doing quite good actually
<ttx> dholbach: re:netbeans at first glance it looks relatively harmless but I don't know anything about netbeans... I know persia does
<dholbach> ttx: I think he's travelling atm
<ttx> dholbach: ok. i'll put that on my TODO.
<slangasek> pitti: ok; if rtg & pgraner don't have a better idea how to fix it for release, then let's do that
 * ttx is just back from a 3-day presence at the Paris SolutionsLinux expo
<ttx> dholbach: so I have a large backlog.
<pitti> slangasek: do you have time to work on that? I'm on the LF summit next week, and still have a ton to get done today
 * dholbach hugs ttx
<slangasek> pitti: I can probably poke at it over the weekend; as I said, I was already pondering hacking it together for myself :)
<pitti> ah, splendid
<dholbach> superm1: does bug 352572 make sense?
<ubottu> Launchpad bug 352572 in mythtv-status "Please move mythtv packages that depend on libmyth-perl (multiverse) to multiverse" [Undecided,New] https://launchpad.net/bugs/352572
<slytheri1> cjwatson: not sure if you have noticed already, but grub-pc package is not on alternate CD images. Let me know if I should file a bug for this.
<slangasek> slytheri1: it's intentional to only include in on the DVD; does this cause a problem?
<RAOF> lifeless: Do you remember when I was complaining about evolution thrashing the disc for 30 minutes at a time, and you said (a) that there was a bug filed upstream and (b) that it was fixed in trunk?  I can't seem to find the bug, and it's not fixed in Ubuntu :)
<Unggnu> hi all
<Unggnu> pitti: You there?
<pitti> hi Unggnu
<Unggnu> hi
<Unggnu> Is it possible that apport doesn't mark the whole bug report private but only the private relevant parts like backtraces?
<Unggnu> The problem is that often your bug report is marked as a duplicate but you can't see the original report because of the private tag
<Unggnu> So it is still possible to add information for the duplicate reporter.
<slytheri1> slangasek: I haven't yet tried installation yet. But since grub-installer is supposed to give an option to install grub2 in advanced mode, I thought it will cause problem if it is not included on CD.
<Unggnu> pitti: What do you think? Should I add a feature request/bug report?
<pitti> Unggnu: that would be nice, but unfortunately isn't possible with LP
<pitti> you can't make attachments private at all
<Unggnu> pitti: atm?
<pitti> if you know their URL, you can read them
<Unggnu> So a bug against launchpad?
<pitti> Unggnu: right
<Unggnu> ok, thx
<pitti> if we had private attachments, we could redesign this to be much more friendly
<pitti> tseliot: bug 320632> seems you did it, great job! Can you please connect with bryce to get this sponsored?
<ubottu> Launchpad bug 320632 in xfree86-driver-synaptics "tap-to-click and edge-scrolling broken in Jaunty" [Medium,In progress] https://launchpad.net/bugs/320632
<tseliot> pitti: sure, I'll talk to him
<mvo> just FYI I disabled upgrades to jaunty temporarely because of bug #354228
<ubottu> Launchpad bug 354228 in python-central "package python2.6-minimal 2.6.1-1ubuntu8 failed to install/upgrade: " [High,Triaged] https://launchpad.net/bugs/354228
<RAOF> TheMuso: You might be happy to learn that pulseaudio from the test PPA is no longer totally crazily crap.  It seems to work fine, and not even make HDA Intel a world of crackling underruns.
<slangasek> slytherin: it /should/ automatically download from the network to install it
<slangasek> slytherin: if you don't have a network, then the DVD is the only way to get grub2 currently
<Unggnu> pitti: https://bugs.launchpad.net/bugs/354345
<ubottu> Launchpad bug 354345 in launchpad "Launchpad needs private attachments" [Undecided,New]
<slytherin> slangasek: hmm. I can understand, considering that only advanced users will install grub2. Are we targetting for grub2 to be default for karmic?
<bryce> pitti, tseliot: done
<pitti> bryce: awesome
<tseliot> bryce: thanks. I didn't think you were still awake ;)
<slangasek> slytherin: we don't currently have such a target, no; grub2 will need more attention yet before we'll be able to make it default, and no one's committed yet to making that happen
<bryce> tseliot: pshaw it's barely 1am
<tseliot> hehe
<slytherin> slangasek: ok.
<pitti> bryce: sounds like a good time to go to bed :)
 * pitti hugs bryce
<lool> slangasek: Please do change texlive-bin, thanks for looking into it
<slangasek> lool: ok - done ;)
<bryce> ooh, slangasek's up too, and he's my same timezone
<lool> ISTR Matthias had done some changes to texlive though
<lool> Oh no, it was djvulibre
<slangasek> bryce: yes, and I have to be up in 6 hours for a release meeting; I'm a masochistic idiot, what's your excuse? :)
<bryce> same
<lool> I have to be up in 6 hours for a release meeting as well!!
<lool> :-P
<slangasek> lool: you'd better get to bed soon then
<bryce> lool:  done today just for you...
<bryce>    def append_comment(self, message):
<bryce>         for m in self.bug.messages:
<bryce>             if m.content == message:
<bryce>                 return
<bryce>         self.bug.newMessage(subject = "Re: "+self.title, content = message)
<bryce>         return True
<mvo> lool: what TZ are you in currently :) ?
<lool> bryce: \o/
 * lool hugs bryce 
<lool> bryce: TBH I've been a bit annoyed by the rate at which the scripts were asking for useless stuff; I'm sure they'll improve and that'll eventually be history
<lool> mvo: I'm in Disneyland/Mickey + 2
<pitti> bryce, tjaalton: did you happen to see bug 349127?
<ubottu> Launchpad bug 349127 in mesa "Elisa displays video with greenish/purplish colors" [High,Triaged] https://launchpad.net/bugs/349127
<tjaalton> pitti: yes, I've got mesa 7.4 in my ppa
<pitti> I mean the backported patches
<mvo> lool: heh :)
<pitti> tjaalton: I don't suppose 7.4 is targetted at jaunty?
<tjaalton> pitti: it is
<lool> Uh
<pitti> oh
<tjaalton> I'd rather get it instead
<mvo> lool: I'm in GreenTeaLang/Sencha
<tjaalton> it's a bugfix release
<pitti> tjaalton: this sounds like a high regression potential?
<lool> mvo: Sweet, received your order? :)
<tjaalton> no it doesnt'
<pitti> I was just looking at the backported patch
<bryce> lool: yes, getting them tuned perfectly will take some time but I plan to keep at it
<mvo> lool: yes - you too?
<tjaalton> did I not send an email to the list about it?
<lool> mvo: No, and it's looking bad; order was refused and they don't pick up the phone so I couldn't switch credit card in time, it's going to expire today   :-/
<lool> tjaalton: I didn't see it
<pitti> tjaalton: I haven't seen it, but I might have missed it (I'm not on ubuntu-x@)
<bryce> tjaalton: don't think so
<tjaalton> damn
<lool> I'm not on -x either
<pitti> so, the backported patch looks reasonable to me
<bryce> hehe
<pitti> and it is confirmed to fix elisa
<bryce> I think maybe I'm on -x by myself, that would explain the lack of replies to some of my emails ;-)
<tjaalton> I mean to send it to u-d
<bryce> here I've just been assuming everyone must be agreed ;-)
<tjaalton> meanT
<pitti> tjaalton: when is that scheduled to land? can we have it ASAP theN?
<bryce> pitti: I also reviewed mesa 7.4 and agree it is worth a FFe on
<pitti> also, that means I shouldn't bother to apply/test the backported patch then?
<pitti> bryce: FF? I thought it was bug fix only?
<tjaalton> pitti: sure, it's basically ready, I've just been adding some backported commits that have been verified to fix some bugs
<pitti> ah, great
<tjaalton> well, new upstream version
<pitti> tjaalton: mind if you close the bug above in the changelog?
<mvo> lool: oh :(
<tjaalton> pitti: sure
<pitti> great, thanks
<pitti> tjaalton: new upstream versions by themselves don't need an ack; new features do
<bryce> pitti: yes bug fix only; but whatever paperwork is required for a new version of a package, I +1 it for mesa 7.4 ;-)
<slangasek> does 7.4 also close the mythbuntu bug?
<pitti> I don't think so
<pitti> 7.4 from ppa was said not to fix that one
<tjaalton> which bug was that?
<slangasek> (who's upstream for mesa these days? someone who knows what "bugfix only" means?)
<pitti> tjaalton: bug 341898
<ubottu> Launchpad bug 341898 in mesa "Mythtv frontend does not display any fonts" [High,Confirmed] https://launchpad.net/bugs/341898
<tjaalton> slangasek: brian paul @ vmware, they are pretty strict ;)
<slangasek> ok
<slangasek> still, taking a new upstream release that only manages to fix one of two release-critical bugs on the package, vs. just cherry-picking the fix we know and care about?
<tjaalton> I proposed a patch that bumps the texture size on i965 and it was rejected from 7.4
<tseliot>  tjaalton: can I see that patch?
<tjaalton> tseliot: it's in the ppa version
<davmor2> bryce: should a built in nvidia 6100 gfx card have a higher res than 800x600 using the nv driver or is it likely to be using the vesa mode? 00:0d.0 VGA compatible controller [0300]: nVidia Corporation GeForce 6100 nForce 405 [10de:03d1] (rev a2) id from lspci -vvnn
<pitti> admittedly I'm still nervous about getting large changes in now, even if they are declared bug fix only
<wgrant> doko: Should python2.6's distutils really be inserting local/ even when it's nowhere near /usr?
<tjaalton> pitti: I'll open a new tracker bug for it with all the confirmed fixes, diffstat and shortlog etc
<bryce> slangasek: shipping ubuntu with a version number on mesa that is a stable version number will give people more warm fuzzies than if we shipped with an unstable version number + patches.  For whatever warm fuzzies are worth, there's that ;-)
<tjaalton> yeah, like um, hardy?-)
<pitti> tjaalton: thanks
<tseliot> tjaalton: ok, thanks
<bryce> davmor2: check your Xorg.0.log to see what driver is loaded
<bryce> davmor2: in general if you're stuck at 800x600 it usually means either you booted vesa, or your monitor's EDID was invalid for some reason
<lool> tjaalton: Weird, that max texture size bump didn't seem too risky; it was even tested
<davmor2> bryce: where was the nv device list too I can check if it is listed in there too
<tjaalton> davmor2: nv is fail, try nouveau
<lool> I was actually about to ask whether we'd get that fix
<slangasek> bryce: oh, 7.3 reads as an unstable version number in the case of mesa?
<lool> (Cause currently you can't have a big screen on the side of your laptop and use compiz)
<bryce> davmor2: /usr/share/xserver-xorg/pci/
<bryce> slangasek: yes
<lool> slangasek: yes
<tjaalton> lool: it might get in 7.4.1, but idr said it should need another commit which broke r300
<slangasek> ah, well, in that case.. :)
<davmor2> bryce: ta I'll look at both of those
<bryce> tjaalton is right that nouveau is a good option, however we're not officially supporting it yet, so it's still sort of buyer beware for now
<tjaalton> RAOF does support it though :)
<directhex> crazy boy that he is
<davmor2> bryce: Meh xorg.log and xorg.log.old both list nvidia and glx however the card id isn't listed in nv.  Should I try adding it and do sudo dpkg-reconfigure -phigh xserver-xorg
<tseliot> davmor2: isn't it something similar to what I reported here (albeit with a different card)? http://www.mail-archive.com/xorg@lists.freedesktop.org/msg04430.html
<tseliot> davmor2: have a look at Aaron's reply
<tjaalton> oh, 6100 doesn't work
<tjaalton> sorry
<tjaalton> wrong model :)
<RAOF> tjaalton: 6100 doesn't work with nouveau?  There are some kernel fixes there I'm considering pulling in.
<tjaalton> RAOF: no, I meant -nv
<davmor2> tseliot: Ah makes sense
<tjaalton> I filed a bug about GF7050 not being supported by -nv, but failed to remember the model
<RAOF> davmor2: Really, try nouveau.  It's faster and more featureful than the binary nvidia driver.
<RAOF> davmor2: Well, barring 3d, of course :)
<lifeless> RAOF: uhm
<lifeless> RAOF: http://bugzilla.gnome.org/show_bug.cgi?id=564339 was one
<lifeless> which I patched
<ubottu> Gnome bug 564339 in Mailer "imap syncing performstoo much local I/O" [Normal,Unconfirmed]
<tjaalton> pitti: so, there's bug 347171 already, I've updated it
<ubottu> Launchpad bug 347171 in mesa "[FFe] Allow mesa to be updated to 7.4" [Wishlist,Confirmed] https://launchpad.net/bugs/347171
<tjaalton> slangasek: ^^
<lifeless> RAOF: but I can't right now find the other; it was linked from the lp bug I filed on evolution though, if you care to search for it
<RAOF> lifeless: Looks like your patch should be in Jaunty's package.
<tjaalton> pitti, slangasek: oh and it seems to fix my problems on resume :) (bug 347871)
<ubottu> Launchpad bug 347871 in mesa "[LENOVO 7674E68] suspend/resume failure" [Medium,Triaged] https://launchpad.net/bugs/347871
<cjwatson> calc: ok, thanks; I was more wondering about dictionary compatibility than about the contents, I think
<directhex> tracker's "about to index" notification message seems inappropriate
<directhex> saying "you can pause it by clicking here" doesn't help much given the contextless nature of the new notifications
<directhex> and unclickability too
<tkamppeter> Any USB/kernel expert around? Can you have a look at bug 348316? Seems to be a low-level USB problem.
<ubottu> Launchpad bug 348316 in linux "Printer (HWModel Name) May Not Be Connected" [High,Incomplete] https://launchpad.net/bugs/348316
<mnemo> tkamppeter: try #ubuntu-kernel as well
<james_w> I need to do a split() with and re in perl, but also retain the text that was split on, is there a way to do this?
<james_w> i.e. split on "[ \t]+" and get back the exact spacing that was used as well as the bits either side
<cjwatson> james_w: put parens around the thing you're splitting on
<cjwatson>                If the PATTERN contains parentheses, additional list elements
<cjwatson>                are created from each matching substring in the delimiter.
<james_w> ah, wonderful, thanks
<tkamppeter> mnemo: Thanks, but it seems that there is currently no traffic on #ubuntu-kernel.
<mnemo> :(
<ogra> tkamppeter, the kernel team is at a sprint at the US eastcoast ... they will be up later
<tkamppeter> ogra, thanks, did not know that they are having a sprint now.
<juanje> hi, anyone here maintain the grub package? I've added a branch to a bug 347790 to fix it last week. I've been testing it and it's working, but I don't know if it's the best approach. It is a problem with the UUID device name and splashimage path
<ubottu> Launchpad bug 347790 in grub "Splash image not shown when using device UUID as root" [Undecided,Confirmed] https://launchpad.net/bugs/347790
<mnemo> juanje: use "aptitude changlog grub" to see how usually uploads it and contact one of those guys
<juanje> mnemo: thanks
<jpds> juanje: You could subscribe the ubuntu-main-sponsors to the bug too.
<juanje> jpds: Thank, good idea. I will
<juanje> mnemo: actually I now the people who touch the package, the problem is nobody said nothing in more than a week and the bug is confirmed and make the splashimage feature fails, so for me it's quite important.
<cjwatson> juanje: I'll look at it, thanks
<juanje> cjwatson: Thanks to you :-)
<cjwatson> juanje: please don't modify existing already-released changelog entries
<cjwatson> -grub (0.97-29ubuntu51) jaunty; urgency=low
<cjwatson> +grub (0.97-29ubuntu51guada1) jaunty; urgency=low
<cjwatson> very confusing
<juanje> cjwatson: sorry, this was for our ppa so we could use in the main time. I didn't mean to change for the patch :-/ Sorry
<cjwatson> this all seems quite wrong though. There'll be all sorts of problems caused by putting a root command in there.
<juanje> cjwatson: yes, I was looking for that problem (I'm still doing it) but i didn't find yet the place
<cjwatson> juanje: oh, also, never use a file in debian/patches/ to patch files in debian/
<cjwatson> just change the file directly
<juanje> ummm
<juanje> cjwatson: ok, it was just because it was a script which will be installed on /usr/sbin/ not a debian file
<cjwatson> (ubuntu_update_grub.diff does this, I know; that's a bug and not one to be imitated)
<cjwatson> juanje: that doesn't matter, the fact is that it's in debian/ and not in the .orig.tar.gz
<juanje> cjwatson: yes, that was the one I looked to make mine..
<juanje> ok
<juanje> I undertand
<cjwatson> ubuntu_update_grub isn't actually applied, it's apparently just kept there for future reference or something
<juanje> yes, I saw it
<cjwatson> I'll remove it since it's preserved in revision control
<juanje> cjwatson: I guess that is better to avoid confusions like mine
<lifeless> RAOF: my fix is in yes
<lifeless> RAOF: there are other issues, and thats where I got bored
<cjwatson> (done)
<lifeless> I'll get annoyed enough some day to come back to it
<RAOF> lifeless: I'd be happy enough with a workaround such as a recommendation for a better mail client :)
<lifeless> RAOF: I hear tinymail works
<juanje> cjwatson: I was trying another approach in another branch. Doing it by fixing the real bug (splashimage should allow UUID paths), but I'm still looking in the code... :-/
<cjwatson> juanje: the syntax would be a bit tricky. What did you use?
<juanje> cjwatson: syntax? what syntax?
<juanje> for the path?
<juanje> I didn't put any. The updated-grub did
<cjwatson> juanje: in order to allow for opening images by UUID and path, the syntax of the splashimage command would need to be extended, would it not?
<juanje> I just put the file in the right place (/boot/grub/splash.xpm.gz) and the update-grub did the work
<juanje> ummm
<cjwatson> and there is a fundamental problem with that because grub_open supports no syntax which allows UUIDs
<juanje> cjwatson: yes, I saw it. But other files are opened with that with success. I think because they open first the device (or set the root device) and the open the file
<juanje> cjwatson: well, I think... I'm not totally sure...
<cjwatson> I'm talking about the syntax "(hd0,0)/foo/bar/baz"
<cjwatson> if you mean the kernel and the initrd, then yes, they do so by first setting the uuid, and then opening a file relative to that
<cjwatson> it would probably make sense to use 'uuid foo\nsplashimage /relative/path'
<cjwatson> assuming that that actually works, mind :)
<juanje> cjwatson:  what I did in the branch was setting the root to the uuid device before (but in the menu.lst) and then putting just the relative path for the splashimage. And in that way works
<cjwatson> juanje: there's a separate command for setting root by uuid
<cjwatson> juanje: you should use that, not the 'root' command
<juanje> cjwatson: I guess the thing is doing something similar, but in the code. Just before the grub_open, setting the uuid root
<cjwatson> juanje: well, no, it wouldn't be necessary to do that in grub_open if it were done properly in update-grub
<cjwatson> not strictly necessary anyway
<juanje> cjwatson: yes, I know
<juanje> ummm
<cjwatson> but using the 'root' command in update-grub as a workaround is right out
<cjwatson> you need to use the 'uuid' command
<cjwatson> at least, if $grub_root_device is a UUID
<juanje> cjwatson: well the documentation says it's almost the same command
<RAOF> lifeless: Hm.  Tinymail (or, at least, the 'modest' client built on it) is certainly fast; it just doesn't actually work, though :)
<juanje> and if you are not using uuid it will working anyway
<cjwatson> "almost the same" is not "the same"
<juanje> cjwatson: hehe, ok
<cjwatson> juanje: the whole *point* of the exercise is to fix things for people using UUIDs
<cjwatson> so saying "it'll work if you aren't using UUIDs" is a bit fatuous
<cjwatson> it works right now with no changes if you aren't using UUIDs :)
<juanje> cjwatson: yes, probably, no one uses non uuid path, but if what if this happen?
<juanje> ok
<cjwatson> you use the 'root' command for such cases
<cjwatson> look at lines 799-806 of update-grub
<lifeless> RAOF: :)
<lifeless> or should I say :(
<juanje> cjwatson: yes, know those lines, I used them
<cjwatson> juanje: not properly, though
<pitti> Keybuk: I'd like your opinion on bug 347370 (last comment)
<juanje> ummm
<cjwatson> juanje: your version of it never emitted a 'uuid' command
<ubottu> Error: Could not parse data returned by Launchpad: timed out (https://launchpad.net/bugs/347370/+text)
<juanje> cjwatson: the case didn't work well for me
<cjwatson> juanje: that needs to be made to work
<juanje> you mean to change the "root" command there for the "uuid" one?
<cjwatson> juanje: if the root device is (hdX,Y), it should produce a 'root' command. If it is a UUID, it should produce a 'uuid' command - just as in the lines I referred to above
<juanje> cjwatson: I thought about it, but I didn't because what I told you before. but I guess you're right, it must be uuid because with other paths wont get into the case
<juanje> yes
<juanje> you are right
<cjwatson> actually, if the root device is (hdX,Y), there is no need to produce a 'root' command, because the 'splashimage' command's syntax can already cope with that
<juanje> that's why i didn't in that cases
<juanje> actually, putting root comand was an error....
<cjwatson> in other words, if the root device is (hdX,Y), emit 'splashimage=(hdX,Y)/relative/path'; if the root device is a UUID, emit 'uuid foo-bar-baz' and 'splashimage /relative/path'
<cjwatson> or splashimage=/relative/path I guess. I don't think it matters
<juanje> so, the patch could be the same, but changing the root command for the uuid one, couldn't it?
<cjwatson> yes, probably
<juanje> ok
<juanje> and changing directly in the update-grub, instead of using the debian/patches
<cjwatson> yes
<juanje> do you like i change the branch and readed? or you like to change it yourself?
<Keybuk> pitti: if you want unmangled, use ID_FS_LABEL_ENC
<cjwatson> juanje: I'd appreciate it if you could do it - I'm not going to have time to test changes and I have a depressing number of RC bugs of my own :/
<juanje> cjwatson: I've just attached patch for the current main branch
<juanje> cjwatson: I'll testing again with this code and I'll write update on the bug
<juanje> cjwatson: thank you so much for your time. I really appreciate. I know you're quite busy...
<Keybuk> just for _once_, I'd like usb-creator to work
<Keybuk> "invalid compressed format (err=2)" ?
<cjwatson> I don't think that's from usb-creator itself. gzip or something?
<Keybuk> cjwatson: it's from trying to boot the USB keys it's making today
<Keybuk> (of 9.04 beta)
<cjwatson> oh, right, that's the kernel
<Keybuk> using trunk seems to have solved it
<Keybuk> ooh, today London has moved to the North coast of France \o/
<cjwatson> let me see if I can do an upload
<cjwatson> it has? it was in the right place for me
<cjwatson> sassenfrassenmapprojections
<Keybuk> hmm
<Keybuk> stuck in a "The installer has detected that the following disks have mounted partitions: /dev/sdb" loop
<cjwatson> err, is this beta or a daily?
<cjwatson> Keybuk: there's nothing in usb-creator trunk that isn't in the beta
<Keybuk> beta
<cjwatson> could you try a daily please?
<cjwatson> I want to make sure that both of those bugs are dead and gone
<Keybuk> I'm using beta deliberately for the testing I need to do
<Keybuk> I'm not sure whether I'll have time to play with a daily
<Keybuk> heading to SF over the weekend
<cjwatson> then I'd appreciate if you didn't scare me by talking about installer bugs we've already fixed?
<Keybuk> sure, but I did *start* this by saying 9.04 beta ;)
<Keybuk> ?! "Input/output error" now
<cjwatson> I'm still confused about you talking about usb-creator beta vs. trunk, which AFAICS are identical
<Keybuk> usb-creator in current jaunty didn't work for me
<Keybuk> hmm
<Keybuk> this is failing again due to squashfs errors
<cjwatson> lp:~usb-creator-hackers/usb-creator/trunk is 0.1.15
<Keybuk> weird
<Keybuk> why aren't these images working?
<cjwatson> are you using some different trunk? I think Evan has moved it a couple of times
<Keybuk> no, definitely the one you say
<Riddell> ArneGoetje: how come language-pack-kde-fr contains translation files?  shouldn't they all be in language-pack-kde-fr-base?
<superm1> dholbach, added a comment, that's for raising that
<dholbach> superm1: rock on!
<cjwatson> Riddell: language-pack-kde-fr's purpose is to contain deltas on top of language-pack-kde-fr-base, to save us the expensive -base respin all the time
<Riddell> cjwatson: and isn't that post-release only?
<cjwatson> Riddell: sometimes during a development release too, since the full export is expensive (days of runtime, IIRC) at any time. They'll be back down to size for final
<doko> wgrant: where does it to this?
<wgrant> doko: I'm trying to get virtualenv working, but it's proving non-trivial becauuse python2.6 insists on sticking local/ after Python's prefix even when it's not in /usr.
<doko> wgrant: do you use python2.6_2.6.1-1ubuntu8?
<wgrant> doko: Yes.
<pitti> Keybuk: is there a standard function for decoding that by any chance?
<juanje> cjwatson: tested and updated the bug. Thanks for the help and the time :-)
<Keybuk> pitti: it's just standard escaping no?
<Keybuk> \x<hex>
<pitti> Keybuk: right, I just wondered if there's some existing function to decode that, or whether I need to write it
<Keybuk> unsure
<doko> wgrant: please update and rehcheck. this should address the problems. Had a discussion with Larry Hastings at PyCon, who emailed about these on the distutils-sig
<wgrant> doko: Update to what? 2.6.1-1ubuntu8 is the latest.
<doko> wgrant: hmm, I misread. do you use the package, or the virtualenv upstream directly. in any case please file a bug report.
<Riddell> mdeslaur: would you have an opinion on updating the lcms package to 1.18?
<mdeslaur> Riddell: I guess we should
<mdeslaur> Riddell: for jaunty
<Riddell> mdeslaur: trouble is I can't see a changelog
<Riddell> mdeslaur: oh here's a sort of one http://www.littlecms.com/whatsnew.htm
<mdeslaur> Riddell: heh...great changelog
<mdeslaur> Riddell: when I looked at 1.17 to 1.18beta2, it was mostly the security fixes, along with a few other things
<superm1> mdke, thanks for that hack.sh in the interim re bug 353981. i'll just integrate that for now in new import target in my Makefile until rosetta is fixed
<ubottu> Launchpad bug 353981 in rosetta "File names of exported PO files are non-standard." [Undecided,New] https://launchpad.net/bugs/353981
<smagoun> slangasek kees: Hey guys, would you take another look at bug 316756 when you get a chance? It's a conffile prompt for login.defs on upgrade to Jaunty; I figured out how to reproduce it.
<ubottu> Launchpad bug 316756 in shadow "conffile prompt on upgrade to jaunty" [Medium,Confirmed] https://launchpad.net/bugs/316756
<m4v> Riddell: bug 354493
<ubottu> Launchpad bug 354493 in lcms "security update breaks lcms" [Undecided,New] https://launchpad.net/bugs/354493
<ahasenack> hi guys, I prepared an FFe request for smartpm (it's in main), it's here: https://bugs.launchpad.net/ubuntu/+source/smart/+bug/349866 I think it's complete. Who can I ping to take a look at it?
<ubottu> Launchpad bug 349866 in smart "Update smart to 1.2" [Undecided,New]
<pitti> Keybuk: oh, if it's really just \x00 style, then of course there is a decoding function --- printf() :)
 * pitti RTFS udev
<Keybuk> pitti: heh
<james_w> ahasenack: the release team are subscribed, so they'll get to it soon
<ahasenack> james_w: ok, thanks
<Keybuk> pitti: does printf really decode those?
<pitti> $ printf 'Pitti\x20USB'
<pitti> Pitti USB
<pitti> I'm checking volume_id_encode_string()
<cjwatson> pitti: I'd be worried about %s in the string
<Keybuk> that's the shell printf surely?
<pitti> cjwatson: hm, true that
<pitti> meh, why can't I just get the label as it is..
<Keybuk> cjwatson: well, if you trust udev, you know there's no % in there
<cjwatson> and yeah, what Keybuk said, in C \x is decoded by the compiler's lexer
<cjwatson> or lexical analysis pass or whatever the proper name is :)
<Keybuk> pitti: because labels can include \0, and C strings (and therefore udev's db) can't :p
<Keybuk> hmm
<Keybuk> actually those don't come from udev, they come from vol_id (blkid soon)
<Keybuk> and anyone can overwrite them with a udev rule
<pitti> ./extras/volume_id/lib/libvolume_id.c, yes
<Keybuk> pitti: the ones you get from volume_id are *not* escaped or encoded
<Keybuk> they're raw
<Keybuk> you only get an escaped or encoded copy if you use udevadm
<pitti> Keybuk: hal braindeadly calls udevadm info -e instead of just calling the volume_id_() functions for those
<Keybuk> see, you're running a program intended to output for humans ;)
<Keybuk> so it has to escape characters that can't be output
<Keybuk> actually, it's pretty paranoid and just escapes everything
<Keybuk> E:ID_VENDOR_ENC=ATA\x20\x20\x20\x20\x20
<Keybuk> there really is random crap in these strings ;)
<Riddell> mdeslaur, m4v: bug 354493 updated with FFe request
<ubottu> Launchpad bug 354493 in lcms "security update breaks lcms" [Undecided,New] https://launchpad.net/bugs/354493
<mdeslaur> Riddell: I don't think we were affected by that bug, I didn't use that "untrusted" patch, I pulled the patch out of 1.18beta1
<mdeslaur> m4v: did you get affected by the lcms update?
<pitti> Keybuk: I'm writing a decode_escape() function now; can't be more than 10 lines anyway
<m4v> mdeslaur: yes, as soon as it was updated
<m4v> Riddell: great, I will try to update from your ppa
<mdeslaur> m4v: do you have steps I can use to reproduce the issue?
<m4v> mdeslaur: only if you have koffice2 compiled from kde's svn, basically Krita asserted when opening any .kra file
 * Riddell notes that koffice2 is in jaunty
<Keybuk> pitti: that should go in libudev I reckon
<Keybuk> alongside the encode one
<pitti> would be handy
<pitti> OTOH
<pitti> Keybuk: if you are using libudev, you can just use the non-encoding functions in the first place
<m4v> ah, i didn't know, that should work, just open krita, paint something, save as kra, and try to open it again, I'll try it mysql
<Keybuk> pitti: things like the labels don't come from udev though
<m4v> myself*
<Keybuk> udev *gets* them encoded from blkid
<Keybuk> and never decodes them itself
<Keybuk> so a decode function would be useful
<pitti> ah, I see
<Keybuk> err, vol_id in this case
<Keybuk> but the same holds true in the future
<mdeslaur> m4v: work for me with the version in jaunty. Do you have color profiles configured in it?
<ttx> pitti: remember when joining a domain with likewise-open would break desktop things by aggressively restarting DBUS ? we fixed it by reloading instead...
<ttx> pitti: but likewise-open5 *requires* (according to upstream) DBUS restart to pick up nsswitch changes
<pitti> ttx: I don't, I haven't looked into likewise-open at all
<Riddell> mdeslaur, m4v: I confirm krita crashes using current lcms and doesn't with 1.18
<pitti> ttx: why woudl dbus be affected by an nsswitch change?
<Riddell> when opening a .kra file
<Riddell> mdeslaur: are you using krita-kde4  ?
<m4v> Riddell: yep, I get it too, if you open krita from a console, you should see an assert
<mdeslaur> Riddell: oh, no, sorry
<ttx> pitti: good question. Not restarting DBUS results in "Failed to initialize HAL" when logging in as a domain user
<ttx> pitti: upstream says it's required for glibc to pick up the nsswitch change
<ttx> http://lobugs.likewise.com/show_bug.cgi?id=17
<ubottu> lobugs.likewise.com bug 17 in domainjoin-core "DBUS should not be restarted in ConfigureLogin.in" [Normal,New]
<ttx> "DBUS is not able to resolve the user's id"
<pitti> oh, for enforcing the policies
<m4v> mdeslaur: not that i know of, i use the sRGB built-in (lcms internal) if that's what you mean. and I delete krita stuff in ~/.kde regulary
<pitti> ttx: that's just an one-time problem after installation, no?
<pitti> ttx: perhaps you should just trigger the 'reboot requried' notification in likewise's postinst then?
<ttx> yes. And Windows requires to reboot as well.
<ttx> pitti: I suppose yes. What is the proper way of doing that ?
<ttx> hhhmm no.
<ttx> pitti: it's a one-time thing after domain join, not package install.
<ttx> pitti: but I have a script run (the one mentionned on http://lobugs.likewise.com/show_bug.cgi?id=17) on which I can execute things rather than restarting/breaking DBUS
<ubottu> lobugs.likewise.com bug 17 in domainjoin-core "DBUS should not be restarted in ConfigureLogin.in" [Normal,New]
<ttx> pitti: so perhaps I could trigger the reboot required notification from there ?
<pitti> ttx: sure
<pitti> ttx: just call /usr/share/update-notifier/notify-reboot-required
<ttx> pitti: sounds simple enough :)
<facundobatista> Hello all
<facundobatista> tkamppeter, ping
<ttx> pitti: many thanks :)
<pitti> facundobatista: I think you should probably just followup on bug 348316; Till reads it, and he needs some tests (especialy with older kernels)
<ubottu> Launchpad bug 348316 in linux "Printer (HWModel Name) May Not Be Connected" [High,Incomplete] https://launchpad.net/bugs/348316
<mdeslaur> m4v: oh, yeah, I see the problem
<mdeslaur> Riddell: I was fixed between beta1 and beta2, I can either fix the patch, or we can go to 1.18
<m4v> w00t, both my build and krita-kde4 works with Riddell's lcms
<facundobatista> pitti, ok, thanks
<m4v> mdeslaur: probably up to 1.18 is better, it seems is going be a requirement for koffice2
<ttx> pitti: won't notify-reboot-required only notify you if update-manager is running ? I need to ask for a reboot after the domain is joined (triggered by domainjoin-cli or domainjoin-gui) so update-manager is not running at that time. Anything I should/could plug into ? notify-send ?
<pitti> ttx: update-notifier, not manager
<mdeslaur> m4v: ok, great
<pitti> ttx: if you aren't logged into GNOME, you won't get it, right
<m4v> mdeslaur: from koffice maillist, http://lists.kde.org/?l=koffice-devel&m=123874884601650&w=2
<ttx> pitti: I'll test some more, it doesn't seem to trigger on my test rig.
<mdeslaur> m4v: ok, let's go to 1.18
<ttx> pitti: the /var/run stuff is created but update-notifier doesn't trigger anything. Maybe it still sleeps.
<pitti> mvo: ^ hmm
<ttx> pitti: yep, running an apt-get afterwards triggers the notification.
<ttx> so it's not really usable in my case
<mvo> ttx: it needs a touch to /var/lib/update-notifier/dpkg-was-run too
<mvo> ttx: its designed to be part of the upgrade process and that file is touched when the upgrade is finished
<ttx> mvo: testing that, thx
<calc> cjwatson: i think they should be compatible in this case since they appear to be the same files in two different packages
<pitti> Keybuk: would you mind eyeballing this? http://paste.ubuntu.com/143509/
<pitti> works well for me
<cjwatson> calc: ok, thanks - can you take responsibility for changing hunspell based on the discussion?
<calc> cjwatson: hmm rene wants me to look at it again
<cjwatson> (once you've agreed it etc.)
<calc> cjwatson: and he thinks that myspell-en-us should be the one going away
<cjwatson> calc: right, if that's the case, hunspell's dependencies should change to list hunspell-en-us as the first alternative
<calc> ok
<tkamppeter> facundobatista: Hi
<facundobatista> tkamppeter, hi, I was just about to offer you my PC to test the printer issue in #348316, but then I found that I need to try some of what you wrote there
<pitti> Keybuk: I fixed a thinko in the UTF-8 validation, it's http://cgit.freedesktop.org/hal/commit/?id=97b023f94f1d79a19bc0489c0d167bdaebb765fd now
<NCommander> cjwatson, Good afternoon
<cjwatson> NCommander: it's open in my browser :) looks fine, I just want to do a couple of final checks and then I'll upload it
 * NCommander wonders when cjwatson installed telepathy and thus read my mind
<calc> cjwatson: do you remember that bug number? i need to add a few packages to it
<siretart> mvo: are update-manager's dist-upgrades to jaunty re-enabled yet?
<cjwatson> calc: bug 327821
<ubottu> Launchpad bug 327821 in livecd-rootfs "residual config in myspell-en-us after fresh install" [Medium,Fix released] https://launchpad.net/bugs/327821
<calc> cjwatson: ok thanks
<pitti> seb128: wow, the retracer caught up and didn't crash \o/ *phew*
<calc> cjwatson: ok this seems to only affect hunspell and thunderbird, and thunderbird is not of the cd so isn't critical to fix before release
<calc> cjwatson: i'll fix up hunspell
<cjwatson> thanks
<cjwatson> plenty of time to fix tb still :)
<calc> yea
<UsamaAkkad> hello, I've something needs a bit intention
<UsamaAkkad> https://bugs.launchpad.net/ubuntu/+source/synaptic/+bug/251378
<ubottu> Error: Could not parse data returned by Launchpad: The read operation timed out (https://launchpad.net/bugs/251378/+text)
<UsamaAkkad> lets say I don't have internet and I want to update my system
<UsamaAkkad> the synaptic generate download script worked for me fine when I had Dial-up connection
<UsamaAkkad> but what if someone has no connection at all
<UsamaAkkad> any one interested ?
<seb128> pitti: excellent ;-)
<calc> cjwatson: done
<Riddell> mdeslaur: I'll upload lcms 1.18 then
<mdeslaur> Riddell: thanks
<facundobatista> tkamppeter, ok, I tried everything on the mentioned bug (#348316 in lp), and now I can't even see my printer (see the bug for full details)
<facundobatista> tkamppeter, just let me know anything you want to test
<kees> smagoun_: oh good!  I can't tell you how many upgrade I've run trying to find that one.
<tkamppeter> facundobatista: Have you done "sudo aa-conplain cupsd"?
<tkamppeter> facundobatista: Did you unload the usblp kernel module and did you blacklist it?
<james_w> kees: thanks for looking at it. I have an idea for a patch to system-tools-backends to stop it doing that. I fear I may not want to show it to you though
<facundobatista> tkamppeter, yes to both
<facundobatista> tkamppeter, in the other order, though (modified the blacklist file first, then unloaded the moldule)
<tkamppeter> facundobatista: That is all OK.
<tkamppeter> Did the module actually unload ("lsmod | grep usb")?
<tkamppeter> facundobatista: What is the output of /usr/lib/cups/backend/usb
<facundobatista> tkamppeter, modules loaded: there's a usbhid, and the rest are all modules for usb sound
<facundobatista> tkamppeter, but no usblp
<tkamppeter> facundobatista: Yes, then the module got correctly unloaded.
<tkamppeter> Can you run /usr/lib/cups/backend/usb now?
<facundobatista> yes:
<facundobatista> DEBUG: list_devices
<facundobatista> DEBUG: usb_find_busses=2
<facundobatista> DEBUG: usb_find_devices=5
<facundobatista> and then it gives me a "symbol lookup error"
<facundobatista> undefined symbol: _ppdGet1284Values
<kees> james_w: haha, I'm curious to see it, regardless.  I figure I'll have to patch shadow to do a preinst change on the file itself.
<tkamppeter> Did you install all binary packages of the CUPS from my PPA? Especially also the new libcups package is needed.
<james_w> kees: well the patch is sensible I think, it's what it implies about the existing code that worries me
<facundobatista> tkamppeter, mmm... let me see... I just installed the .deb you mentioned
<slangasek> calc: I swear we had a conversation about when the next OOo upload was going to be, and now I can't find it in my logs at all... :)  did that conversation happen, and what was the answer? :)
<facundobatista> tkamppeter, oh, I didn't install any libcups...
<tkamppeter> facundobatista: Install also the new libcups2 package.
<kees> james_w: well, you already know my opinion of that code-base.  :)
<james_w> yeah
<james_w> it's not as bad as the other issue thankfully
<facundobatista> tkamppeter, what about libcupsimage2, and libcupsys2?
<james_w> kees: bug 354378 is quite a fun one I found today
<facundobatista> tkamppeter, cups-client? cups-common?
<ubottu> Launchpad bug 354378 in policykit "Deadlock when PAM_TEXT_INFO is used" [Unknown,Confirmed] https://launchpad.net/bugs/354378
<james_w> 'cos I'm sure you haven't got much to do and can spend time looking at random bugs :-)
<tkamppeter> They are not needed. All *cupsys* are even only transitional package which do not contain any files or maintainer scripts.
<kees> james_w: oooh, owchy.
<kees> heh, nah, I like knowing the reality of a situation.  :)
<facundobatista> tkamppeter, ok
<james_w> kees: I also noticed that while the policykit design is pretty sane generally it does actually pass an unencrypted password over a file descriptor at one point
<james_w> as you can see, the user in that bug had to redact it from the strace
<james_w> is that a concern? It seems like it doesn't open too much of a hole.
<slangasek> well, as opposed to doing what with it?
<kees> james_w: well, a fd's not totally crazy.
<UsamaAkkad> any one can tell me who should I ask about this ?
<UsamaAkkad> #251378
<slangasek> unless policykit is running as root, it has to pass it over a pipe to unix_chkpwd
<UsamaAkkad> https://bugs.launchpad.net/ubuntu/+source/synaptic/+bug/251378
<slangasek> for unix auth
<ubottu> Launchpad bug 251378 in synaptic "Synaptic's Generate download script does not update package lists" [Undecided,New]
<kees> james_w: I mean, passwords float through the tty fds, so it's not much different
<james_w> slangasek: yeah, I'm not sure there's an alternative, I thought it was worth asking
<james_w> slangasek: in this case it passes it to a process running as root which can communicate with pam, so it's equivalent
<tkamppeter> facundobatista: Does CUPS now detect your printer?
<slangasek> james_w: hrm, that's... odd. :)
<slangasek> second-guessing PAM?
<slangasek> well; you have to do that if your process is non-root and not running as the user you want to auth
<james_w> yeah
<james_w> often it is, but not always
<james_w> and it needs to add an entry to polkit's auth db anyway, which needs to be root controlled for obvious reasons
<facundobatista> tkamppeter, yes! wee...
<facundobatista> tkamppeter, let me see how it goes
<facundobatista> ...searching for controllers...
<facundobatista> selecting "Foomatic/foo2xqx"
<facundobatista> sending test page print
<facundobatista> printer state: "processing"... and nothing happens
<facundobatista> it just stays there...
<facundobatista> tkamppeter, and one process, from "lp" user, is taking 100% of one processor
<tkamppeter> facundobatista: what is the name/command line of the process ("ps auxwww | grep '^lp '")?
<facundobatista> tkamppeter, that is strange... the command, or at least what appears in the ps or top is:
<tkamppeter> facundobatista: Looks like that thgis backend principally works but does not fix the bug. So it is really as I assumed, the backend is not the culprit.
<facundobatista> "usb://HP/HP%20Laserjet.... 152 facundo Test Page 1 job-...
<tkamppeter> facundobatista: That is the USB backend, it tries to feed the data into the appropriate port of the kernel but the kernel does not let the data in.
<facundobatista> tkamppeter, damn
<facundobatista> tkamppeter, do you want me to comment something in the bug?
<tkamppeter> facundobatista: So your next step is to try running Jaunty wityyh the kernel of Intrepid.
<tkamppeter> facundobatista: Comment these results in the bug. So people who are not here on IRC in the moment (kernel developers perhaps) know what happened.
<tkamppeter> facundobatista: Did you update from Intrepid to Jaunty?
<facundobatista> tkamppeter, question... when I boot, GRUB offers me two kernels: 2.6.28-11, and 2.6.27-11, but both as "Jaunty"
<facundobatista> tkamppeter, yes I did
<tkamppeter> facundobatista: Then you did a fresh Jaunty installation and not an upgrade from Intrepid, or you played around with strange tools like computer-janitor.
<facundobatista> tkamppeter, I upgraded, and didn't run the janitor
<tkamppeter> Strange that all the old kernels go away when you upgrade.
<facundobatista> tkamppeter, don't remember what happened when upgraded from hardy to intrepid...
<tkamppeter> facundobatista: Perhaps you could do the following: Find the kernel package of intrepid on Launchpad and install it onyour system. It should not have dependencies or only dependencies on kernel components. All what you need to install should be packages with version numbers in their names, so nothing of Jaunty should get overwritten. If you reboot then, the old kernel should appear in the boot menu.
<facundobatista> tkamppeter, ok, I'll try that
<cjwatson> slangasek: http://paste.ubuntu.com/143572/ look OK to you? there's only one difference in its output, and it's a bug in ruby's gettext parser :-)
<facundobatista> tkamppeter, (but later)
<slangasek> cjwatson: <laugh>
<cjwatson> slangasek: (it misparses \\r in the middle of multibyte strings as \ \r rather than \\ r)
<m4v> Riddell: mdeslaur: when lcms 1.18 will be available in jaunty repos?
<slangasek> cjwatson: looks good to me!
<slangasek> (and way better than the ruby looked :P)
<cjwatson> slangasek: oh, the only difference is that it needs to be run on .mo rather than .po
<cjwatson> ok, I'll upload it
<slangasek> cjwatson: ...which saves us a step, so. :)
<mdeslaur> m4v: Riddell uploaded it, so it should be on it's way once it's built...in the next hour or two maybe?
<slangasek> cjwatson: does python's gettext module automatically give you utf8, or does it just happen to not be an issue?
<m4v> mdeslaur: ah, thanks! :D
<amgarching> does it make sense trying to install gcc-snapshot (20090327-0ubuntu1) from Jaunty repos onto Intrepid?
<cjwatson> slangasek: the ugettext method gives you a Unicode string
<slangasek> cjwatson: spiff
<cjwatson> there are a few charset=EUC-JP .po files in there
 * slangasek nods
<alex-weej> any Qt maintainers/experts here? got a bug in Jaunty wrt font settings
<jpds> alex-weej: Maybe #kubuntu-devel might be able to help.
<alex-weej> jpds: ta
<calc> slangasek: hopefully later today or by end of weekend at latest
<slangasek> ok
<calc> slangasek: i was holding off on the upload until after lp 2.2.3 came out wed night
<slangasek> ah, right
 * calc wishes bugs were harder to file, keep getting duplicate bug reports, argh
<ScottK> calc: How about LP had a better U/I for moving people to accepting something is a dupe?
<calc> ScottK: that might help too... though the percentage of non apport bugs suggests they would still try to file bad bugs :\
<ScottK> I think the current 'would you like to subscribe to one of these' approach is not an appealing alternative to filing a new bug.
<maxb> Didn't update-manager used to keep its progress window open if you'd expanded the embedded terminal view?
<maxb> It seems to have stopped doing that for me.
<maco> Jaunty has version 2.4.12 of Openswan, but the current 2.4.x (which has security fixes) is 2.4.14.  Aside from that there's a 2.6.21.  Would it make more sense to grab last week's security patch and apply it to what we've got or to update to the latest release of the 2.4.x line?
<ScottK> maco: If it's bugfixes only, probably just update.
<maco> yep, memory leaks and security bugs
<rolianne> hi.. why is my newly installed 8.10 cant connect to the internet? what should I do?
<rolianne> err
<rolianne> bye
<phaidros> hi, I have seen in launchpad as well in package names that there is a hardy version 8.04.3 and 8.04.4 .. all my uptodate machines are 8.04.2
<phaidros> is .3 and .4 planned? or virtual?
<LaserJock> phaidros: have a look at the bottom of https://wiki.ubuntu.com/HardyReleaseSchedule
<phaidros> ah ic, thanks LaserJock
<NCommander> cjwatson, how'd your testing w/ my shadow patch go?
<BUGabundo> hi guys
<BUGabundo> where would I redirect bug 354682 ?
<ubottu> Launchpad bug 354682 in casper "Casper advance option for edubuntu" [Undecided,New] https://launchpad.net/bugs/354682
<BUGabundo> maybe evan?
<gon> <gon>: Hi <gon>: I have some problems connecting to wireless network in some place <gon>: In 8.10 works fine, but in jaunty can't connect
<hyperair> gon: wrong place to ask. head to #ubuntu.
<hyperair> i mean #ubuntu+1
<gon> !
<BUGabundo> hyperair: we won't be able to help him much there either
<hyperair> BUGabundo: really?
<BUGabundo> lets see
<hyperair> BUGabundo: what be up anyway
<BUGabundo> if it is user stuff we can
<BUGabundo> if it is packages stuff, most of us in there won't be able to help much
<BUGabundo> which seem to be the case
<hyperair> does it really?
<hyperair> what seems to be the issue then
<BUGabundo> humm
<BUGabundo> he is using knetworkmanager
<BUGabundo> which is broken badddddd
 * hyperair quickly backs away.
 * hyperair hides in the corner
 * hyperair waves a flag saying "network-manager-gnome banzai!"
<BUGabundo> eheh
<BUGabundo> pop up on +1
<BUGabundo> all help is appreciated
<hyperair> but i've never even used kde before
<hyperair> well i ahve, but not more than a week.
<hyperair> never got past configuring it.
<LaserJock> BUGabundo: what do you mean by "when booting with casper"?
<BUGabundo> I don't use it either
<BUGabundo> but I do help on anything users trow at me
<BUGabundo> LaserJock: humm the boot from CD/USB
<hyperair> BUGabundo: i would help, if my accounts exam isn't in 10 days ;)
<BUGabundo> isn't that casper?
<hyperair> casper's a friendly ghost
<LaserJock> BUGabundo: from the Desktop CD, yes
 * BUGabundo makes some voodoo and gets hyperair exams reschedule
<hyperair> BUGabundo: if only that worked =(
<BUGabundo> LaserJock: then that's what I'm trying to say
<LaserJock> BUGabundo: what specifically does the F6 menu say?
<BUGabundo> Show extra options
<BUGabundo> like acpi off, etc
<LaserJock> right
<BUGabundo> go buntu
<LaserJock> and there is one that says "Edubuntu"?
<BUGabundo> one of them is for Edubuntu
<BUGabundo> but its badly worded
<BUGabundo> just says edu=on
<LaserJock> how odd
<BUGabundo> no oned guess what that is
<BUGabundo> I ask on the bug to re-write it with
<BUGabundo> just Edububuntu
<BUGabundo> and then the Flag enabled by the user
<BUGabundo> LaserJock: does it makes any sense to you ?
<LaserJock> not yet, no
<BUGabundo> if it is an option, just saying what it is, should be enough
<BUGabundo> no need for "edd=on"
<LaserJock> is it edd or edu?
<BUGabundo> no sure now
<BUGabundo> you got me confused
<BUGabundo> eheh
<BUGabundo> bbl
<pjwaffle> hi
<mnemo> thiebaude: what intel chipset is it you're having problems with btw? (you can tell using "lspci -nn | grep VGA")
<thiebaude> 00:02.0 VGA compatible controller [0300]: Intel Corporation 82815 Chipset Graphics Controller (CGC) [8086:1132] (rev 04
<thiebaude> i can log into gnome only using 2.6.24-24 generic kernel
<thiebaude> ubuntu 9.04 works, but only with the older kernel
<mnemo> hmm, so its some sort of regression then :(
<thiebaude> yea, i've had no problems with alpa's and beta's and i've been using ubuntu since 6.06
<thiebaude> i've had this 81815 since 6.06
<mnemo> thiebaude: can you please open a bug in LP explaining this?
<mnemo> use the command "ubuntu-bug xorg" to file it
<mnemo> then it will attach lots of interesting data automatically
<thiebaude> ubuntu web site says bug 304871
<ubottu> Launchpad bug 304871 in xserver-xorg-video-intel "[i845G] Fatal server error: Couldn't bind memory for BO front buffer (Jaunty)" [High,Fix released] https://launchpad.net/bugs/304871
<thiebaude> ok
<mdke> superm1: no worries :)
<pjwaffle> hey how do you base a distribution off of another distribution eg. ubuntu
<pjwaffle> I would like to use the init scripts and maybe apt-get to create a rolling release distro
<pjwaffle> IMHO ubuntu needs a rolling release distro to test really early development packages eg. kernel 2.6.29
<pjwaffle> like debian's sid
<BUGabundo> pjwaffle: go try fedora
<mnemo> fedora is not rolling release
<BUGabundo> we need some time to stablize
<mnemo> try rawhide
<pjwaffle> I know they have rawhide but I use apt-get and debian packages
<BUGabundo> and then the next cycle begins again
<BUGabundo> for cutting edge use bzr or PPAs
<pjwaffle> and sid is not so driver-friendly
<mnemo> pjwaffle: ubuntu offers the ability to test mainline kernels and latest xorg bits though
<pjwaffle> well you know my question is how do you base off another distro?
<pjwaffle> I would consider myself an intermediate/early-experienced user
<BUGabundo> either use what is available to you or package your own newer versions
<pjwaffle> I mean do you just use cp and copy the init scripts to your chroot or what? isn't there a version control for the entire ubuntu distro?
<savvas> any main sponsors here? I would like your opinion on bug #315679 - should I try to merge the new version of libmtp from Debian?
<ubottu> Launchpad bug 315679 in libmtp "Please merge libmtp 0.3.0-1ubuntu3 (main) to 0.3.6-1 from Debian (experimental)" [Wishlist,Confirmed] https://launchpad.net/bugs/315679
<pjwaffle> well ok fine what is the ubuntu repo for the initscripts on bazaar
<BUGabundo> LaserJock: ping
<LaserJock> BUGabundo: yeah?
<BUGabundo> how can I make the bug clear?
<cjwatson> pjwaffle: unfortunately not everything is in revision control (yet)
<BUGabundo> you seemed to have some questions about it?
<cjwatson> BUGabundo: that casper bug? it's invalid.
<pjwaffle> oh :(
<cjwatson> edd has nothing to do with edubuntu
<BUGabundo> cjwatson: :(
<LaserJock> that's what I was trying to figure out
<BUGabundo> ok that makes it clear
<BUGabundo> what is it then?
<LaserJock> I couldn't see why there would be anything Edubuntu in the menu
<cjwatson> I replied to your bug
 * BUGabundo looks
<cjwatson> pjwaffle: we hope that this will be rectified over the next release cycle or two, though
<BUGabundo> BIOS Enhanced Disk Drive Services 3.0 (EDD)
<BUGabundo> got it
<BUGabundo> still its bad wording, no?
<cjwatson> pjwaffle: merges.ubuntu.com helps us to deal with the six-monthly merge from Debian
<BUGabundo> no need to have the ON there!
<cjwatson> BUGabundo: it's advanced options. I don't care.
<cjwatson> BUGabundo: the kernel option is literally "edd=on"
<BUGabundo> ok ok
<BUGabundo> then never mind
<BUGabundo> sorry for the noise
<cjwatson> NCommander: uploaded
<cjwatson> sorry for the delay
<NCommander> cjwatson, no problem
<mvo> kirkland: I updated #352307
<kirkland> bug #352307
<ubottu> Launchpad bug 352307 in ecryptfs-utils "update-notifier message about recording mount passphrase" [High,In progress] https://launchpad.net/bugs/352307
<mvo> kirkland: you probably cover the server use case already with update-motd? I'm not sure if kde supports this feature of update-notifier though
<kirkland> mvo: i don't ...  we don't have per user messages in update-motd ...  i'll need to think about this
 * mvo nods
<mvo> update-notifier-text
<kirkland> mvo: actually, for intrepid, we handled it in the alternate/server case in the installer
<kirkland> mvo: there was a page that popped up, and showed the user their password, and told them to record it
<kirkland> mvo: for some reason, that page isn't getting displayed in Jaunty
<mvo> right, I remember this page I think
<kirkland> mvo: i've ping cjwatson about turning that back on
 * mvo nods
<kees> james_w: is there actually a bug open for the g-s-t UID_MIN rewriting?
<james_w> kees: nope
<Amaranth> mvo: Do you think the nvidia workaround should be on by default?
<james_w> kees: do you think a task on the existing bug would be appropriate, or a new bug?
<Amaranth> Although I don't think the workaround is included in the packages right now...
<kees> james_w: probably a task, keeps it all in one place
<kees> james_w: which src pkg should I open it against?
<james_w> system-tools-backends
<mvo> Amaranth: which one?
<kees> james_w: okay, cool.  assign it to you?
<Amaranth> mvo: bug 269904
<james_w> kees: sure
<ubottu> Launchpad bug 269904 in nvidia-graphics-drivers-180 "Screen refresh problems with nvidia on intrepid" [Undecided,Confirmed] https://launchpad.net/bugs/269904
<Amaranth> mvo: It's a pretty simple patch but it causes a small performance loss
<Amaranth> mvo: http://launchpadlibrarian.net/23889138/compiz-fusion-plugins-main_0.8.2-0ubuntu2.debdiff is the relevant bit
<mvo> Amaranth: I remember seeing the commit in git, but that does make everything pretty slow dosn't it. or is the nvidia HW fast enough to deal with this kind of syncs?
<Amaranth> mvo: nvidia hardware is plenty fast to handle it, not sure how other systems will
<Amaranth> mvo: I don't think there is that much of a slowdown but the only people that have tested it are nvidia users
<Amaranth> I don't really have time to play with it until tomorrow but I can try it on intel then
<mvo> I'm pretty sure we have the half-fix from aaron, this workaround a bit scary. also having it sounds fine
<Amaranth> Just wanted to make sure you saw it
<mvo> enable-by-default hmmmmm
<mvo> Amaranth: please try
<mvo> Amaranth: we could add more magic to compiz-manager to enable it only for peole with -180
<mvo> Amaranth: my intel system had a mainboard meltdown, I can test this at monday afternoon (then I should get a replacement)
<gouki> Anyone has a jaunty debootstrap script?
<mvo> Amaranth: thanks a lot for raising it!
<kees> gouki: I also just use mk-sbuild-lv, but that's pretty LVM/sbuild-specific
<Amaranth> mvo: true, we already detect nvidia in there
<Amaranth> mvo: I guess I've got a couple minutes, let me get it built
<mvo> Amaranth: I apply the diff, having it is certainly good and will not do any harm
<gouki> kees, I wanted to create a jaunty file system for user-mode linux.
<kees> gouki: hrm, in that case, I'd just use debootstrap directly
<Amaranth> mvo: I've got it enabled now on X3100, seems fine
<Amaranth> mvo: seems to make Xorg CPU usage go up a couple percent though
<gouki> kees, but I still need the specific options for jaunty present on the /usr/share/debootstrap/scripts, right?
<kees> gouki: nah, just symlink intrepid to jaunty
<kees> they're mostly already symlinks.  :)
<Amaranth> mvo: should probably put out a call for testing after a package with the fix is uploaded, see if anyone notices problems with various hardware after a couple days use
<mvo> Amaranth: right, I will just upload the fix with the enables "false" default for now so that people can at least enable it
<mvo> Amaranth: and ponder about it some more later
<gouki> kees, but there isn't even a hardy (nor intrepid, for that matter) script on the debootstrap package. :S
<jpds> gouki: There are, they all link to hardy's.
<maxb> gutsy's, actually
<kees> yeah, link to gutsy.
<kees> $ dpkg -L debootstrap | grep hardy
<kees> /usr/share/debootstrap/scripts/hardy
<maxb> gouki: Are you using a really out of date debootstrap?
<kees> $ ls -la /usr/share/debootstrap/scripts/hardy
<kees> lrwxrwxrwx 1 root root 5 2009-03-19 17:17 /usr/share/debootstrap/scripts/hardy -> gutsy
<gouki> maxb, I was under the impression I tested with debootstrap from jaunty, but that clearly isn't the case.
<gouki> Well, thank you all very much for the help. :)
<kees> np
<gouki> It's there indeed :) My bad.
<picklesworth> Hey folks! What's the status on appending notifications for Pidgin? Any way I can help that along?
<YokoZar> picklesworth: what kind of notifications
<YokoZar> you mean like more than one at once?
<picklesworth> ( Speaking of Pidgin, it's being hopelessly unstable today :/ )
<maxb> mvo_: I think update-manager used to not auto-close its progress window if you display the embedded terminal - was this a deliberate feature? It seems to have broken.
<mvo_> maxb: there is a checkbox for this that should remember its state
<mvo_> maxb: assuming you mean normal update and not release upgrades ?
<maxb> yes, normal updates. Where is this checkbox? I've not seen it! :-)
<maxb> (ever!)
<mvo_> maxb: did you every switched it when running synaptic normally?
<mvo_> maxb: give me a sec, i check the name
<mvo_> maxb: /root/.synaptic/synaptic.conf - there is a option called "closeZvt" - what values does that have?
<maxb> Not present in the file
<maxb> on one of my machines, that is. Set to "false" on the other, but it still closed.
<mvo_> maxb: hm, odd. let me try to reproduce
<mvo_> maxb: heh :) turns out this was changed back in intrepid, the key to control it is /apps/update-manager/autoclose_install-window
 * mvo_ has faulty memory
 * maxb fires up gconf-editor
<maxb> It's on... but not in my per-user gconf
<maxb> Also, IIRC it didn't always close or always not-close - it depended on whether you expanded the Details terminal or not
<mvo_> oh, I see now what you mean. I don't think it was that clever, but actually that would be a good feature
 * mvo_ is a bit tired already
<maxb> How puzzling. Surely I can't have hallucinated this feature? :-)
 * maxb boots intrepid for some comparative testing
<mvo_> maxb: let me know, but I will have to crash soonish. just poke me when I'm online again
<maxb> Huh. It doesn't work on Intrepid either, which suggests I may have somehow managed to totally confuse myself
<maxb> I will grab a colleague who's still running Hardy on Monday for further experimentation.
#ubuntu-devel 2009-04-04
<cjwatson> slangasek,sbeattie: BTW, I fixed bug 301430 just now in ubiquity, partly because otherwise d-i and ubiquity are out of sync, but I have a nagging worry that this may expose some late ipv6/localhost problems
<ubottu> Launchpad bug 301430 in ubiquity "ipv6 /etc/hosts missing localhost hostname" [Medium,Fix released] https://launchpad.net/bugs/301430
<cjwatson> if you spot anything that looks like it might be that, let me know ...
<cjwatson> I'm also conscious that there may not be time to fix netbase for upgrades
<kirkland> mvo: hiya, are you actually around?  :-)
<ezyang> Hello all; I noticed that xvm-3.3 has three bugs complaining about missing docs. Anything I can do to help fix this?
<maxb> Is it automatically a bug to clobber configuration files in /etc/, or are there any exceptions?
<dtchen> TheMuso: / pgraner: what do you think of muting "PC Beep" unconditionally?
<maxb> kees: That shadow upload.... the arguments to grep are the wrong way around in the the preinst :-)
<ezyang> Where is the source code repository for xen-3.3?
<dtchen> ezyang: meaning Ubuntu or upstream?
<ezyang> Ubuntu.
<ezyang> I'm on the launchpad page but there's no code tab.
<maxb> Are there Vcs-* keys in the control file?
<ezyang> No.
<dtchen> ezyang: http://package-import.ubuntu.com/x/xen-3.3/jaunty/files
<ezyang> Thanks! How would I find that page in the future?
<dtchen> ezyang: it's organised alphabetically by source package
<ezyang> Ok
<ezyang> dtchen: Would you happen to know why xen-utils-3.3 doesn't have docs anymore?
<dtchen> ezyang: have you installed xen-docs-3.3?
<ezyang> xen-docs-3.3 is an empty package
<ezyang> xen-utils-3.2 used to be the package with the docs
<dtchen> ezyang: hmm, probably not being built at all. i don't see doxygen in the build-dependencies at least. you'll probably want to ask zul; he's likely far more familiar with the source package than i am.
<ezyang> I suspect what happened is that the docs where removed from xen-utils-3.2 to be placed in xen-docs, but then that never happened.
<ezyang> Why do the bzr branches seem not to be connected to each other?
<ezyang> As in, I can't actually tell when the change was introduced without laboriously stepping through each branch
<dtchen> ezyang: perhaps you'll find https://launchpad.net/ubuntu/+source/xen-3.3 more efficient
<ezyang> arrgh
<ezyang> I'm used to being able to point at a file, and see all of its history
<ezyang> This is very different
<ezyang> So, if I understand correctly, package-import doesn't actually have development done on it?
 * calc is prepping new OOo upload and it appears the server hosting the upstream OOo translations is dead :\
<slangasek> cjwatson: hmm. :/ ok, will keep a watch out
<bryce_> wiki.ubuntu.com seems DOA
<kees> maxb: yeah, fix building now.  that's what I get for a friday night upload.
<Hobbsee> hrm.  usb sticks really don't mount in jaunty anymore.
<sbeattie> Hobbsee: hrm, really? works here.
<sbeattie> ... though my usb fs with a space in the label gets it mapped to _ on the mount; that might be new behavior.
<slangasek> tjaalton: how did you reach the conclusion that bugs 351756 and 352581 are dupes of 354688?  The backtraces are entirely different.
<ubottu> Bug 351756 on http://launchpad.net/bugs/351756 is private
<slangasek> for that matter, 351756 and 352581 both refer to UXA, which I'm *not* using...
<tjaalton> slangasek: same error message
<tjaalton> well, they were duped together
<slangasek> which error message is the same?
<tjaalton> http://dl.getdropbox.com/u/256410/IMG_0479.JPG
<slangasek> but that's not the cause of the crash
<slangasek> I only noticed DRI wasn't active after I started investigating the crash...
<tjaalton> hrm ok
<slangasek> shall I undupe?
<tjaalton> sure
<mdke> slangasek: got a sec?
<mdke> slangasek: never mind, sorted I think
<c0p3rn1c> who is responsible for packaging mplayer ?
<c0p3rn1c> n/m
<c0p3rn1c> Kmos: thx, yeah I figured that out by myself after asking the question :-)
<mnemo> c0p3rn1c: ubuntu doesnt have specific persons responsible for each package... but there might be someone who usually ends up packing it.... see "aptitude changelog mplayer"
<c0p3rn1c> mnemo: I've send the whole MOTU media team a message about it
<mnemo> yeah that's probably the best way
<c0p3rn1c> mnemo: thx anyways, maybe I'll use that command in the future, still kinda new to all of this(bin using ubuntu for about 6 months)
<mnemo> :)
<c0p3rn1c> I'm slowly trying to help ubuntu to improve more and more, currently I'm only reporting bugs and trying to get new technology to the main stream, btw where would best I start to learn programming in the linux environment, 10 years ago I have bin coding visual c++ but since then I only have bin programming java/perl/vb.net
<mnemo> im sort of in the same position.. but I've been using ubuntu since 2007
<mnemo> one thing I learned is that its good for focus on a few things and do them really well
<mnemo> i filed a lot of random bugs in the beginning and didnt follow up much on them
<mnemo> but its better to learn deeply and some programs so you can file really good bug reports for those packages
<c0p3rn1c> yeah, I don't have that much time anyways, I would love to be an open source programmer though but I don't know if there are any well payed jobs for it
<c0p3rn1c> in the US yes, but not in the EU
<mnemo> well nokia does a lot of gnome stuff for maemo, qt software in oslo, fluendo in spain, and google will let you work on open source as a 20% project
<mnemo> openisimus in germany, codethink and collabora in the UK
<c0p3rn1c> mnemo: yeah but I'm scared to work for google lol
<mnemo> heh yea
<mnemo> or go work for canonical ofc ;) seems like a great company
<c0p3rn1c> I'm even scared to ask for an internship, I'm petty gifted for programming but I've not exactly bin an A student
<mnemo> yeah its probably harder right now with the bad economy etc
<mnemo> but maybe start learning more deeply about linux
<mnemo> try to come a MOTU etc
 * c0p3rn1c is googling MOTU
<c0p3rn1c> Masters Of The Universe lol
<c0p3rn1c> nice :-)
<mnemo> =) thats the team that brings you most of the software in ubuntu
<c0p3rn1c> ic
<YUNGMIZZ> HEY WATS GOOD
<htrejh> hi
<htrejh> did something change in jaunty, i am a gfire dev (pidgin plugin for xfire) and now it crashes, seems to ba MALLOC_CHECK or something like that
<htrejh> did something change in the system vars or in gcc?
<dreamcoder> is anyone else having issues with greatly reduced download speeds in jaunty? via wireless
<dreamcoder> i am downloading at less than 700 when it should be 2400
<sits> is the first user not being added to the audio group etc. a known and fixed bug?
<the_dark_warrio> When watching a movie in fullscreen, the new message system makes the screen blink. Is this a known bug?
<directhex> oh, the notification thing causes that?
<jpds> Yeah, I have that too.
<hyperair> blink?
<hyperair> i don't have that
<hyperair> in the first place, the notification shouldn't happen when watching a movie in fullscreen
<hyperair> unless you're watching videos from veoh, which has the stupidest web player you can ever find.
<james_w> it won't if the movie player inhibits the screensaver
<the_dark_warrio> well
<the_dark_warrio> its vlc
<hyperair> ah vlc
<hyperair> what gpu?
<the_dark_warrio> I'm using nvidea
<hyperair> ah nvidia
<hyperair> but that's strange, i thought nvidia was better than intel in this aspect =\
<hyperair> i'm using intel, but if there's one thing that really works well, it's compositing on top of videos
<cjwatson> htrejh: many things have changed, including new upstream versions of the toolchain - but chances are it's a bug in your program that this just happened to expose. Try using valgrind
<htrejh> ok thanks
<Afifi> hi
<Afifi> how to change the default user settings ?
<ScottK> Afifi: Ask in #ubuntu (or #ubuntu+1 if you are running Jaunty)
<Afifi> ok thank you
<slangasek> cjwatson: bug #327819 seems to indicate the kerneloops MIR is deferred until karmic; should I unseed this from desktop?
<ubottu> Launchpad bug 327819 in kerneloops "Main Inclusion Report/Request" [High,Triaged] https://launchpad.net/bugs/327819
<slangasek> cjwatson: or is there something I'm overlooking in that bug, that's a reason to keep it in the seed?
#ubuntu-devel 2009-04-05
<cjwatson> slangasek: if it's deferred, it's fine by me to unseed it
<cjwatson> slangasek: I think I seeded it when there was still some question
<slangasek> ok
<slangasek> unseeding then, thanks
<slangasek> superm1: ok, I've traced through hotkey-setup now, and I think the video/DOS stuff is the only thing left that does anything useful... I just got a bug report about why the remaining thinkpad key mask stuff is doing the /wrong/ thing... :)
<dtchen> james_w: how often is package-import.u.c refreshed?
<james_w> dtchen: regularly, but it's down at the moment I'm afraid
<dtchen> aww
<james_w> there won't be anything newer than around 3 days currently, sorry
 * dtchen just sends upstream the git changesets instead
<james_w> Something has changed about the network and I haven't looked for someone to fix it for me yet
<james_w> when it comes back up it will be based on launchpadlib though, which will give a latency of ~5 minutes on average I think
<dtchen> cool!
<james_w> that's accepted -> available for "bzr branch"
<RAOF> Anyone here a PPC fan?  I have no idea why ld is trying, and failing, to access crtsavres.o in this log http://tinyurl.com/dj8f9h
 * ScottK suggests TheMuso when he's around.
<rvn> https://bugs.launchpad.net/ubuntu/+source/tkdesk/+bug/234055
<ubottu> Launchpad bug 234055 in tkdesk "Hardy tkdesk crashes on startup" [Undecided,New]
<rvn> nobody has addressed this since hardy
<rvn> can someone please look at that
<rvn> it's still affecting the package in 8.10
<rvn> the app needs to be updated to find newer versions of the packages it depends on that are shipped with the OS
<rvn> not a hard fix i imagine
<twb> Can someone with a firefox installed please tell me what its x-www-browser alternative priority is set to?
<twb> The file is /var/lib/dpkg/alternatives/x-www-browser
<geofft> On my Intrepid ubuntu-standard system, 40
<geofft> (it's being overriden by xlinks2 at priority 69)
<twb> Really?!
<twb> On Debian it's 70
<twb> Any idea why that's different?
<ebroder> We were talking about this elsewhere early. My theory is that x-www-browser wants to be something that launches quickly - i.e. you get an HTML attachment, you want to open it, see the file, close the window
<ebroder> Firefox is too bulky for that kind of usage
<ebroder> But that's just a theory - I don't know the real reasoning
<geofft> I think Jaunty has firefox at a higher priority
<twb> The current ordering on Debian is ridiculous
<twb> galeon and netsurf are up the top
<twb> Have I got this right?
<twb> "My understanding of Ubuntu numbering is that it is -0ubuntu1 only if it is actually modifying an imported Debian package of version -0.  If it's a native Ubuntu package that has no relation to any Debian package, then it would just be -1."
<twb> Er, and by "native Ubuntu" I really mean "not based on a Debian package".
<infinity> twb: There are very few "native Ubuntu" packages in that sense, though.
<twb> infinity: upstart and such
<twb> infinity: but I've understood correctly, right?
<laserjock> I don't think it'd be a -1, that would mean it was a Debian package
<infinity> twb: Mostly, we view "packaged for Ubuntu first" packages as being "stuff that Debian hasn't gotten around to yet", and stick with the 1.2.3-0ubuntu1 versioning, so we get the merge hint if/when Debian picks it up.
<twb> infinity: OK, I wasn't aware.
<twb> infinity: is this new since, say, 2006?
<laserjock> if it's really a native package you'd just do <version>
<twb> laserjock: yeah, I misused the word "native"
<laserjock> k
<infinity> twb: upstart's versioned without the -XubuntuX mostly because Keybuk chose to do it that way, IMO.  Not due to any particularly strict policy on who upstream is.
<infinity> twb: And no, none of the versioning policy is particularly new.  We've been informally doing things pretty much the same way since warty.
<twb> Fair enough.
<infinity> twb: But the "only packaged in Ubuntu, and nowhere else" case is fuzzy, and sometimes it goes the way of ustrart, sometimes it goes the -0ubuntu1 route, generally depending on how likely the packager thinks it is that Debian will ever pick it up.
<twb> infinity: may I quote you on the debian-haskell list?
<infinity> twb: (And using versions without "ubuntu" means the archive admins have to add a manual blacklist to the sync process (we have one for upstart), "just in case" Debian ever ships a version)
<twb> infinity: well, Debian does ship upstart, but only in experimental
<infinity> twb: Right.  And when that moves to unstable, we'd accidentally sync it if we didn't have the blacklist.  Hence the issue.
<twb> Huh.  I thought syncs were manual unless there were no differences.
<infinity> twb: The fact that Keybuk happens to have been intimately familiar with the sync process, and blacklisting therein, may have influenced his versioning. :)
<twb> Oh, I guess "no differences" is determined by the presence of ubuntuN
<infinity> twb: Right.  Syncs versus merges are entirely based on version numbers.
<twb> OK, thanks.  May I quote your comments above?
<infinity> twb: When we autosync, anything that's not XubuntuX is auto-synced if Debian has a higher version number (unless we blacklist it).
<infinity> twb: Quote away.
<twb> Thanks.
<DreadKnight> heya
<DreadKnight> blender shows up very crappy ... guess bad video drivers
<DreadKnight> i have ATI intel GMA 950
<foxbuntu> DreadKnight, I think you might be asking for help in the wrong channel try #ubuntu
<DreadKnight> well, i have jaunty :P
<DreadKnight> bah im such and bleeding edge freak..
<twb> DreadKnight: #ubuntu+1, then, I think
<DreadKnight> oh ok
<twb> But I thought 9.04 was already released?
<foxbuntu> twb, not yet
<twb> Oh, 23rd
<twb> Someone confused me!
<foxbuntu> :)
<DreadKnight> lol
<DreadKnight> beta released.. channel topic
<gene2> I hate asking this here, but I've searched and searched, asked on #ubuntu and got nowhere. I'm looking to find the source for linux-image-2.6.24-23-rt, when I get it using apt-get source linux-image-2.6.24-23-rt, I get the regular source with the Ubuntu patch but the preempt stuff is missing, because when I tr to load the config I have running it complains about a bunch of preempt variables not existing
<gene2> I'd like to rebuild this package but I just cannot locate the ubuntu patch for 2.6.24.7-rt21, the original one does not apply clean
<twb> gene2: look in debian/patches/ ?
<gene2> yes sir
<twb> There might be an #ubuntu-kernel or something.
<gene2> there is no patches director in the debian directory
<gene2> thanks, I'll give it a try
<twb> Unfortunately I don't know how Ubuntu does its kernel packaging, so I can't help further.
<twb> Theroretically kernel-package was once used, but AIUI that was long ago
<gene2> got ya
<cjwatson> gene2: by definition the only source that can possibly be used for our -rt kernel is contained in 'apt-get source <package name>' and in the build-dependencies listed in debian/control
<cjwatson> gene2: the build system simply won't use anything else - so if you're not seeing something, either you're missing it or it's not there :-)
<gene2> cjwatson: I was under the same impression but I'm telling you parts of the preempt-rt patch are missing
<cjwatson> *shrug* the builds don't happen by magic
<cjwatson> I don't know anything about the -rt kernel, I'm just giving you immutable rules for how our build system works
<gene2> I agree, I'm going file by file looking how this patch might get applied but the way I see it now, the patch is not there
<cjwatson> perhaps the patch you're looking for is not in fact applied then?
<gene2> perhaps so, it is very likely, but I cannot find where the patch lies then, when I grab the patch from the original maintainer, I can see it applies like 75%, so obviously it is not applied, the problem is I cannot find how it is applied using the rules anywhere
<cjwatson> in the version you're looking at, patches are in debian/binary-custom.d/rt/
<gene2> omg, thank you so much! I see it now, I really appreciate your help
<cjwatson> I think 'debian/rules custom-prepare-rt' will give you buildable source ... somewhere
<gene2> yes, looks like it, except i was not aware of the -prepare, this will help a lot instead of applying those by hand
<gene2> thank you so much for your help, its 3:40am here, I can go to sleep now and figure out the remaining tomorrow
<cjwatson> debian/build/custom-source-rt/ by the looks of things
<cjwatson> is where custom-prepare-rt puts it, with the expectation that it be built with something like 'make -C debian/build/custom-source-rt O=debian/build/custom-build-rt' - see debian/rules.d/6-binary-custom.mk
<gene2> I ran fakeroot debian/rules custom-prepare-rt it applied all the patches and crapped out in the end, trying to execute something, I'm getting tooo sleepy to figure out what
<cjwatson> gene2: for reference, the build system starts from a clean extracted source package (from dpkg-source -x) with 'debian/rules build'
<cjwatson> of course that will build all sorts of other stuff first
<cjwatson> but that's where to start if you want to trace this through
<cjwatson> (it'll later run 'fakeroot debian/rules binary' or a close equivalent)
<cjwatson> in general 'debuild -b' will rebuild a package from source with no changes; you can apply changes on top of that by first editing the working tree and probably also editing debian/changelog to give it a different version number
<siretart_> I've merged lintian 2.2.9 for personal use, now I wonder if it was acceptable to upload it to jaunty at this point.
<gene2> I see
<cjwatson> you can pick apart the build system by hand to rebuild just the -rt bit, which will use less machine time, but it might use less human time to just rebuild the lot ...
<cjwatson> siretart_: I'd rather not, it moves to a newer version of policy than is in Ubuntu
<siretart_> ok
<cjwatson> siretart_: is there some particular fix you want?
<siretart_> its in my ppa anyway..
<siretart_> cjwatson: I'm working on debian packages for unstable, so I'd like to check against policy 3.8.1
<cjwatson> ISTR I was reasonably deliberate in merging only up to 2.2.5 recently
<cjwatson> if you're working on Debian packages, why not use a Debian chroot with Debian's lintian package installed?
<cjwatson> that's what I do
<cjwatson> since Debian requires binary uploads you need a chroot anyway
<siretart_> hm..  the main reason is that I use emacs-client to connect to my 'main' emacs session
<cjwatson> isn't that just a matter of some bind-mounts?
<siretart_> perhaps I can make the debian chrooted emacsclient connect to the outside emacs? - /me goes investigating..
<cjwatson> I have a bunch of hacky scripts which set up a chroot with all sorts of bind-mounts and shims for this kind of thing
<cjwatson> (they're pretty specific to me but also not hard to reinvent)
<Mithrandir> you generally just want $HOME and /tmp, don't you?
<Mithrandir> schroot can do that for you easily enough
<siretart_> and perhaps /srv/scratch/packages...
<cjwatson> and /proc /sys /dev /dev/pts, and I actually mount bits of $HOME and /tmp separately rather than the whole thing. Also I transfer xauth and iceauth data into the chroot
<cjwatson> and /etc/resolv.conf
<cjwatson> I might look into schroot/dchroot one day
<siretart_> skip dchroot, schroot replaces it
<slangasek> schroot is very nice
<slangasek> proc and /dev/pts are handled by default; as are /home and /tmp, but your mounts are just a config file anyway
<Mithrandir> slangasek: resolv.conf should arguably be done by default too.
<slangasek> maybe it is
<slangasek> I'm not sure I've looked :)
<slangasek> it is
<slangasek> :)
<slangasek> $ cat /etc/schroot/copyfiles-defaults
<slangasek> /etc/group
<slangasek> /etc/hosts
<slangasek> /etc/passwd
<slangasek> /etc/resolv.conf
<slangasek> /etc/shadow
 * hyperair thinks that was more than 3 lines of a paste. =p
<slangasek> you are correct
<siretart_> indeed. emacsclient "just works"...
 * cjwatson installs schroot and puts it on the "when I get round to it" list, then
<slangasek> schroot+lvm snapshotting == win
<cjwatson> mm, unfortunately attempting to convert laptop in-place to lvm == loss, probably
<slangasek> ah, yeah
<slangasek> :)
<A4Tech> Hi, Please Give, I collect deb package but it will be the program of the scripts.
<A4Tech> ie make and install the files I have no. What should I do?
 * hyperair tries very hard to understand and fails.
<A4Tech> hyperair what you do not understand? :)
<hyperair> your two sentences.
<A4Tech> I need to collect the deb package, which will be only 2 Script and a pair of directories
<A4Tech> and that he has set this in ~/.gnome2/...
<Mithrandir> are you asking for help on how to build a deb package?
<A4Tech> Mithrandir yes)
<A4Tech> written everywhere how to build packages from source
<A4Tech> but I have some bash scripts
<cjwatson> then you take the standard advice for building packages from source, but just leave out the bits about compiling things
<A4Tech> hmm, and where to edit the path, which will set the contents of the package?
<cjwatson> man debhelper (and then read the various other manual pages linked from that; dh_install in particular may be relevant)
<A4Tech> ok
<RAOF> Poot!  When did compiz start preventing gnome-do from presenting properly?
 * RAOF looks learily at the recent focus_on_map patch.
<RAOF> Oh, dear.  It seems that compiz is no longer putting splash windows on the top of the z-order, where nature intended.
 * hyperair hates splash windows anyway
<RAOF> hyperair: One _tiny_ problem: gnome-do takes out a keyboard & pointer grab, and is a splash window...
<hyperair> what? seriously?
<hyperair> i thought it was a dock.
<hyperair> oh whoops sorry i was thinking of docky =p
<RAOF> That would be the 'docky' interface, added quite recently.  Which is a dock, and hence doesn't suffer from the problem.
<hyperair> yeah
<RAOF> All the other interfaces _are_ splash windows, take out grabs, and then aren't positioned above other windows.  This makes the computer appear to behave quite strangely!
<hyperair> hmm
<RAOF> Compiz has an awesome dependency graph.  It includes such wonders as libxine-dev.
<crdlb> what pulls that in? O_o
<RAOF> Some kde4 stuff, which depends on phonon, which depends on libxine.
<hyperair> lol nice
<crdlb> ah, wait isn't that the point of phonon? :P
<RAOF> No.
<hyperair> why does compiz depend upon kde4 again?
<crdlb> to build kde4-window-decorator et al.
<Mithrandir> build dependency graph != dependency graph, though
<RicardoPerez> andersk: Hi. Can I chat with you about the bug #269904 ? I've a refresh problem with the clock applet
<ubottu> Launchpad bug 269904 in nvidia-graphics-drivers-180 "Screen refresh problems with nvidia on intrepid" [Undecided,Confirmed] https://launchpad.net/bugs/269904
<directhex> is it still not possible to connected to encrypted wifi when auto-logging-in? i don't remember the specifics
<infinity> directhex: There was a pretty long discussion on ubuntu-devel (search for "keyring" on https://lists.ubuntu.com/archives/ubuntu-devel/2009-March/thread.html) about auto login and keyring passwords, but AFAIR, nothing was actually changed in that regard for jaunty.
<infinity> directhex: So, since there's nothing unlocking your keyring, and it's encrypted-by-default, you can't both auto-login and auto-connect to secure wireless.
<jpds> Unless you don't have a password on the keyring.
 * hyperair doesn't
<Company> but it does work if i select "available to all users" when editing connections
<Company> does it not use the keyring then or am i misremembering?
<ion_> nautilus: - Update fallback icon to not look like gnome 1.x
<ion_> *Finally*
<superm1> slangasek, great! I think the next step will be to find out if it really is doing anything "useful" for desktop installs, or if the X driver is doing similar behaviors on it's own when it initializes xrandr.  I'm not sure i've got any older laptops with svideo still, so i'll have to look around
<beginner9> hello
<beginner9> can someone help me with this?
<beginner9> no one?
<beginner9> hey
<beginner9> nenolod
<ebroder> If I'm merging package a into package b, then the new package b should provide, conflicts, and replace a, right?
<directhex> who killed pciehp?
<directhex> it used to be at least possible to get hotplug working on an aspire one's memory card readers, or at least on one of them. jaunty seems to have no pciehp.ko, and correspondingly zero hotpluggability
<johanbr> directhex: CONFIG_HOTPLUG_PCI_PCIE=y
<johanbr> it's built-in
<directhex> oh bugger, that means kernel parameters to alter behaviour doesn't it
<johanbr> yes
<directhex> wish i knew what made these card readers so difficult to have JustWork(tm)
<dtchen> kirkland: i'll file a wishlist about this, but it would be awesome if screen-profiles also prepended exit status to PS1
<dtchen> kirkland: "exit status" -> non-zero exit status
<jefferai> asac: hey there, Riddell said I should ping you
<jefferai> having a networking issue
<philsf> is this the right place to ask for the removal of a package?
<philsf> Bug #64594
<ubottu> Launchpad bug 64594 in hubackup "hurestore will always crash on startup (unfinished tool)" [Undecided,In progress] https://launchpad.net/bugs/64594
<philsf> bug has been  around since 2006, and upstream shows no activity towards a solution in a long time, please remove hubackup before jaunty
<cjwatson> philsf: https://wiki.ubuntu.com/UbuntuDevelopment/PackageArchive#Removing%20Packages
<cjwatson> philsf: in short: if you aren't an Ubuntu developer, get an Ubuntu developer to sponsor your request (and in this case, preferably get this Martin Bergner guy to agree, since he seems to be involved; "hostile removals" tend to create aggravation and confusion); if you are, subscribe the ubuntu-archive team to the bug
<jefferai> asac: basically the issue is, I had a default openvz install of 8.04 server which I upgraded to 8.10, no problems in either...but when I upgrade it to 9.04 (tried several times) the networking doesn't work.  The main issue seems to be that /var/run/network isn't being created, so ifstate can't be found/stored there, but if I add that directory it gets wiped out on the next reboot
<jefferai> (of the container)
<philsf> cjwatson: I see, thanks for the info
<philsf> cjwatson: it appears it was already removed, with consent from developers: Bug #320797
<ubottu> Launchpad bug 320797 in hubackup "Remove hubackup from repositories (no GUI restore!)" [Wishlist,Fix released] https://launchpad.net/bugs/320797
<philsf> should I close the original bug as invalid? I can't set as wontfix
<Cronos> is it here to ask for help on ubuntu 9.04 ?
<Mithrandir> no
<Mithrandir> ask in #ubuntu+1
<Cronos> kk
<cjwatson> philsf: fix released is probably closest
<cjwatson> philsf: just include an explanation pointing to the other bug
#ubuntu-devel 2010-04-05
<crypt-0> i wish to mount a LUKS volume *before* the root volume is mounted how would i go about this?
<lifeless> crypt-0: is the volume for / ?
<lifeless> if so cryptsetup has built in support for that
<lifeless> its all part of the initramfs scripts
<crypt-0> lifeless, no trying to get two-factor auth working
<crypt-0> then add a wiki when im done
<lifeless> well, you can mount a LUKS partition before /
<crypt-0> how so?
<lifeless> but you can't mount other volumes before /, not sanely.
<lifeless> its built in, just make sure its listed appropriately in crypttab
<lifeless> s/mount a LUKS partition/unlock a LUKS partition/
<crypt-0> i was thinking of using a keyscript
<crypt-0> that cats the keyfile
<psusi> storing the password in a file defeats the purpose of the password in the first place
<crypt-0> i know, the keydevice shall be a LUKS encrypted device
<crypt-0> mounted before the root encrypted LVM
<crypt-0> so the password will be to decrypt the keydevice, once decrypted the keyfile can be read and boot can continue
<crypt-0> that is my goal
<crypt-0> i was looking at a howto  to do two factor with GPG, but GPG lacks PBKDF2
<lifeless> uhm
<crypt-0> and user passwords tend to be entropy weak
<lifeless> LUKS has keyfile support; put the keyfile on a USB device
<lifeless> thats something you have
<lifeless> I have to go, can chat later
<crypt-0> right but i want the keyfile to be encrypted
<psusi> and hwo are you going to mount that device?  with a weak password?
<crypt-0> *i* am not, but others may yes
<psusi> the keyfile IS encrypted, with the password
<crypt-0> huh?
<psusi> pretty sure that the keyfile contains the real encyption key, which is itself encrypted using the password... possibly multiple times if you have multiple passwords
<crypt-0> if i make a key using /dev/random that is plaintext just because i tell LUKS to use it doesn not mean it is encrypted.
<psusi> I'm pretty sure that normally luks stores the key in a header it places on the disk... the key is randomly generated when you set up luks.... that key is then encrypted using your password and stored there too
<psusi> when you put in your password, it is used to decrypt the real key
<psusi> that's why you can change the password without wiping out everything on the disk... because the encryption key is not changed, it's just encrypted using the new password and stored on the disk
<crypt-0> if read the LUKS spec, and did mention that
<crypt-0> LUKS uses PBKDF2 , which changes your passhprase/keyfile > final decryption key
<crypt-0> if Mallory has the password/keyfile she can use it.
<psusi> right.... real key gets encrypted using your password(s) and stored on the disk... so even with access to the disk, you can't read the key without the password
<crypt-0> yes that is if you consider the disk  a factor.
<crimsun> 2/win 39
<psusi> huh?
<crypt-0> if your disk is stolen and your password is too, the attacker has your data.
<psusi> well of course
<psusi> so don't write your password down on a sticky note pasted to the bottom of the laptop ;)
<crypt-0> yes.... so if someone's laptop gets stolen with a weak password...it is gone
<crypt-0> yes.... so if someone's laptop gets stolen with a weak password...but they are using two factor authentication with a USB stick its fine
<psusi> encrypting it a second time does not help
<psusi> keeping the key on a usb stick helps, provided that it is not also stollen
<crypt-0> and if the attacker gets the laptop and the usb stick only the password is required
<psusi> yep
<crypt-0> that is what i want to set up.
<psusi> then store the keyfile on a usb stick, that's pretty straight forward
<crypt-0> ans wish to make a wiki so that others may use it
<psusi> that's what lifeless ways saying
<crypt-0> yes it is, but the keyfile requires no password
<psusi> you can make it require one
<crypt-0> you know the args?
<crypt-0> for cryptsetup
<crypt-0> the LUKS header is stored in plaintext
<psusi> not offhand, but you should be able to put the key on a usb stick, AND have a password on it
<crypt-0> yeah ive looked, but couldnt find a way
<psusi> can anyone take a look at bug #534743 and see about applying the fix or at least bumping up the priority?  this NEEDS to get fixed by release and I'm worried that if it doesn't get in for beta 2, it won't get in for release
<ubottu> Launchpad bug 534743 in dmraid "dmraid causes udev event feedback loop in Lucid" [Undecided,Confirmed] https://launchpad.net/bugs/534743
<crypt-0> lifeless, psusi the keyscript to be run http://pastebin.com/M2AhZDVR
<sistpoty> doko__: around? just saw that you've taken bug #534459... to my findings, that's gcc miscompiling, but I haven't managed to produce a test-case more minimal than the entire patch package yet :(
<ubottu> Launchpad bug 534459 in gcc-4.4 "2.6-2 FTBFS on sparc (bus error in test cases)" [High,Confirmed] https://launchpad.net/bugs/534459
<doko__> sistpoty: uploaded, build with -fno-stack-protector on sparc. I assume it's kees's task now ;p
<sistpoty> doko__: ah, thanks!
<sistpoty> doko__: I've got a patch lying around that justs adds an assert for an out of bounds check (local only, the one at the bug report is wrong), which somehow makes the build pass as well, interested?
<sistpoty> doko__: however I have retried to build fpc with a fixed patch package, didn't work (however that was a few gcc revisions ago already)
<sistpoty> (didn't work due to a bus error later, iirc)
<doko__> sistpoty: enotime, sorry. please ask kees. the fpc build on sparc is still running
<sistpoty> doko__: kk, kees?
<crypt-0> is there a way to enable SMART probing, an update disabled it?
<sistpoty> kees: attached the patch to the bug report in question (however in reverted form :()
<psusi> cjwatson, ping
<psusi> cjwatson, updated OEMRescue wiki page with thoughts for you to read when you're back
<un214> apt-get remove plymouth wants to remove e2fsprogs !
<ScottK> un214: Don't do that.
<un214> plymouth results in a brick
<ScottK> Removing it is just a longer path to tears.
<ScottK> File bugs and help get it fixed.
<un214> ?
<ScottK> plymouth isn't just a pretty splash screen.
<un214> I was better off when ubuntu didn't try to recognize my video card
<ScottK> It also does some important things with system I/O (I don't recall what)
<ScottK> So removing it is likely to have side effects eventually.
<ScottK> Considering you're using a development release and having problems with the most aggressive area of development in this development cycle, it's not stunning it's problematic for some.
<ScottK> Is it really a brick or just on a different vt?
<un214> last time I tried it, no display usable (bad driver)
<ScottK> How long ago was that?
<un214> about a month
<un214> usplash had the same problem
<ScottK> A lot has been done since then.
<un214> well we'll sure find out
<un214> well what do you know it actually came up this time
<un214> part of the problem is every so often I get a nouveau driver so bad I have to revert to using vgaconsole and VESA. I may end up having to do that anyway (potentially bad hardware).
<un214> ^bad nouveau driver
<lifeless> persia: hai
<persia> lifeless: Hey.
<lifeless> persia: hey
<lifeless> so
<lifeless> we're getting a test machine for lmirror in the dc
<lifeless> need some folk with the bandwidth & disk space to test mirroring from it
<persia> I'm happy to help with that.
<lifeless> \o/
<persia> I've about 250-280ms latency, but can saturate the TCP/ACK window, and have plenty of available mirror space.
<lifeless> cool
<lifeless> whats your actual pipe size?
<persia> Technically, 1Gbps, but my fiber is a bit dirty, so I only get ~600Mbps, but my router is old and sad, so I only get ~40Mbps, but the DC is >250ms away, so I really only get ~25.6Mbps
<lifeless> hah lol
<lifeless> lmirror should saturate your tcp session
<lifeless> can you open your tcp buffers more ?
<lifeless> tcp profiling is likely to be a significant aspect of tuning it
<persia> Probably not usefully, because of my old, sad router.
<lifeless> isn't that endpoint determined ?
<persia> I'm happy to tweak endpoint stuff, but I'll lead guidance.
<persia> s/lead/need/
<lifeless> sure
<lifeless> to start with, grab lmirror from bzr or a release tarball
<persia> Is it in the archives?
<lifeless> haha no
<persia> k
<lifeless> all the deps are, except testrepository which is only in debian atm
<lifeless> I did request a sync, but it hasn't been done.
<persia> OK.  Source downloaded.
<lifeless> apt-get install bzr python-paste python-testresources python-testtools python-testscenarios
<lifeless> python -m testtools.run l_mirror.tests.test_suite
<persia> Hrm.  Seems I need to fiddle, as some of this isn't in karmic :)
<lifeless> will then check that tests pass on your machine
<lifeless> oh heh :)
<persia> Failed to fetch http://ports.ubuntu.com/ubuntu-ports/pool/universe/p/python-openid/python-openid_2.2.4-1_all.deb  404  Not Found :(
<lifeless> wow, what dragged that in?
<persia> Dunno.
<persia> I had it on my local mirror of archive.u.c, but it's a bug that it's not on ports.
<persia> /usr/bin/python: No module named testtools.run
<persia> (yes, python-testtools is installed)
<lifeless>  what version ?
<persia> 0.1~r16-0ubuntu1
<lifeless> too old
<lifeless> 0.9.2 should be ok
<lifeless> [lucid]
<lifeless> or you can add the subunit release ppa, which has backports of a few of this sort of thing for karmic etc
<persia> lucid version installed fine
 * persia plans to upgrade this server soon anyway
<persia> What does http://paste.ubuntu.com/409365/ imply I need to upgrade?
<lifeless> something
<lifeless> add -v to the command
<lifeless> you'll get a backtrace in the log, that actually has the problem import
 * persia is looking at http://paste.ubuntu.com/409368/
<persia> That would indicate that apport is the culprit?
<lifeless> ugh
<lifeless> no
<lifeless> try
<lifeless> python -c 'import l_mirror.tests'
<persia> ImportError: No module named testresources
<lifeless> did you install python-testresources?
<persia> I did.
 * persia tries again
<lifeless> python -c 'import testresources'
<lifeless> dpkg -L python-testresources if that fails
<persia> Apparently I remembered incorrectly.  Installing python-testresources results in "ImportError: cannot import name memory_transport_stat"
<lifeless> thats included in the lmirror source
<lifeless> did you grab a tarball or bzr ?
<persia> tarball
<lifeless> may be a bong tarball :>
<lifeless> :<
 * lifeless hates on distutils some
 * persia mumbles about release management and testing and pulls bzr (slowly)
<maco> persia: intentionally?
<persia> maco: No, but bzr doesn't seem to kjnow how to get much meyond 20KB/s for me.
<lifeless> persia: you've done bzr lp-login ?
<persia> lifeless: Yes.  Anyway, with lp:lmirror, `python -c 'import l_mirror.tests'` succeeds cleanly.
<lifeless> ok
<lifeless> I'll fix
<persia> Running `python -m testtools.run l_mirror.tests.test_suite` now gets me "AttributeError: 'module' object has no attribute 'test_logging_resource'".  Do I need -v again, or does this mean something to you?
<lifeless> try -v
<persia> traceback is still when trying to import apport.  Shall I upgrade that?
<lifeless> no
<lifeless> its not apport
<lifeless> uhm
<lifeless> python -c 'import l_mirror.tests.logging_resource'
<persia> ImportError: cannot import name TestResourceManager
<lifeless> old testresources :<
<lifeless> uhm
<lifeless> edit that file
<lifeless> change TestResourceManager to TestResource
<persia> Um, why?  Is there a good reason not to just upgrade?
<lifeless> grep for TestResourceManager through tests/*.py
<lifeless> l_mirror/tests/*.py
<lifeless> persia: may not be packaged; I don't want to yak shave right now.
<lifeless> though lucid has 0.2.4 which is what I'm using
<lifeless> so it should be packaged just fine
<persia> python -c 'import l_mirror.tests.logging_resource' works great with python-testresources (0.2.4-1)
<lifeless> ok
<lifeless> pop()
<persia> AttributeError: 'module' object has no attribute 'test_server'
<persia> Err, let me just make sure I have the lucid versions of the list of stuff you asked me to install :)
<lifeless> python -c 'import l_mirror.server'
<persia> OK.  By installing the lucid versions of everything you asked in the beginning (except bzr), `python -m testtools.run l_mirror.tests.test_suite` runs, but I fail 35 tests.
<lifeless> heh
<lifeless> what tests fail ?
<lifeless> or rather
<lifeless> name a couple
<persia> python -c 'import l_mirror.server' runs cleanly
<persia>  l_mirror.tests.commands.test_mirror.TestCommandCommands.test_mirrors_new l_mirror.tests.commands.test_mirror.TestCommandCommands.test_mirrors_incremental l_mirror.tests.commands.test_mirror.TestCommandCommands.test_error_no_source
<persia> The failures all seem to be "AttributeError: 'MemoryServer' object has no attribute 'start_server'" fromself.transport_factory.start_server() atl_mirror/tests/__init__.py:48
<lifeless> newer bzr needed
<lifeless> but I don't really care if you run the tests or not
<lifeless> you should have enough to run it ;)
<persia> Good, because bzr gets compiled, and would need a real backport :)
<lifeless> err
<lifeless> the bzr ppa
<lifeless> already has it
<persia> 2.1.1-1~bazaar2~karmic ?
<lifeless> yes
<persia> Doesn't have it for my architecture.
<lifeless> oh
<lifeless> what arch?
<lifeless> sparc?
<persia> ppc
<lifeless> heh
<lifeless> well, you could grab source and respon
<lifeless> but frankly, just skip the tests.
<persia> So I don't need to backport bzr to do the test you wanted?  Cool.
<persia> What do I need to do?
<lifeless> symlink lmirror into /usr/local/bin
<persia> done
<lifeless> cd to a dir somewhere, such as pool/main/libm
<lifeless> run lmirror init test
<lifeless> and lmirror mirror test /tmp/test
<lifeless> if those commands work
<lifeless> lmirror serve test
<persia> Should pool/main/libm be a current mirror?
<lifeless> open a new window
<lifeless> persia: doesn't matter; it won't write to the mirror files; it will make a .lmirror directory we'll delete shortly
<lifeless> and do lmirror mirror http://127.0.0.1:8080/test /tmp/test2
<lifeless> if that works, then we can be pretty sure we're prepped to do some tests with jpds when his test archive server is up and running
<lifeless> persia: how did that go ?
<lifeless> you can check ~/.cache/lmirror/log to see what went on/is happening
<lifeless> or add -v (or -vv etc) to the command line
<persia> Just waiting for the result of lmirror mirror http://127.0.0.1:8080/test /tmp/test2
<crypt-0> lifeless, if while in initrd you mount a volume before mounting / and unmount it before mounting / is that safe?
<persia> ArneGoetje: When you're around, I'd like to chat about search engines and language-pack-ja
<lifeless> crypt-0: probably
<persia> lifeless: How long should it take for this last command to return?
<lifeless> persia: it should have taken no longer than the local disk mirror
<lifeless> can you du -sh /tmp/test ?
<persia> 24K
<lifeless> not test2
<lifeless> /tmp/test
<lifeless> the one that worked
<persia> Both are the same.
<lifeless> interesting
<lifeless> does /tmp/test contain the libm content ?
<persia> It contains nothing at all.
<persia> But the directory in which I ran the tests also contained nothing.
<lifeless> oh
<lifeless> heh
<lifeless> well that would make it fast :P
<lifeless> so, it seems to be hung yeah ?
<persia> Indeed.
<lifeless> can you strace the client ?
<persia> I don't know how to do that interactively.  I can kill it, and run again under strace.  Would that output interest you?
<lifeless> use ps to find the process
<lifeless> then strace -p PID
<persia> spinning on "recv(4, "", 23, 0)                      = 0"
<lifeless> ok
<lifeless> its expecting more content, but not seeing it
<lifeless> which is interesting
<lifeless> I can probably reproduce this
<lifeless> could you add a file to your source dir
<lifeless> if its not a live mirror
<lifeless> and run lmirror start-change
<lifeless> and run lmirror start-change test
<lifeless> and then run lmirror finish-change test
<lifeless> and then repeat the lmirror mirror http://127.0.0.1:8080/test /tmp/test2
<lifeless> I want to be sure its an empty-mirror bug, not a platform networking bug
<lifeless> persia: same symptoms ?
<persia> Yep.
<lifeless> has it written the new file to disk ?
<persia> I do get a .lmirrortemp file though, so it's trying to do soemthing.
<lifeless> ok
<persia> The .lmirrortempfile is 0-byte
<lifeless> is the new file you made 0-byte ?
<persia> the source is 15 byte
<lifeless> and strace shows it spinnnig on recv ?
<persia> Yes.
<persia> "recv(4, "", 15, 0)                      = 0"
<lifeless> any error on the server terminal ?
<lifeless> or in ~/.cache/lmirror/log ?
<persia> None
<persia> ~/.cache/lmirror/log has "2010-04-05 06:45:07Z: Writing file 'mirror.this'"
<persia> (which is the name of the test file)
<lifeless> ok
<lifeless> I have to do some stuff here
<lifeless> if you're up for it, might try to debug this more later
<lifeless> e.g. get a tcpdump trace of the request
<lifeless> btw do you have a http proxy configured ?
<persia> I'm happy to run stuff as you need.  I don't use a proxy for that server
<lifeless> for now, you can delete the test file, the .lmirror dir in your test area, and /tmp/test and /tmp/test2
<persia> (it has mirrors of Ubuntu and Debian, and any sane proxy would be useless most of the time)
<lifeless> persia: does it have http_proxy or similar configured ?
<persia> Not intentionally.  Is there something I should check?
<persia> by "test file" do you mean some file named "test", or my "mirror.this" file used for testing?
<lifeless> mirror.this
<persia> OK.  All deleted.  I likely still have the "test" mirror configured in lmirror, but that can just sit there until it works.
<lifeless> nope, you've deleted the config if you deleted the things I said you could ;)
<ArneGoetje> persia: I'm only only for a short time now... public holiday here today... what's up?
<persia> ArneGoetje: based on bug #526411 , we have the impression that we need to set the search providers for firefox in the langpacks, and if you have a pointer to a HOWTO or similar, we'd like to use that.
<ubottu> Launchpad bug 526411 in ubufox "In a fresh installation, firefox search engines are ordered alphabetically" [High,Fix released] https://launchpad.net/bugs/526411
<persia> ArneGoetje: Any guideance would be input to discussion with yahoo.jp and mozilla.jp, as the en-US default is currently mostly useless.
<ArneGoetje> persia: hum... I'm not sure about the sort ordering... but the localized searh engines are handled in langpack-o-matic, i.e. they are static there.
<persia> ArneGoetje: So what would be the best way to send a suggested order for the ubuntu-ja team?  Just a bug, and subscribe you, or something more complicated?
<ArneGoetje> persia: need to talk with asac first. I'm not sure what's the procedure for the localized entries.
<persia> I hear he won't be around until Wednesday or so.  Does it have to be him, or will any member of the mozillateam work?
<ArneGoetje> persia: can ask other members of the mozillateam... though I don't know if they know the answer...
<persia> ArneGoetje: Just to make sure I understand: you need information on how it is supposed to work, and then we'd file a bug subscribing you to make it work that way?
<ArneGoetje> persia: yup
<persia> ArneGoetje: Thanks!  I'll go hunt up an answer.
<ArneGoetje> persia: thanks a lot! Please file the bug against the langpack-o-matic project.
<persia> Will do.
<intick> hi all (english is the official language here right ) ?
<mdke> intick:
<mdke> intick: yes
<mdke> is it acceptable practice during the freeze to upload packages which are not essential for the beta on the basis that they will be processed after the freeze ends?
<intick> ok, first sorry for my poor english, i would like to know where can i share my bug experience with developpers of nautilus ? i have some comments to do
<nailora> could someone un-private this bug (of course only if applicable) https://bugs.launchpad.net/bugs/549655
<ubottu> Error: Could not parse data returned by Ubuntu: list index out of range (https://launchpad.net/bugs/549655)
<nailora> ^^ is that ubottus way of saying this report is private?
<mdke> intick: this is probably the place to start: http://live.gnome.org/Nautilus
<intick> thx mate that's what i'm looking for
<intick> cu
<nigelb> mdke, we are encouraged not to upload nonessential stuff during beta freeze
<persia> Um, it's more complicated that that, actually.
<persia> If a package appears in no images, it's fairly safe to upload.
<nigelb> i.e. universe?
<persia> Well, no.
<persia> Because many images draw from universe.
<nigelb> oh like... stuff in universe for ubuntu might in images for kubuntu and the likes?
<persia> If a package has an update and it is known in advance that there will be no need to change the package during the freeze, it's safe to upload (but will be held pending freeze lift)
<mdke> well, my package does appear in an image, but if it isn't approved, then the upload shouldn't compromise an image, afaics
<persia> nigelb: No.  The "universe flavours" vary by release.  For lucid, they are xubuntu and ubuntustudio.
<mdke> it's just a question of whether it will annoy the release managers
<mdke> (to have it pending)
<persia> mdke: My personal suspicion is that we'll go into pre-release freeze once beta2 releases, so I would expect every upload from this point to require manual approval.
<nigelb> it does, it does
<nigelb> every upload needs release ack
<mdke> persia: are you sure? That's not what the release schedule says
<persia> The risk with having it pending is that if it happens to end up having a milestone-critical bug, it's awkward to do an update that isn't the non-milestone targeted update.
<persia> mdke: I'm not sure at all.  I'm just guessing.
<mdke> hmm.
<mdke> I'll wait until beta release and upload then I guess
<persia> That's safer for packages in images.
<nigelb> mdke, /me misread.  Only during last week needs ack from release for all uploads :)
<mdke> persia, nigelb: thanks for the input
<ScottK> persia: I don't think we're going to stay in pre-release freeze after the beta is out.
<ScottK> It's fine to upload stuff now and if there's time to review it and it appears low risk, it'll get in.
<persia> ScottK: Cool.  So pre-release will just be from RC-freeze?
<ScottK> persia: AFAIK, yes.
<persia> That makes sense.  I thought it might be more stringent because of the specialness of this cycle.
<mdke> ScottK: you think it's ok to upload a package now even if it appears on a cd? (I'm not bothered about whether it is approved before or after beta release, but it would be convenient to me to get the upload off my plate now)
<ScottK> mdke: Yes.
<mdke> ok, thanks
<carnil> Hi, we in Debian Perl Group have a FTBFS on libgk2-perl (1:1.221-5) building against libgtk2-dev 2.20.0-2. If possible, could someone of you please rebuild libgtk2-perl in lucid against the gtk2.0 version there and check if it fails too?
<geser> carnil: FTBFS in my lucid pbuilder. It fails at some tests. (AMD64; libgtk2-perl: 1:1.221-4ubuntu1; libgtk2.0-dev: 2.20.0-0ubuntu3)
<carnil> geser: is one of the failing test t/GtkAction.t? And thanks for testing!
<carnil> [14:25] < geser> carnil: FTBFS in my lucid pbuilder. It fails at some tests. (AMD64; libgtk2-perl: 1:1.221-4ubuntu1; libgtk2.0-dev: 2.20.0-0ubuntu3)
<carnil> ups, pasting to wrong channel Ã¶
<geser> carnil: yes, "t/GtkAction.t                    (Wstat: 768 Tests: 19 Failed: 3)", "Failed tests:  11-13", "Non-zero exit status: 3"
<carnil> geser: okay many thanks, at least it is consistent. If we manage to fix it before lucid release, hope it will get into it too.
 * hyperair wonders what ubuntu-iso in ubuntu-dev-toolsi s
<hyperair> yay for manpageless binaries
<hyperair> ah at least apt's description has it
<persia> hyperair: Just upload a manpage for it :)
<hyperair> persia: at this rate, i'm going to upload manpages for every single manpageless binary in ubuntu. why can't the authors of the binaries write them?
<persia> Sheer laziness.  I know that I tend to avoid making changes that require changes to manpages to avoid doing manpages.
<nigelb> hyperair, when they have you why should they :D
 * hyperair throws tomatoes at nigelb 
<nigelb> lol
<hyperair> persia: i've mentioned this before, but i'm beginning to get the feeling that new contributors make better packages than old seasoned ubuntu developers.
<hyperair> persia: simply because they obey every single lintian complaint
<sebner> hyperair: rotten ones, rotten ones!
<hyperair> sebner: haha not again
<sebner> hyperair: you are always forgetting! :P
<hyperair> sebner: i like fresh tomatoes. i don't want to touch rotten tomatoes =\
<nigelb> hyperair, I tend to agree (not about the tomatoes :D)
<sebner> hahaha
<hyperair> nigelb: heheh i was about to ask whether you preferred rotten tomatoes instead =p
<nigelb> hehe
<nigelb> hyperair, I always tag patches, etc. but find very few patches tagged in packages I fix bugs
<hyperair> nigelb: because the seasoned ol ones don't need to please anybody
<nigelb> hyperair, there will come a day when lintian will check for patch tags ::D
 * hyperair mumbles the code is open, you're free to patch it in...
<hyperair> nigelb: sound familiar? ;-)
<nigelb> hyperair, I thought about it, but its C and I'm zero there :D
<hyperair> nigelb: eh? lintian is C?
<nigelb> hyperair, I thought so
<nigelb> it isnt?
<hyperair> $ file /usr/bin/lintian
<hyperair> /usr/bin/lintian: a /usr/bin/perl -w script text executable
<hyperair> >_>
<sebner> hyperair: all the same crap :P
<hyperair> sebner: perl's a different level of crap
<nigelb> perl? how retro
<sebner> heh
<hyperair> but nothing is as crappy as assembly.
<hyperair> okay, maybe visual basic is.
<hyperair> and maybe pascal
<ScottK> Pascal was lovely for it's day.
<hyperair> i'd take on assembly over visual basic any day
<ScottK> Certainly nothing like assembly or VB.
<nigelb> vb is fun.  I learned VB first :D
<nigelb> hyperair, it teaches you how not to write a program :D
<hyperair> nigelb: well said.
<ScottK> lamont: I think it's safe to drop Postfix's (alternate) build-dep on libmysqlclient14-dev now.
<SandGorgon> anybody know whom to ask for help in this bug - https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/539086 - we are absolutely unable to even install Lucid
<ubottu> Ubuntu bug 539086 in ubiquity "Gigabyte GA-M61PME-S2 does not boot on Lucid" [Undecided,New]
<SandGorgon> the bug is assigned to ubiquity right now
<ccheney> anyone know why openoffice.org-writer2latex in lucid is still showing up as 0.5.0.2-4ubuntu1 ?
<ccheney> oh nm my cache is somehow weirdly stale
 * ccheney should stop using dpkg -p, heh
<lamont> so htf do I undo the ugliness that is my window title bar now?
<lamont> ScottK: it's still in dapper....
<lamont> universe, to be sure, but...
<ScottK> lamont: So you'd need to be trying to build postfix with Main disabled....
<lamont> jej
<lamont> heh
<lamont> so... glib2.0... totally going to go tweak sbuild-package to totally fail glib2.0 on sparc
<lamont> or do an upload just to supersede the build
<lamont> not sure which
 * lamont watches the glib2.0 build on artigas
 * ScottK hands lamont a fire extinguisher.
<lamont> ScottK: go read the build log.  I. WIN.
<ScottK> Can't.  It's not all the way dead yet.
<lamont> is now
<lamont> search for 'really'
<ScottK> Nice.
<ScottK> I see it
<geser> hmm, since when does the openoffice splash screen the oracle logo?
<ScottK> geser: Since Oracle bought Sun.
<ScottK> (it had the Sun logo before)
<geser> hmm, somehow I didn't notice the Sun logo much
<ScottK> lucas: Now that we've removed the unbuildable binaries re the supportable binaries spec, I was wondering if we could have another rebuild to I can look for packages now missing build-deps (we've hit a few at random and I want to take a systematic look)?
<lamont> ScottK: there's a test-rebuild of lucid that's working on starting, needs a little more love from us'ns once the UK is online in the morning
<ScottK> lamont: Main or all of it?
<lamont> main, I expect
<ScottK> The stuff I need it all Universe/Multiverse
<lamont> ah, ok.  in any case, it would be best to get the current logjam happy first
<ScottK> Plus if he does it, I can diff the results and not have to engage in fancy scripting.
<lamont> though as long as you don't mark it for publishing, all is OK
<slangasek> lamont: lucas's rebuilds happen outside LP
<lamont> slangasek: oh.  well then.
<lamont> outside LP == outside my concern
<ScottK> He can also do it overnight instead of over weeks.
<lamont> ah.  many many machines, eh?
<LaserJock> I thought he had something like 4k, but that was a long time ago so I could be wrong
<geser> IIRC it's done on the "Grid5000" in France -> https://www.grid5000.fr/mediawiki/index.php/Special:G5KHardware
<TrueTom> Does anyone know if 'acipd' is still used to handle events like closing/opening the lid of a notebook?
<zyga-nc10> I'm looking for someone involved with couchdb and python
<mdke> does anyone know where the Ubuntu icon from the top left of the menubar comes from?
<mdke> I'm struggling to find it for some reason
<fagan> mdke: its built into the theme
<mdke> fagan: but the icon must be found on the system somewhere right? I can't seem to find it
<fagan> mdke: id say best bet would be to look at the theme package itself and see if you can find it in there
<fta> when will the unapproved queue be processed? been waiting for almost a week now :(
<mdke> fagan: I'm browsing the various icons in the theme packages
<mdke> ah, I think I have it
<fagan> nice
<james_w> fta: unapproved of what? oldest entries are 4 days old
<james_w> is that almost a week?
<MariachiAC> Hello everyone. i'd like to update my ubuntu system to 10.04. however the last time I tryed the system rebooted and I was unable to boot the system. i got an error message saying unable to connect to plimith. i'm a blind user using the orca screen reader and speakup.
<fta> james_w, i submitted chromium almost 6d ago, lots of people are waiting for the ssl fix
<james_w> launchpad says the 1st
<arand> MariachiAC: #ubuntu+1 is the channel for 10.04 support, and likely more active.
<MariachiAC> arand: Thank you
<lifeless> persia: sorry for disappearing last night
<lifeless> I'd like to resume in a few hours
<kees> can an ubuntu-release person review bug 555967 ?  I'd like to get it uploaded earlier rather than later.  :)
<ubottu> Launchpad bug 555967 in debmirror "[FFe] merge debmirror with debian" [Undecided,New] https://launchpad.net/bugs/555967
<lee_> how many developers are there?
<lifeless> of ?
<lee_> idk, just ubuntu developers in general
<lee_> and the ironic thing, your nickname is liveless and yet you're the only one that responded to my question...
<lee_> lifeless*
<kklimonda|G1> lee_: few hundreds but i don't remember the exact number - there are around 600 ubuntu-members and not all of them are developers
<lee_> I see
<LaserJock> it's usually ~150-200 in the Ubuntu Developers Launchpad team
<LaserJock> but there are also quite a lot of contributing developers one might say
<kklimonda|G1> LaserJock: oh? only that much? /me is surprised
<ajmitch> kklimonda|G1: that number is still far higher than those who are regularly contributing
<LaserJock> 158 is the number of members right now
<LaserJock> yeah, I would put the regulars at <= 100 I'd think
<kklimonda|G1> ajmitch: i know, but i was under the impression that the number is in high 200s and not 100s :/
<LaserJock> it's been that way for years
<LaserJock> roughly
<LaserJock> between 100 and 150, it seems to have hit some sort of equilibrium
#ubuntu-devel 2010-04-06
<ajmitch> there will be others now who aren't included in that 158, but are in kubuntu-dev or similar
<LaserJock> ahh, true
<lee_> well, the reson for my asking, I'm planning on becomming a developer
<LaserJock> ajmitch: actually no, 158 includes those
<LaserJock> ajmitch: they are a member of ~ubuntu-dev I see
<wgrant> Active developers are going to be well under 100.
<lee_> true
<LaserJock> I was once going to take a stab on figuring that out
<lee_> I'm actually shocked that ubuntu is developed by so many different people and can still run like it does
<LaserJock> something like, all the developers who've uploaded more than 1 time in the last release
<LaserJock> last time I looked at that it weeded out probably 2/3
<lee_> hmm
<Daviey> LaserJock: What about people who only do security or SRU?
<lee_> I guess it'd be the same
<LaserJock> Daviey: what about them?
<Daviey> LaserJock: Would they be included in your "uploaded more than 1 time in the last release"
<lee_> <--from south, has not perfect english btw
<akgraner> kenvandine, ping
<LaserJock> oh, I don't know, probably
<LaserJock> last time I wrote a script it crawled through <release>-changes
<Daviey> ahh
<LaserJock> which would include post-release uploads
<ajmitch> do security uploads end up on -changes?
<lee_> I'm new to c++ language, and I've yet to find something that will help me make a gtk program from it
<LaserJock> ajmitch: not sure about that one
<wgrant> ajmitch: Yes, but not with a correctly signed changes file.
<LaserJock> right, that was the problem last time I did this, syncs, etc. were not counted right
<LaserJock> but that was a long time ago, I think the -changes format has changed since then
<ajmitch> lee_: if you're looking at making an application, I think #ubuntu-app-devel may have people who can help
<wgrant> It's also reasonably easily doable with launchpadlib.
<ajmitch> LaserJock: syncs have got attribution of who requested it in the mail
<LaserJock> ajmitch: not with C++ ;-)
<ajmitch> LaserJock: I don't know, I haven't been there :)
<LaserJock> ajmitch: WRT #ubuntu-app-devel
<kklimonda|G1> most of #ubuntu-app-devel folks are heavy python users ;)
<LaserJock> python lovers
<lee_> heh
<lee_> figures
<ajmitch> maybe some variety could be good then
<LaserJock> JavaScript?
<kklimonda|G1> please, don't
<lee_> true, I've already made a game using just a terminal app
<ajmitch> you may as well next suggest php-gtk
<LaserJock> well, JavaScript is the new python, right?
<LaserJock> gnome-shell is written in it
<LaserJock> as are a few of the Gnome games now
<wgrant> LaserJock: Only if you are GNOME.
<kklimonda|G1> this joke wasn't funny when gnome devs told it and it isn't funny now LaserJock ;)
<LaserJock> wgrant: as goes GNOME so goes ... um, GNOME?
<lee_> hmm, actually, from all the sources that I learned c++ from (still a beginner at it) python is a rising programming language and is already the most used
<kklimonda|G1> introducing JS as a part of core GNOME platform is the weirdest decision i've seen in some time :/
<lee_> and the whole, ubuntu developers using python thing, confirms it...
<lee_> eh, people are weird
<LaserJock> kklimonda|G1: well, they could have picked C# ...
<lee_> c++, and this is just my opinion, is better then c# language
<lee_> much like ubuntu, being derived from debian, is better then debian...
<kklimonda|G1> lee_: well, there are ubuntu developers and developers who writr apps for ubuntu - first are writing lots of glue code to make working on distribution faster and python is great for that.
<lee_> ok, I may be a beginner at c++, but I already figured that out
<lee_> well, I'd better go learn python...
<RAOF> It'll be a good investment of time.
<lee_> yup
<lee_> cya
<kees> ajmitch: they do end up on -changes (it was broken for a long while, but is fixed now)
<lee_> ok, I ran across a problem...
<lee_> how do you open python after you've installed the compressed file?
<kklimonda|G1> is there any way of getting results that are uploaded by people using checkbox? where are they stored?
<Guest6565> Hi. I would like to get involved in development. Can anyone give me any pointers on where to start??
<kklimonda|G1> !development
<ubottu> Interested in becoming an Ubuntu Developer? Get started here: https://wiki.ubuntu.com/UbuntuDevelopment
<kklimonda|G1> Guest6565: ^
<Guest6565> Thanks for the Link :-D
<kklimonda|G1> no problem
<lee_> I need some help with something
<ari-tczew> where can I find irc logs of channel #ubuntu-hardened ?
<zul> irclogs.ubuntu.com probably
<ari-tczew> zul: not found this channel :/
<GrueMaster> crimsun: ping - in response to your comment on bug 528524, no change means that pulse is not being bypassed, and sudo speaker-test is still running through pulseaudio with the user as the owner of the device open handle.
<ubottu> Launchpad bug 528524 in speex "Sound not working in all apps through pulse on arm" [High,Confirmed] https://launchpad.net/bugs/528524
<GrueMaster> GrueMaster: PULSE_NO_SIMD=1 does however make it work properly, where sudo speaker-test actually grabs the pcm device as root.
<persia> lifeless: I am available at your convenience for the next while.
<lifeless> persia: ok cool
<lifeless> persia: in an empty dir do
<lifeless> lmirror init test
<lifeless> lmirror serve test
<lifeless> start up a tshark or similar session logging traffic on localhost port 8080
<lifeless> we want full frame captures, not truncated
<lifeless> then run lmirror mirror http://127.0.0.1:8080/test /tmp/test3
 * persia starts reading tshark documentation
<lifeless> jpds: around?
<wgrant> He's not.
<persia> bad timeofday + easter
<lifeless> I know both of those things. Sometimes however, people surprise us :)
<wgrant> lifeless: Have you put any thought into how we are going to mirror the actual archive with lmirror?
<wgrant> With the split and all that.
<wgrant> It could be done by maintaining a separate journal for each, but it seems like things could be much more efficient than that.
 * persia would like to re-un-split later to save disk space
<persia> lifeless: So, tshark documentation follows current practice of not including any examples, and being written without the clarity and concision of the SYSV manpages.  Any pointers as to how to capture?
<crimsun> GrueMaster: I was afraid of that being the case. I guess it's time to debug the arm asm.
<lifeless> wgrant: yes, I have
<lifeless> persia: -i lo host 127.0.0.1 and port 8080 -X
<lifeless> persia: at a guess, offhand
<lifeless> wgrant: I suspect many journals, perhaps as many as one per dr-arch
<persia> I finally found an example almost the same time you posted, and `tshark -f "tcp port 8080" -i lo0` seems to do the right thing.
<lifeless> wgrant: into the same dir structure
<lifeless> persia: ok, grab a capture of it hanging
<lifeless> and show me
<lifeless> back shortly
<persia> lifeless: http://paste.ubuntu.com/409814/
<lifeless> persia: uhm
<lifeless> persia: that pastebin is garbage
<persia> lifeless: You have to "download as text".
 * persia puts the file somewhere else
<lifeless> persia: 'download as text' gives me garbage too
<lifeless> persia: did you use -s 0 ?
<persia> lifeless: http://people.ubuntu.com/~persia/tshark.out and no.
<persia> Does that seem less like garbage?
<lifeless> persia: 403
 * persia fights with sftp
<persia> Try again.
<lifeless> I have it, am looking
 * persia 404s it to save precious disk space
<persia> Err, 410!
<lifeless> hmm
<lifeless> the trace is noisy or something
<lifeless> persia: please redo it with -s 0
<persia> Well, it's the output of `sudo tshark -f "tcp port 8080" -i lo -w /tmp/tshark.out`
<persia> OK.
<persia> lifeless: http://people.ubuntu.com/~persia/tshark.out updated
<lifeless> wow
<lifeless> I think I need to tune the tcp interactions a bit
<lifeless> nevertheless
<lifeless> odd
<lifeless> its asking for /1/1
<lifeless> did you reuse the target mirror directory ?
<lifeless> persia: ^
<lifeless> persia: also, is it still hanging ?
<persia> I used a new target directory.  I stopped the hang with Ctrl-C
<lifeless> ok
<lifeless> uhm
<lifeless> please repeat, new target dir
<lifeless> don't ctrl-C the hung process
<lifeless> stop the tshark first
<persia> OK.
<lifeless> actually
<lifeless> nevermind
<lifeless> I think I should have enough here, I can see where you waited
<persia> lifeless: uploaded new tshark.out for new directory stopping before stopping lmirror.
<lifeless> its not seeing the content for the last file
<persia> The directory is empty.
<lifeless> wireshark shows it being transmitted
<persia> Odd.  On the server side, the sequence was `mkdir empty; cd empty; lmirror init test; lmirror serve test`
<lifeless> indeed
<lifeless> I'm tracking the bug down
<lifeless> ok, the content is being seen
<lifeless> client side I think
<lifeless> data is seen in the client socket
<lifeless> ah, found it
<lifeless> fixed
<persia> Should my symlink still work with a fresh bzr pull?
<lifeless> yes, though I haven't committed yet.
<persia> OK.  Just let me know when :)
<lifeless> ok
<lifeless> persia: it should work now
<persia> lifeless: Indeed.  empty mirror completed successfully.
<lifeless> persia: cool
<persia> Now that it runs, did you want me to actually test anything?
<lifeless> not especially. I mean if you wanted to init somewhere with a few 10's or 100's of GB's and mirror it around, that would be sweet.
<lifeless> but I wouldn't expect much insight from such local ops
<persia> I'd expect the behaviour to match what you can do locally.
<persia> So I suppose we need jpds, so I can pull against something sensibly large.
<lifeless> I don't have the disk space to do tests on that scale locally ;)
<lifeless> but i've tested with ~ 4GB datasets
<lifeless> found an issue in squid 3.0.8/32bit builds
<lifeless> but nothing in lmirror that was an issue
<crimsun> doko_: any recommendations for dealing with #554149? Supporting 8.04 LTS -> 10.04 LTS seems thorny.
<crypt-0> 0_o quite some activity in here
<crypt-0> may i ask why the cryptsetup package in Lucid is *still* a release candidate (rc2) when the stable release was released in Jan ?
<lifeless> I don't think anyone will know the answer
<crypt-0> IIRC a lot of bugs were fixed, and the version packaged is no longer mirrored. cryptsetup-1.1.0-rc2 is in the repos between 2 and 4 there were substantial bugfixes and then the final non-rc cryptsetup-1.1.0
<persia> crypt-0: 1.1.0-2 migrated to debian testing on Sunday, and lucid is pulling from testing.  Given the volume of ubuntu-specific patches, it may be that this will not be upgraded for release.
<lifeless> we're in deep freeze
<lifeless> so any change is going to be reviewed rather closely
<persia> Given that lots of folks took Monday off for Easter, I don't think we're even behind, even if we weren't in freeze.  Given the freeze, nothing is likely to happen prior to beta2, and may well only involve cherrypicks prior to release.
<crypt-0> i mentioned it late jan on a mailing list
<lifeless> thats not an effective way to get things done
<crypt-0> well will it *eventually* be upgraded like within the first month of the stable release?
<persia> Unlikely.
<lifeless> unless someone does the work to merge the debian and Ubuntu packages
<lifeless> and QA the result
<persia> It's more likely that some bits of it will be cherrypicked to address bugs.
<lifeless> and ask for a FFe for it, no.
<lifeless> *you* can do some / all of that work, if you like.
<crypt-0> well where can i start?
<ScottK> Look at what's in 1.1.0-2 and what we have in Ubuntu and see if there are Ubuntu changes that need to be preserved.
<crypt-0> ok
<lifeless> ScottK: hey
<ScottK> Hello lifeless.
<lifeless> ScottK: can you have a look at https://bugs.edge.launchpad.net/ubuntu/+bug/538946
<ubottu> Ubuntu bug 538946 in ubuntu "FFe: Sync testrepository 0.0.3-1 (universe) from Debian unstable (main)" [Wishlist,New]
 * ScottK looks
<crypt-0> ScottK, nothing besides the shell scripts
<ScottK> Right, so the question is, are the changes needed.
<ScottK> Likely they are.
<crypt-0> ill work on getting out 23/64 bit packages built soon after that where should i submit them for review?
<crypt-0> ScottK, yes they are but the changes wont effect going from 1.1.0-rc2 to 1.1.0
<crypt-0> ScottK, so the scripts already in place will work like they do with rc-2
<crypt-0> will just need to be extracted and added to my package
<ScottK> crypt-0: Ideally you'd make a debdiff and attach it to a bug asking for the upgrade.
<ScottK> lifeless: minus points for edge urls, but approved anyway.
<lifeless> ScottK: thanks
<lifeless> ScottK: are you also an archive admin, to do the sync, or do I need to hunt someone else down ?
<ScottK> I'm an archive admin, but you need the "employed by Canonical and has shell access" kind for a sync.
<persia> lifeless: Alternately, you need about 6 weeks of code reviews to fix the bug in launchpad that makes that true, but you may not want to wait that long...
<lifeless> ScottK: ok
<lifeless> StevenK: ping; I wants a sync done :)
<lifeless> crypt-0: so, have you done a merge of the packages yet ?
<lifeless> crypt-0: if not, the wiki has good docs on merges - you need to do a merge.
<crypt-0> ok
<crypt-0> i will get to it
<lifeless> if you need pointers just shout
<lucas> ScottK: yes, I'm planning to do a rebuild before the week-end, possibly earlier
<ScottK> lucas: Excellent.
<ScottK> lucas: I don't think I managed to reply to your mail for feedback, but I've found your rebuilds very useful.
<ScottK> lucas: Most particularly one case where I fixed a FTBFS that was caused by a problem in a library the package used and I was ably to use the symptom information you provide to find all the other affected packages.
<pitti> Good morning
 * mneptok hugs pitti
<pitti> kirkland: I'm around now
 * pitti hugs back mneptok; how are you? found some Easter eggs?
<mneptok> pitti: i tried looking for them, but the wife said a scalpel near her abdomen made her nervous, and said to stop. :(
<pitti> that sounds a bit early in the processing chain indeed!
<mneptok> oh SURE! take HER side!
 * mneptok pouts
<lifeless> mneptok: you forgot the ether
<mneptok> lifeless: we're in a recession. times are tough. i had to stop the ether and switch to "mallet."
<mneptok> brb ... police coming through the windows.
<dholbach> good morning
<persia> jpds: lifeless indicated you had some interesting data sets available to test lmirror.  Please let me know what I might pull that would provide useful information.
<lifeless> persia: we're not quite ready for that; pending some machine setup
<persia> Oh well.  rsync is is then.
<zyga-nc10> hello, anyone affiliated with couchdb around?
<zyga> mvo: hello
<zyga> mvo: anything I can help you with today?
<sladen> oh I fucking hate quilt
<maco> sladen: pssst language
<mvo> zyga: hello! bug #549011 (probably pretty trivial, but it would be nice to refactor a little bit around it if needed)
<ubottu> Launchpad bug 549011 in software-center ""Canonical does not provide updates for ."" [High,Confirmed] https://launchpad.net/bugs/549011
<maco> sladen: also, hello :)
<mvo> sladen: try edit-patch instead
<mvo> hey sladen and maco
<maco> hi mvo
<dholbach> sladen: ubuntu-dev-tools package
<mvo> zyga: bug #437709 is fixed I think, but confirmation would be cool
<ubottu> Launchpad bug 437709 in aptdaemon "race in lock checking code" [Medium,Fix released] https://launchpad.net/bugs/437709
<mvo> zyga: and bug #540790 not sure what the best way forward is here, probably to offer a "reload" or "ignore"
<ubottu> Launchpad bug 540790 in software-center "handling of untrusted sources is suboptimal" [Medium,Confirmed] https://launchpad.net/bugs/540790
<zyga> mvo: could you please assign those bugs to me, it'd be easier to track if that's okay with yu
<mvo> zyga: sure, thanks!
<zyga> mvo: are you aware of the bug that software-center is not usable via keyboard (it's doing synchronous ops on keyboard up-down nav)
<zyga> mvo: thanks, I'm checking my bugs now
<mvo> zyga: what bit in particular does not work with keyboard?
<zyga> mvo: try it, the app quickly hangs (turns gray on compiz)
<zyga> mvo: it's probably doing something synchronously and it takes ages
<zyga> mvo: just try moving down the list with keyboard
<mvo> zyga: ok, so in the software-list?
<mvo> zyga: the long listview?
<zyga> mmm, yes I think so (if I understand you correctly)
<zyga> I can reproduce this each time
<zyga> from the initial screen, just scroll down with the arrow key
<mvo> zyga: into any paricular category? or just scrolling around in the welcome screen?
<zyga> mvo: this is reproducible in each screen, the welcome screen will do
<zyga> mvo: I didn't dig through the code yet, I could be wrong on the cause
<zyga> mvo: maybe it's the resize of each list item that occurs
<mvo> zyga: hm, I can reproduce it when going into "System", not not otherwise
<zyga> mvo: my system is slower probably
<zyga> mvo: I could record a video and show it to you if you'd like
<mvo> zyga: that would be nice
<zyga> mvo: in progress, just a moment
<zyga> mvo: if you are aware of this problem and know LP # then I'll attach the video there
<tkamppeter> pitti, hi
<zyga> mvo: I have the video, any place to upload this?
<mvo> zyga: I don't have a open bug for this yet, please just open one :)
<zyga> ok, moment please
<pitti> hi tkamppeter, how are you?
<zyga> mvo: #556290
<zyga> mvo: istanbul sucks, the video stopped after 20 seconds or so
<zyga> mvo:  got it
<zyga> mvo: uploading
<zyga> mvo: video attached, http://launchpadlibrarian.net/43226843/software-center-unresponsive-with-keyboard-navigation.ogg
<mvo> zyga: thanks, its a wee bit small, but I can see the problem I think
<zyga> mvo: in the future I think I will be able to capture video off-system
<zyga> mvo: but for the moment in-system solution will have to do
<zyga> mvo: basically I think the list should be smooth no matter how you navigate - can we make the buttons and other stuff overlay the list item without reflowing/resizing all other items?
<mvo> zyga: its not trivial, the gtktreeview does not work well with non-fixed heights like this
<mvo> zyga: we had a apply some trickery to make it somewhat fast (a special property)
<mvo> zyga: see bug #514879
<ubottu> Launchpad bug 514879 in software-center "details update very very slow" [High,Fix released] https://launchpad.net/bugs/514879
<zyga> mvo: how about we make the view fixed height
<zyga> mvo: and then show a overlay window that has the details when you navigate or click
<zyga> (focus)
<mvo> zyga: interessting idea! if it overlays part of the row below you need to discuss that with mpt if that is ok with him, we have almost fixed-height performance, I wonder if the freeze bug comes from something else, some missing optimization in the way we use the treeview
<zyga> mvo: I'll try to poke around, you are right - the first thing is to understand what's slow
<tkamppeter> pitti, fine
<zyga> mvo: is it possible that there is something downloaded/read from file/ in a non-async way when you focus?
<zyga> mpt: what do you think about this?
<tkamppeter> pitti, there are still complaints going around that CUPS does not start on boot/stop on shutdown.
<pitti> tkamppeter: start on boot, too? that's totally independent from stopping on shutdown
<zyga> mvo: what's the proper branch for hacking lp:software-center?
<zyga> or some lucid-specific branch?
<tkamppeter> pitti, no I have found the bug where there appeared a comment on the weekend: bug 497299, but now I see that the complaint is about Karmic, not Lucid.
<ubottu> Launchpad bug 497299 in ifupdown "upstart not starting init-scripts (event net-device-up IFACE=lo missing)" [High,Fix committed] https://launchpad.net/bugs/497299
<pitti> right, that's not cups specific
<tkamppeter> pitti, and it is CUPS startup.
<mvo> zyga: lp:software-center is the right one
<mvo> zyga: if you run it with --debug you should get a lot of info
<mvo> zyga: its doing a lot of stuff async :/
<zyga> mvo: thanks
<mvo> zyga: biggest is probably apt cache reading
<zyga> mvo: python softwarecenter/view/appview.py
<tkamppeter> pitti, CUPS not shutting down I do not find in the moment, there was a bug report, but I do not know what got down about it.
<zyga> if you run that
<zyga> and move around
<pitti> tkamppeter: I have a list of them, I'll triage them soon
<pitti> tkamppeter: we can ignore those for now, I think
<zyga> you can see that item view is changed slightly even though nothing visible is changed
<mvo> zyga: good idea to test it in isolation - is that freezing for you as well?
<zyga> mvo: yes, search for 'x' and scroll away
<zyga> mvo: that's good actually :-)
<zyga> ExecutionTime, neat
<mvo> yeah, I use that all the time :)
<mvo> geser: do you plan other ubuntu-dev-tools upload after beta-2 ? I just applied a fix for the bug that sladen had with edit-patch
<tkamppeter> pitti, I have also committed a small (trivial) fix to the CUPS BZR repo, to eliminate a warning in error_log. Can you upload CUPS before release? Thanks.
<pitti> tkamppeter: yes, of course; I also committed an updated security fix, I'll do an upload right after beta-2
<pitti> it'll be well in time for final
<tkamppeter> pitti, and also what about taking in the 1.4.3 bug fix release of CUPS?
<pitti> tkamppeter: if you can test it, please feel free to commit
<persia> mvo: There is almost always a last-possible-moment upload of u-d-t for changing defaults lucid/maverick, but upload earlier if you ave good bugfixes.
<tkamppeter> pitti, I do not have much time for testing, the OpenPrinting Summit is next week.
<zyga> mvo: strange, if I scroll around I get http://pastebin.ubuntu.com/409920/
<mvo> persia: cool, thanks
<mvo> zyga: its probably a artifact of it running in isolation, I can have a look
<zyga> mvo: it doesn't happen all the time, just if you move around fast
<geser> mvo: yes, I plan to do at least one upload.
<zyga> timing?
<mvo> zyga: I guess
<mvo> geser: cool, thanks
<zyga> mvo: I added a logger to CellRendererAppView.draw and it keeps logging activity when I drag the window
<zyga> mvo: maybe we can save some time with double-buffering?
<mvo> zyga: good idea
<zyga> mvo: do you know how to enable this on a widget tree?
<mvo> zyga: there is a gtk.Widget.set_double_buffered() call
<mvo> zyga: but it should be default already
<mvo> zyga: but maybe its not for some reason
<zyga> mvo: I'll check this in a second, I found something strange with that Cache.ready and None on pango
<zyga> mvo: I was moving up and down like crazy and I managed to make a ghost entry without any data inside, I have video
<zyga> mvo: http://launchpadlibrarian.net/43229601/ghost-entry.ogg
<zubin71> hello, has anyone here worked on iptables? id like some feedback for an idea i had. you can view the idea here at https://wiki.ubuntu.com/GoogleSoC2010/ZubinMithra. Thankx in advance.
<zyga> mvo: setting double buffered view on AppView doesn't help
<zyga> mvo: either the view always draws cells for some strange reason (on purpose) or it's another bug that prevents this from working
<mvo> zyga: I would not be suprised if its a issue with gtktreeview, I saw a lot of drawing in my custom models. I don't know if its a bug in the treeview or in the custom models, but I suspect the former
<zyga> mvo: do we have gtk hackers to give us a hand in this?
<zyga> mvo: the UI is really slow because of this
<zyga> even on core i7 which is insane IMO
<mvo> zyga: bratsche is the first who comes into my mind, gimpnet and #gtk+ is probably a good place
<TrueTom> does anyone know if 'acpid' is still used for handling events like opening/closing a notebook lid?
<pitti> TrueTom: only if gnome-power-manager/the KDE pendant aren't running
<pitti> TrueTom: but not for lid closing, only for the power button
<zyga> mvo: I managed to remove the slowdown by dropping other columns
<zyga> mvo: interesting thing is that the Cache.ready issue is clearly reproducible so it's a separate problem
<TrueTom> pitti: so is gnome-power-manager responsible for disabling the backlight of the screen when I close the lid?
<pitti> TrueTom: no, it just tells the kernel to suspend, and the kernel does the rest
<pitti> TrueTom: oh, if you disabled suspend-on-lid-close, it's gnome-power-manager, yes
<zyga> mvo: can you please try to do one thing for me: run python softwarecenter/view/appview.py
<TrueTom> pitti: how does gnome-power-manager know the lid is closed? its homepage states that it doesn't use pmud/acpid/apmd anymore but HAL (which isn't used in Ubuntu anymore!?)
<zyga> mvo:  and attempt to write "nethack", quickly
<pitti> TrueTom: closing/opening the lid produces an input event now (SW_LID)
<zyga> mvo: do you get "ehakctn" too?
<pitti> TrueTom: so it just needs to listen to that X event
<TrueTom> pitti: ah, didn't know that, thanks... i will test if that works... also, acpi_listen shows that there is no event generated when I close my lid but two when i open it... this seems broken but that isn't a problem since nothing is still using acpi anymore?
<pitti> TrueTom: that sounds broken, indeed, hm; is the first event after lid opening the "close" event?
<pitti> TrueTom: does the machine suspend in between?
<mvo> zyga: yes
<mvo> zyga: but only in that mode
<mvo> zyga: no in s-c itself
<TrueTom> pitti: i don't know... i couldn't find out how to parse the output from acpi_listen, however the output is the same for both events (minus the event counter)
<TrueTom> pitti: the machine doesn't suspend (which works fine though)
<TrueTom> pitti: the problem is that closing the lid doesn't disable the backlight but opening the lid again does
<pitti> TrueTom: these effects sound related
<TrueTom> pitti: then the backlight stays off and i have to reboot
<TrueTom> pitti: yes, hence my question
<pitti> I suppose it gets the "lid close" event only after opening
<TrueTom> pitti: i agree... but eventually this is a problem with ACPI in the kernel?
<pitti> TrueTom: right
<TrueTom> pitti: ok, thanks... then i'm going to have to compile a kernel with acpi_debug=y... see you all in a few hours... ;)
<zyga> mvo: I have some improved monitoring
<zyga> mvo: it shows where execution time of nested ExecutionTime object exceeds given threshold, by default 1.0/24 seconds
<zyga> mvo: it's quite easy to spot the slow part now
<free> mvo: hey! just wanted to let you know that the hardy->lucid upgrade problem the other day was a transient one
<doko_> crimsun: just make it a depends. ubuntu always did ship the files in /usr/lib32, not in /emul
<free> mvo: I tried the day after and it worked
<free> mvo: now I have another problem though, dapper->hardy using the official Dapper AMI, https://pastebin.canonical.com/30087/ (seems a dependency issue as well)
<free> interesting mail from sg
<free> oops wrong channel :)
<sladen> seb128: https://bugs.launchpad.net/ubuntu/+bug/554652/+subscribe
<ubottu> Ubuntu bug 554652 in tracker "Panel menus/applets should present consistent behaviour" [Wishlist,Confirmed]
<sladen> seb128: bug trackers are for tracking, bugs...
<seb128> sladen, right, but opening lot of tasks on one bug does spam everybody
<seb128> the people subscribed to any of the component get emailed for change to any of the components they don't care about in those cases
<seb128> which still happens when the task you care about is closed
<seb128> ie you might fix the bug on your component and still get spammed for years
<seb128> you should open a bug for each component
<bluefoxicy> damnit why the hell does gtkpod and rhythmbox both crash on karmic
<bluefoxicy> a lot.
 * bluefoxicy considers an early upgrade to lucid but he hears it's excessively broken at the moment....
<persia> bluefoxicy: Shouldn't be excessively broken.  We're in freeze for beta2 : if you know of some specific source of excessive brokenness, please share.
<zyga> mvo: another issue, sorting application list can take long time
<zyga> mvo: just click on the "provided by ubuntu" view
<mvo> zyga: executiontime> cool, is that in a branch somewhere?
<mvo> free: aha, happy to hear that
<mvo> zyga: I'm not sure how much we can do at this point to improve sort performance, but we definitely need to keep the UI alive
<Riddell> shtylman, ev: waa, manual partitioner doesn't work on ubiquity kde_ui
<Riddell> shtylman, ev: partman_edit_dialog() doesn't get past if not self.ctrlr.allowed_change_step()
<zyga> mvo: not yet, I tried improving that with python-profiler, I can pass it to You if you want
<zyga> mvo: this app needs backend vs frontend rewrite and separation and _async_ stuff all over the place :-(
<free> mvo: yeah, any clue about the dapper problem?
<mvo> zyga: it certainly needs improvements, but some of this is really hard to fix, e.g. the treeview performance
<zyga> mvo: yeah I realize that
<zyga> mvo: I wonder if we could -kind-of- get away with several issues by introducing... pagination
<mvo> zyga: for the treeview? we have a branch for this if you want to play with it
<zyga> mvo: mmm, cool, why isn't it integrated?
<zyga> not finished?
<mvo> zyga:  lp:~mmcg069/software-center/fastappview-kinda-working	
<cjwatson> Riddell: whatever the bug is, that's not it.  gtk has the same code and it's necessary
<mvo> zyga: well, it will not behave exactly like the treeview and we still ran into performance issues
<mvo> zyga: I had hoped that the ubuntu-almost-fixed-height mode patch for gtk would make the problem go away
<cjwatson> I wish that the GTK and KDE partman components in ubiquity weren't so unnecessarily divergent
<mvo> zyga: but apparently not enough
<zyga> mvo: I fear that the problem is much more complicated and is actually a bag of issues that all add up
<mvo> zyga: ok
<zyga> mvo: is XAPIAN_VALUE_APPNAME guaranteed to be nonempty?
<zyga> as in the actual value there
<mvo> zyga: no
<zyga> oh, okay, that explains it
<mvo> zyga: if its there it should be non-empty
<mvo> zyga: so ideally the database/update.py would not write it, but I don't think its (currently) enforced
<ev> Riddell: looking into it now
<zyga> mvo: so that's the preferred solution? not writing entries without app name?
<mvo> zyga: let me check the code. is it causing the problem with the empty rows you showed me earlier?
<zyga> mvo: no, I'm currently fixing #549011
<zyga> mvo: one step at a time I guess
<mvo> :)
<mvo> sure
<mvo> zyga: aha, I think in this particular case the problem is that we use two databases, the app-install-data one and the apt-xapian-index one. only the former has this value set
<mvo> zyga: if the package comes from the later we simply need to use the pkgname
<zyga> mvo: hum, okay that's easy to fix I guess
<mvo> yes
<zyga> mvo: I think the architecture could be easier though ;-)
<mvo> and it should be :)
<zyga> anyway, let's do it one-at-a-time
<mvo> feel free to apply medium levels of re-factor
<zyga> mvo: I don't want to target lucid but +1 is very sensible
<zyga> mvo: remember I wanted to fix some stuff earlier but didn't get permission from my employer
<zyga>  mvo: bzr ci -m "...; Fixes LP #number", right?
<mvo> zyga: I do remember that, the branch looked very promising
<mvo> zyga: you can also just edit debian/changelog and then run "debcommit"
<zyga> wow, thanks
<zyga> never knew that one
<zyga> mvo: UNRELEASED or lucid (I did dch -i)
<zyga> mvo: http://pastebin.ubuntu.com/410015/
<mvo> zyga: thanks, please just add your entry under the current "UNRELEASED" one with [ Zygmunt Krynicki  ]
<zyga> ok
<zyga> cool, done
<mvo> free: sorry, what dapper problem was that
<free> mvo: I have a problem with dapper->hardy using the official Dapper AMI, https://pastebin.canonical.com/30087/ (seems a dependency issue as well)
<free>  
<free> mvo: I think it was fine up to some time a go (though it's the first time I use the Dapper AMI for that, I usually use kvm locally)
<pecisk> hi people, I can't get Lucid loaded from LVM, Grub2 complains about not having proper device to load from (aka /dev/mapper/System missing)
<pecisk> fresh install
<pecisk> is there any known issues about this?
<cjwatson> pecisk: should have been fixed a while back.  are you attempting to install beta-1, or a daily build, or what?
<pecisk> it was installed in 26th March
<cjwatson> date is not important; installed from what image?
<pecisk> from daily of that day
<cjwatson> that's odd since I believed I'd fixed those problems on 22 March
<cjwatson> in any case, you might try a daily build
<pecisk> server daily
<pecisk> cjwatson: sorry, Empathy crash
<pecisk> cjwatson: server daily from 26th or 25th, not quite sure
<bdrung> bryce_: do we need a FFe for the 6.13.0 version of ati driver?
<cjwatson> pecisk: hm.  do you have logs?
<directhex> this is the driver which works on 5000-series cards, yes?
<cjwatson> pecisk: and do you mean that it fails on trying to install that image *now*, or that it fails on trying to upgrade a system originally installed from that image?
<mvo> free: uh, I think I need to investigate that a bit more, but could you check if it has ubuntu-minimal and ubuntu-standard installed?
<free> mvo: both installed
 * mvo scratches head
<free> mvo: if you want I can grant you access to the machine
<free> mvo: it's still running
<mvo> free: that would be nice but I doubt I will manage to work on it today :/
<free> mvo: okay, it should be pretty easy to reproduce, please could you ping me some time this week when you have time to give it a look? I can fire an instance
<m4rtin> hi, I've subscribed ubuntu-sponsors-main to 2 bugfix patches for regressions in bash completion. Do I have to do anything else to get them reviewed?
<chrisccoulson> superm1 - just looking at bug 525621, do you not have xulrunner-1.9.2 on your upgraded system?
<ubottu> Launchpad bug 525621 in xulrunner-1.9.2 "package xulrunner-1.9 1.9.0.18+build1+nobinonly-0ubuntu0.8.04.1 failed to install/upgrade: subprocess installed pre-removal script returned error exit status 2" [High,In progress] https://launchpad.net/bugs/525621
<bdrung> m4rtin: subscribe ubuntu-sponsor (instead of ubuntu-main-sponsors) if you have a debdiff. if you only have a patch, subscribe ubuntu-reviewers.
<persia> If you have both, and you're far too lazy to submit upstream, subscribe both, but be prepared to wait :)
<cr3> is it new that multi-card readers are appearing as a device, /dev/sdb for example, even when there's no card? I thought they only appeared as a device when a card was inserted
<persia> cr3: It depends on the implementation of the reader.  It's not new, although the balance mayhave shifted.
<persia> (hardware implementation)
<cr3> persia: I find it strange that the reader is reported as a block device when I'm not sure it really is when there's no card
<pitti> mdz, cjwatson: is TB in 20 minutes or 80? is it UTC or Northern-hemisphere based?
<persia> cr3: Unless something significant changed since I was troubleshooting issues with a card reader that required *reboot* to switch cards a while back, the issue is how the hardware handles stuff.  By indicating there *is* a device there, even when it's not attached, it can handle switching for broken hardware better.
<SandGorgon> does anybody know how to debug ubiquity - do I have to pass "debug=" flag to the boot parameters of the livecd and then run "ubiquity -d".. I am not clear on this part
<cr3> persia: I can appreciate that since there is indeed a card reader, then it makes sense to have it represented as a device
<mdz> pitti: I have it on my calendar in 15m
<cr3> persia: does that mean that it's possible for the drive in a system to sometimes be reported as sda and the card reader as sdb, and vice versa?
<persia> SandGorgon: https://wiki.ubuntu.com/DebuggingUbiquity
<persia> cr3: Sure.  That's why we like UUIDs
<cr3> persia: hm, that might be a pickle for the installation process where the alternate images seem to detect the card reader as sda
<SandGorgon> persia, I read that... I even read https://wiki.ubuntu.com/Installer/FAQ#How do I debug the installer?   I'm confused on what boot parameters to give.. or where should I  run "ubiquity -d" from ? IS it the boot menu of the livecd ?
<persia> SandGorgon: I usually run it from a terminal window in the live session.
<m4rtin> persia: it's nothing to do with laziness -- as I explained in MOTU chan; it's a matter of getting it fixed for Lucid -- waiting for upstream to release would be a prohibitive timescale
<superm1> chrisccoulson, i dont recall.  that system had some other (worse) upgrade bugs that required a lot of manual interaction at the time of the upgrade
<persia> m4rtin: My apologies if my comment was interpreted incorrectly.  Most of the sponsors request that a patch has at least been submitted upstream (if it applies upstream) before sponsoring.  The Reviewers team will do this for you if you don't do it directly, but this can take a while, because of the backlog.
<persia> I didn't mean to imply *you* were lazy, but that if you happened to feel that way, you could take the route that took longer.
<m4rtin> persia: ok, sorry; didn't mean to jump at you either! Is it worth me putting a note on the report? (It's fixed upstream in version control, but they are not going to release in time and have not done so for a long while)
<persia> It is definitely worth noting that in the report.
<SandGorgon> persia, my problem is that the live session doesnt boot up for me.. it hangs and that's what I'm trying to debug. Is there a way to hit the terminal window right at the menu ("Install Ubuntu", "Try Ubuntu without trying", etc.)
<persia> SandGorgon: I think you have to pass special boot args for that, to stop before starting all the way, but it's beyond my immediate knowledge.  Sorry.
<SandGorgon> persia, thanks... I'll try to find it
<nigelbabu> m4rtin, if upstream fixes it in their git/svn, that is enough for us to ok to get into ubuntu
<persia> Well, no.  Getting it upstream and getting it into Ubuntu are entirely separate, but the path is certainly made smoother for getting it in Ubuntu when it's accepted upstream.
<m4rtin> persia and nigelbabu: the functionality is fixed in upstream repos, but they have majorly rewritten components, so it is not fixed in the same way. My fix is a single line change to the latest *stable* codebase (which is synced for Lucid) to give the same functionality; is that acceptable?
<persia> Usually.  Depends on the sponsor to a degree.
<nigelbabu> can't give a blanket yes/no.  its a grey area.
<m4rtin> the short answer is that a future sync from upstream will not cause a regression, but this fixes it for the LTS release
<cjwatson> SandGorgon: https://wiki.ubuntu.com/DebuggingCasper may help; hangs may well be before ubiquity even starts
<m4rtin> well, I guess we'll see
<SandGorgon> cjwatson, very possible - my bug is https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/539086 Let me try it
<ubottu> Ubuntu bug 539086 in ubiquity "Gigabyte GA-M61PME-S2 does not boot on Lucid" [Undecided,New]
<MacSlow> seb128, for fixing the non-composite case of LP: #546650... do you want the full tarball or rather a diff/patch against notify-osd-0.9.27-0ubuntu3 ?
<MacSlow> seb128, I sadly have no good news regarding the rb-cover-art issue... :/
<MacSlow> seb128, still wasn't able to get around that bug.
<seb128> MacSlow, I would prefer a tarball fixing the rhythmbox issue too
<seb128> MacSlow, did you figure what the issue is? I think you said something about image ids the other day
<MacSlow> seb128, it is an inconsistency between image_data hint and normal icon passing... but what's causing that inconsistency I couldn't pin-point yet
<seb128> MacSlow, ok, no need to bother rolling tarball or sending patches for now, I can backport the revision easily
<seb128> MacSlow, just focus on finding what cause the inconsistency between image_data and icons
<MacSlow> seb128, just grab from lp:notify-osd/lucid
<seb128> MacSlow, right, I did that some days ago, I've it locally but we are frozen for beta2 now
<MacSlow> seb128, I pushed the change/fix for LP: #546660 5 days ago... so you should be good
<seb128> MacSlow, yes, it's all good, thank you
<pitti> persia: what went wrong with SDL? I didn't follow that, I think
<persia> pitti: The version we have works with some software in our archive, and breaks others.  Going back to the older version has the same effect.  There are upstream bugs about the regression, but we happened to catch a bad combination of pulls from experiemental whist people were paying attention to RCbugs in testing.
<persia> With unstable, we tend to be more careful about syncs, which tends to avoid some of this.
<persia> Anyway, I agree that this probably needs wider debate and review, rather than being on-topic for the meeting (or even random IRC chatter).
<pitti> persia: hm, I don't understand -- if we pulled from experimental, this seems to be the opposite of what we generally wanted to achieve by pulling from testing?
<persia> Yes, but we often pull several packages from experimental, which has lower risk in some ways when pulling unstable, because there's no chance of weeks-to-months lag in getting packages into testing.
<persia> This is a particular abberrant case, but in general, I think we need to ensure there is clearer guidance to developers, etc.
<pitti> persia: hm, my memory seems to be different wrt. "more careful"; they generally are done by the archive admins without a lot of questioning
<persia> pitti: Well, the archive-admin view is a peculiar one, as it's mostly administrative.  I mean in terms of developers requesting the syncs.
<pitti> right
<persia> I don't expect the archive-admins to ask questions, but I think that the developers may have a different view of risk when pulling from unstable or testing (whether merge or sync: doesn't matter).
<persia> And since testing can hang indefinitely for some package, the risk of pulling from experimental is much higher than when the default source is unstable, given potential time delays, transition lags, etc.
<apw> Keybuk, am i expecting to see plymouth before fsck or always afterwards
<Keybuk> apw: how do you mean?
<apw> i always see fsck from util-linux-ng flash up, then plymouth appears over it
<apw> and in this case its said that, that its doing an fsck, and plymouth has not yet appeared
<apw> so i have no option to 'S' it
<apw> and it takes an hour ...
<mvo> Keybuk: re bug #543580 - can you think of any reason why friendly-recovery would be on the wrong vt and something eats up "ENTER" ? it smells a bit like plymouth has not exited/given up control yet.
<ubottu> Launchpad bug 543580 in friendly-recovery "Recovery mode in lucid fails to load recovery menu" [Medium,Confirmed] https://launchpad.net/bugs/543580
<psusi> wow... that's a long fsck... you using ext2 or something?  a modern ext4 fs should not take that long to fsck, even if it's very large
<apw> Keybuk, all that on an HDD basedmachine
<Keybuk> apw: that sounds like plymouth or initramfs-tools is out of date - you should never see the fsck messages
<apw> hrm
<apw> Keybuk, ok thanks, i'll update _again_ when its done
<apw> i must migrate to ext4
<Keybuk> mvo: could be bug #551263 - though I can't replicate that
<ubottu> Launchpad bug 551263 in plymouth "text renderer does not correctly restore console on 'plymouth quit'" [Medium,Confirmed] https://launchpad.net/bugs/551263
<mvo> Keybuk: I can replicate it here, maybe its nvidia releated? I got a nvidia in that machine
<mvo> Keybuk: thanks, I check the bug
<psusi> oh yea... I forgot about that... I need to file and run down a bug on mke2fs... the man page says it defaults to -E lazy_itable_init=1, but it doesn't... setting this option significantly speeds up mkfs on large disks... also fscking them afterwards
<psusi> WD's new 4kb sector drives lie about their sector size reporting 512 bytes when in fact, they are 4kb... would it be possible to override the kernel detected sector size and set it to 4kb?  it seems that the files in /sys that report the size are read only which is a problem, but even if they weren't, what package would be responsible for handling this quirk?  udev?
<cjwatson> psusi: how much does it matter given that parted now defaults to 1MiB alignment in such cases?
<cjwatson> psusi: there's similar code elsewhere (e.g. fdisk) which could be borrowed
<psusi> cjwatson: seems to default to cylinder alignment still to me
<cjwatson> psusi: well, not in the installer
<cjwatson> and with the parted command line, parted 2.2 should default to optimal alignment across the board
<cjwatson> psusi: is this a USB enclosure, or SATA?  my understanding is that it's only USB that acts that way
<cjwatson> and that's because usb-storage forces use of the SPC-2 protocol even if the disk advertises better
<psusi> it seems to read a few parameters from /sys to decide on alignment, but these parameters are all either 0 or 512 bytes, so when I use parted it seems to still use cylinder alignment since the kernel isn't telling it to use 4kb
<psusi> nope, sata
<psusi> right, but what is "optimal" alignment?  it seems to base that on the optimal parameter in sysfs, which is 0
<psusi> and the drive reports to hdparm -I that it uses 512 byte physical and logical sector size... it seems that if it correctly reported 4kb physical size then the sysfs parameters would indicate that to parted and it would align to 4kb but it doesn't...
<cjwatson> psusi: not that simple - see http://git.debian.org/?p=parted/parted.git;a=blob;f=libparted/device.c;h=64da97868ab4e1209906f268690a66f9b0a27c9f;hb=HEAD lines 518-552
<cjwatson> your description of what's happening doesn't match my understanding of how parted works; if you're using parted 2.2, I would consider it a bug
<cjwatson> it's reasonably well-known that many drives still report 512/512 even though that isn't true, so the 1MiB alignment in such cases is quite deliberate
 * psusi looks for the architecture specific get_optimum_alignement()
<psusi> hrm... yea, looks like the linux.c one returns NULL so the 1mb default should be used when optimal_io_size and and alignment_offset are 0
<psusi> I'll have to test again tonight but I'm pretty sure I got a normal start on sector 63... a 1mb start position isn't ideal either though... would be nice if we could make optimal_io_size be 4kb and then parted would align to 4kb by default
<cjwatson> psusi: there was extensive discussion on various upstream lists about it, this was the consensus
<cjwatson> psusi: I think there was some concern about portability of disks - and frankly, who cares about a wasted megabyte these days
<cjwatson> psusi: also, a 1mb start position is actually kind of nice for grub
<cjwatson> so I'm inclined to leave it as-isi
<cjwatson> *as-is
<psusi> cjwatson: well, it would be nice if it used the extra space... I've been wondering about packing more into the grub core image when you have more than 32kb of space for it
<psusi> cjwatson: I was looking over the grub code last night actually and it looked like grub-mkimage will error out if the image is larger than 64kb anyhow
<cjwatson> sure, but it might be possible to put it further up to avoid those Windows problems
<cjwatson> not that I've seen a definitive analysis of those yet
<psusi> you mean like truecrypt wanting to also use the embed area?
<psusi> probably best just to use GPT and create the explicit grub boot partition ;)
<cjwatson> psusi: in some fantasy world where we can do that everywhere
 * cjwatson not big on fantasy worlds :)
<psusi> hehe
<superm1> cjohnston, i copied the mythbuntu.lucid seed branch from ~mythbuntu to ~mythbuntu-dev.  I figured that -dev better reflects archive permissions and allows all core dev to change mythbuntu seeds.  what other parts of the archive need to be updated to reflect that too?
<superm1> cjwatson, ^
<cjwatson> it would be nice to get *advance* warning of that sort of thing :)
<cjwatson> let me see
<superm1> well it's just a copy, i didnt remove the old ones
<cjwatson> there's a branch in people.u.c/~ubuntu-archive/ which needs to be re-pointed
<cjwatson> superm1: could you do this copy for all the old seed branches as well so that we have consistency?
<superm1> cjwatson, sure
<cjwatson> cdimage needs a tweak
<cjwatson> that's all I can think of; I can take care of all of it
<superm1> cool thanks
<superm1> i'll push those branches in a few minutes
<cjwatson> the change is welcome, certainly
<cjwatson> cdimage done
<superm1> cjwatson, could you also merge https://code.edge.launchpad.net/~superm1/debian-cd/mythbuntu-improvements so we make sure that makes the beta2 candidates?
<cjwatson> superm1: dodne
<cjwatson> *done, even
<bryce_> bdrung, probably
<dholbach> jcastro, bdmurray: can you join #ubuntu-reviews
<dholbach> please? :)
<nigelb> bryce_, if you've got a few minutes to spare for #ubuntu-reviews, would be great :)
<hyperair> hmm ubuntu's sprouted new dev channels
<hyperair> it used to be just #ubuntu-motu and #ubuntu-devel
<cjwatson> any reason reviews need to be separate, FWIW?
 * hyperair shrugs
<persia> cjwatson: Not really, it's been around for a while, and we're focusing on digging through the backlog of ignored patches in LP, and getting them upstream, etc.
<nigelb> shrug.. it was that way when I came around
<cjwatson> oh, that's right, I remember that channel has existed for a while now that you mention it
<cjwatson> fair enough
<persia> In many ways it would be nice to go back to fewer channels, but I feat they would all be too noisy.
<hyperair> is there a list of dev channels?
<persia> hyperair: I'm certain no complete one exists, as there's no wiki page that gets updated as part of the process of creating new ones.
<hyperair> heh oh well =\
<weenus> I'm having a problem compiling a program that was designed for one of the earlier kernels. I found a fix  for it but I don't know how to implement the fix. Could anyone tell me where to go for help on this?
<mvo> Riddell: if someone from the kubuntu people could have a look at bug #556535 that would be nice
<ubottu> Launchpad bug 556535 in amarok "file overwrite bug in 9.10 -> 10.04" [High,New] https://launchpad.net/bugs/556535
<Riddell> mvo: can do
<mvo> thanks
<cjwatson> Riddell,shtylman: could one of you review lp:~amichai2/ubiquity/fixes for merging?  it looks fairly good to me, but I'm not really qualified to review the .ui changes
<cjwatson> fixes a bunch of beta-2-targeted bugs
<cjwatson> and it'd be good to suck him into the #ubuntu-installer cabal if he's sane :) I'll send him a message to that effect
<cjwatson> it'll need a copyright assignment :-/
<Riddell> cjwatson: yes he's generally a good guy, reviewing that branch is on my todo
<cjwatson> Riddell: I've sent mail (via LP) asking for copyright assignment
<jtimberman> I have a PPA with a build that finished 16 hours ago that is still not published, should I do a reupload w/ a new version?
<Pici> jtimberman: Launchpad is having an issue with PPA publishing at the moment.
<jtimberman> Pici: Alrighty.
<jtimberman> Pici: Is there a ticket open for that?
<Pici> jtimberman: I suppose the topic in #launchpad will be changed when its fixed.  I didn't see a bug # mentioned for it.
<jtimberman> ah!
<jtimberman> Thanks
<bdrung> crimsun: i am not sure if bug #555891 is only a bug in pulseaudio. alsamixer does not show volume slider for every channel for example.
<ubottu> Launchpad bug 555891 in pulseaudio "[NFORCE - NVidia CK8S] ALSA test tone not correctly played back" [Undecided,Confirmed] https://launchpad.net/bugs/555891
<crimsun> bdrung: you stated that stereo is fine, yes?
<crimsun> bdrung: right, it's possible there's also a linux component, but I don't have time to chase that currently. Feel free to add the task.
<bdrung> crimsun: yes, stereo is fine.
<bdrung> crimsun: if i remove pulseaudio and try to play a DVD with 5.1 directly through alsa, it should work, right? otherwise alsa is affected, right?
<crimsun> bdrung: well, PA has a known issue with 4.1/5.1, so there's at least a PA task.
<psusi> cjwatson: is there a reason that bug #88633 is still hanging around as confirmed/high?  it sounds like you have decided not to change things, so shouldn't be be marked wontfix?
<ubottu> Launchpad bug 88633 in partman-auto "/boot is on root partition by default" [High,Confirmed] https://launchpad.net/bugs/88633
<crimsun> bdrung: I don't know what you mean by work. Do you mean "doesn't crackle" and/or "maps correctly"?
<crimsun> bdrung: i.e., those are two totally separate bugs.
<bdrung> crimsun: doesn't crackle + maps correctly.
<bdrung> crimsun: i was unsure, if that are two different issue.
<crimsun> yes, those are two different issues affecting possibly two different source packages.
<cjwatson> psusi: it's one of those bugs that if I wontfix it somebody will reopen it or file it again, so it hardly seems worth bothering
<cjwatson> psusi: and if I downgrade it, somebody will rant at me about why it isn't high
<psusi> cjwatson: why would it be filed again?  don't wontix still show up in the default search?
<cjwatson> not last I checked, it's a closed status
<psusi> ack, that's broken
<cjwatson> ICBW
<cjwatson> but besides, most people don't necessarily know where installer bugs go
<cjwatson> honestly, half the time explicitly wontfixing things is more trouble than it's worth
<psusi> that's not good...  it should be used to get the bugs out of the "needs worked on" queue since they won't be worked on
<cjwatson> I have bigger problems with my "needs worked on" list :)
<cjwatson> sometimes optimising for fewest rants in my mailbox is the least energy-intensive way of working
<YokoZar> What package does someone mean when they say "the pthread library" ?
<YokoZar> I'm guessing not libpthread-stubs
<cjwatson> might just be the one in eglibc
<cjwatson> i.e. /lib/libpthread.so.0
<YokoZar> cjwatson: Yeah, that seems to be what they were after.  Thanks :)
<_UsUrPeR_> hey all. I am having some problems with sshfs and ACLs. When a user creates a file in their own directory, and moves it over to a common directory on the server, it maintains it's own group instead of being changed to the group belonging to the common directory. I am trying to figure out a way to change a file's group without having to resort to a cron job. Does anybody have any suggestions? Thus far I have tried sticky bits and ACL. Stick bits wor
<_UsUrPeR_> k if the file is created in the directory, and ACLs don't seem to work at all with sshfs. Can anybody suggest anything to me?
<nigelb> can someone please moderate my mail to -devel titled "Patch Day, May 5th 2010"
<cjwatson> nigelb: done
<nigelb> cjwatson, thank you :)
<cjwatson> kees: FYI I moved bzr and bzrtools back to the supported-development-common seed - I don't see why we shouldn't offer 5y support on these given that they're Canonical products, and I definitely think that they should be in the core package set rather than in something like ubuntu-server which is where they ended up
<cjwatson> (actually ['kubuntu', 'ubuntu-desktop', 'ubuntu-server', 'unr'])
<kees> cjwatson: because they haul in a giant mess of deps :(
<cjwatson> I think, honestly, that that's a problem we have to deal with
<cjwatson> it doesn't seem *that* bad anyway - bzr, bzrtools, python-paramiko, python-crypto, python-configobj
<kees> cjwatson: iirc, it hauls in all kinds of extensive GUI stuff, but I would need to recheck to be sure.
<kees> (due to recommends)
<cjwatson> that does not appear to be the case
<kees> okay
<cjwatson> bzr-gtk is a suggests
<cjwatson> as is the rsvg/graphviz stuff in bzrtools
 * kees goes to re-run the seed thingy
<cjwatson> kees: also, can somebody on the security team tell me what to do with http://paste.ubuntu.com/410185/ ?
<kees> jdstrand: can you advise on the clamav stuff for -updates ^^
<cjwatson> (or indeed Just Do It, since jdstrand's an archive admin)
<jdstrand> cjwatson: I got it
<cjwatson> thanks
<jdstrand> np, done
<Keybuk> smoser: btw, I forgot to ask - did your cloud-without-an-initramfs problem go away?
<smoser> well, yes it went away, but because we're bundling an initramfs
<smoser> did you make a change that may have fixed that properly?
<Keybuk> right, but if you switch that off, is it fixed?
<Keybuk> yes, I think so
<Keybuk> have been studying the effects of code that I got wrong pre-mountall 2.10
<smoser> i can test it.  would an image built early this UTC morning have all needed pieces
<smoser> http://uec-images.ubuntu.com/lucid/20100406/lucid-server-uec-amd64.manifest
<Keybuk> and I think you could well end up in a situation where things got wedged
<smoser> (that is manifest)
<Keybuk> yes
<Keybuk> absolutely
<smoser> i'll try it. thanks.
<Keybuk> (and in 2.10, you should not get wedged anymore)
<lool> slangasek: valgrind/armel: that's news to me; lamont kicked the previous armel build manually because Launchpad had trouble picking up the P-a-s change
<lool> lamont: ^ valgrind wasn't attempted on armel for no good reason; would you mind checking it out?
<lool> lamont, slangasek: ^ thanks to you two
<slangasek> lool: ltsp is in the same state, btw - http://people.canonical.com/~ubuntu-archive/testing/lucid_outdate.html
<slangasek> (and likewise-open just FTBFS due to needing manual porting to each platform, bah)
<ccheney> if an upload includes new source bits but not all of it is new (eg orig.tar.gz isn't but other tar.gz are) do you still use -sa ?
<geser> a multiple tar.gz v3 source package? good question. when in doubt check which files the .changes file mentions
<ccheney> geser: it looks like it even included the orig.tar.gz for some reason, without using -sa
 * ccheney will see how that works after the freeze is lifted, heh
<geser> dpkg-genchanges tries to guess if the .orig.tar.gz is to be included based on the version number (-sa/-sd are for overwrite this)
<slangasek> NCommander: what's the trick to get jocote to give me a chroot?
<NCommander> slangasek: dchroot -c lucid -q
<slangasek> NCommander: and have you gotten a backtrace yet for this OOo segfault?
<slangasek> ok
<ccheney> slangasek: if it wasn't already clear it failed between 1:3.2.0-4ubuntu1 and 1:3.2.0-4ubuntu2 which is only a 6kb diff
<slangasek> ccheney: yep
<NCommander> slangasek: not yet. I don't have a board setup locally, and working on jocote is like pulling teeth, plus I'm not 100% convinced this isn't crappy hardware.
<ccheney> NCommander: did the toolchain change between the dates when the build worked vs failed?
<ccheney> NCommander: it seems to consistently fail now even on different buildds, so if its faulty hardware it seems to be consistently faulty? :)
<ccheney> unless it was an issue of faulty hardware miscompiling that OOo then uses to build which caused it to consistently fail on various buildds
<ccheney> er ...miscompiling other code that..
<NCommander> ccheney: that's the other thought unfortnately. Its going to require some serious debugging to determine what the hell blew up
<NCommander> ccheney: I'm greatly annoyed since we fixed OOo just for it to break again
<NCommander> ccheney: BTW, I *really* like your use of 3.0 source packaging on OOo, I haven't seen a multi-tarball package before today
<doko_> cjwatson, ev: would I break something in the installer if I explicitely check for a mounted /proc and error out in a maintainer script? java/keytool are the two ...
<ccheney> NCommander: yea it helps me with uploads a lot :)
<ccheney> NCommander: the debian bit is only a 2MB tarball now
<NCommander> ccheney: nice
<geser> @archive admins: does it cause a licensing problem if old debs are still published but their source got superseded (so no matching source anymore) by a new version which FTBFS or is stuck in DEPWAIT?
<smoser> Keybuk, bug 531494 seems to be fixed
<ubottu> Launchpad bug 531494 in Ubuntu Lucid "cloud-init job sometimes not running in cloud images without ramdisk" [High,Confirmed] https://launchpad.net/bugs/531494
<slangasek> NCommander: gar, what's this?: Stepping through Thumb-2 IT blocks is not yet supported
<slangasek> NCommander: we don't have a gdb that works on Thumb-2?
<NCommander> slangasek: ugh, that's the debugger not having full support for Thumb2
<NCommander> slangasek: no, its more a newer feature in the compiler that we use to ease thumb2 porting
<lee_> hmm
<lee_> hello
<slangasek> NCommander: well, that's what gdb tells me when I try to step through the code that's segfaulting: )
<NCommander> dyfet: HELP!
<dyfet> what did you break? ;)
<NCommander> slangasek: thats odd, I *never* ran into that problem before, something must have really gone pearshaped
<NCommander> dyfet: 16:44:55 < slangasek> NCommander: gar, what's this?: Stepping through  Thumb-2 IT blocks is not yet supported
<dyfet> ohh....
<NCommander> dyfet: care to shed some light on the situation?
<lee_> who here knows python?
<NCommander> dyfet: I thought the debugger supportred thumb2
<dyfet> I thought so too...
<dyfet> So I am now as concerned as you :)
<NCommander> dyfet: something is telling me that this is related to the implicat-its we use in GCC
<lee_> try python
<bdrung> crimsun: i did some more test and can confirm that's bug  #88633 is only caused by pulseaudio.
<slangasek> lee_: many people; if you have a specific question, you should probably just ask it
<dyfet> what was being debugged?
<ubottu> Launchpad bug 88633 in partman-auto "/boot is on root partition by default" [High,Confirmed] https://launchpad.net/bugs/88633
<slangasek> lee: (but bear in mind the note in the topic)
<slangasek> dyfet: OOo
<lee_> eh, nvm
<dyfet> ohhh....I was afraid you would say that :)
<bdrung> crimsun: wrong bug, it is bug 555891
<ubottu> Launchpad bug 555891 in pulseaudio "[NFORCE - NVidia CK8S] ALSA test tone not correctly played back" [Undecided,Confirmed] https://launchpad.net/bugs/555891
<NCommander> slangasek: we could build it -marm and hope the issue persists (OOo really benefits from thumb2 complication :-/)
<NCommander> slangasek: actually, there's a GDB patch to add the necessary support
<slangasek> NCommander: well, I can at least get a partial backtrace here; I'll continue working it from that angle
<NCommander> slangasek: http://permalink.gmane.org/gmane.comp.gdb.patches/54862 - this may help, I'll see if I can get my imx51 board up since my dove is down until I get my PSU back from Lexington :-/
<dyfet> That sounds like a long rebuild
<dyfet> where did it fail?  Is it just in a library?
<slangasek> dyfet: it's in libuno_cppu.so.3
<dyfet> I just knew you would say uno....
<NCommander> dyfet: its about two hours in
<NCommander> dyfet: that's a separate module thats now broken -_-;;;;;
<NCommander> Thats the part that generates C++ exceptions if memory serves
<dyfet> yeah....
<dyfet> what we have broken in mono, too...
<cjwatson> doko_: I think that should be ok
<NCommander> slangasek: I think the toolchain broke us unfortunately based off that. Might be worth doing a rebuild with -marm as a quick and dirty fix, if it works, we can leave it for the rest of lucid and start caring for maverick
<dyfet> NCommander: Yes, lets try that first, to see if it works, then we can decide if we really want to do that for lucid and postpone solving it for maverick
<NCommander> dyfet: ooh good, you up for building OOo? :-)
<lee_> hmm
<dyfet> Well, it's not my desire, but we need to see if at least that works
<lee_> um, python's not working right on my computer
<slangasek> dyfet, NCommander: for the sake of confirmation, where can I find a glossary for thumb2 asm?
<lee_> can anyone help?
<NCommander> slangasek: I usually use this guide: http://www.keil.com/support/man/docs/armasm/armasm_cihedhif.htm
<NCommander> slangasek: if you need a more indepth explination of ARM Thumb2, there's the official reference guide but that's generally overkill
<dyfet> slangasek: http://infocenter.arm.com/help/index.jsp
<slangasek> I don't need anything indepth, I just need to confirm the semantics of 'strne' :)
 * hyperair likes that quote from bryceh in nigelb's email =p
<bryceh> heh
<hyperair> heheheh
<psusi> cjwatson, weird... I checked on the parted alignment thing again and if I specify the start as 0 or 0m, it warns that it is not aligned and creates it, if I specify 0% as the start, it aligns the start at 1mb.
#ubuntu-devel 2010-04-07
 * psusi wishes he could figure out what package upgrade keeps reinstalling his grub wrong... default install works, but some upgrade keeps reinstalling it without the lvm module.. doesn't look like kernel upgrades reinstall grub..
<wgrant> psusi: How do you work around that? My grub upgrades have been failing for a couple of weeks due to apparently missing LVM support.
<psusi> wgrant, boot from the livecd in text mode, install the lvm2 package, mount the filesystem, chroot into it and reinstall grub
<wgrant> psusi: Interesting. I've tried that, but it still complains that there's no mapping for my root LV.
<lifeless> wgrant: failing how ?
<lifeless> wgrant: do you mean failing to boot, or failing to install grub ?
<psusi> wgrant, did you put a mapping for it in /boot/grub/devices.map?
<wgrant> Failing to install GRUB. Sounds like a different failure mode.
<psusi> lifeless, I don't even get anything that indicates that grub is being reinstalled... just don't boot because it can't find the lv... get a rescue shell and thats it... ls shows no lvm lvs
<wgrant> psusi: No -- should I need to?
<wgrant> I should try a recent installer and see if it works.
<psusi> wgrant, I dunno, I do...
<lifeless> psusi: and is lvm in the initramfs ?
<lifeless> psusi: can you do lvm pvscan ?
<psusi> lifeless, yes... it's just grub that breaks
<wgrant> Karmic and Lucid ~alpha2 both hate something about my VG and fail to install GRUB2.
<psusi> lifeless, don't need to, once I get grub fixed the system boots fine
<lifeless> psusi: uhm, if lvm is in the initramfs, and it boots to the intiramfs busybox shell, its not grub thats the problem.
<psusi> lifeless, I meant I get a grub rescue prompt, not busybox shell
<psusi> so it appears that something rebuilds the grub core image without the lvm module then installs it... I reinstall grub and its fine... at first I was manually rebuilding the core image with the lvm module thinking it was a problem with grub-install not detecting lvm was in use, but it isn't... it correctly detects it and builds it in when I Just run grub-install '(hd0)'
<psusi> I reconfigured the grub package which appeared to reinstall it and that was fine too.... reinstalled last kernel package, also fine... but something I just upgraded in the last few days broke it
<cjwatson> psusi: FWIW you should not need /boot/grub/device.map at all right now
<psusi> cjwatson, well, I do since I'm actually booting from sdc ;)
<cjwatson> psusi: grub-install not including the lvm module would be because it fails to detect it as the appropriate abstraction module - I'd recommend putting 'set -x' at the top of /usr/sbin/grub-install, then capturing a log of the upgrade where it goes wrong
<cjwatson> psusi: you still shouldn't need it if everything is working as specified
<cjwatson> grub2 is meant to be entirely free of dependencies on device ordering now, and if that's not the case I want to fix it
<psusi> cjwatson, thing is, it isn't... grub-install works fine... correctly detects lvm and puts in the module... I can see this because it worked, and also I turned on verbose mode for grub-mkimage when it calls it and its output indicated it put the lvm module in
<psusi> cjwatson, how's it know which disk to install to then?
<cjwatson> psusi: but it might be going wrong when called in some other path, for some reason
<cjwatson> grub-pc/install_devices should be a /dev/disk/by-id/ path equivalent to /dev/sdc
<cjwatson> (in debconf)
<lifeless> cjwatson: is it not possible to just include all the modules ?
<cjwatson> lifeless: it's not a good idea because there are size constraints
<lifeless> first cylinder?
<cjwatson> yes
<lifeless> mmm
<psusi> cjwatson, you know, maybe that's the problem... I think my grub debconf before had an EMPTY list of devices to install to
<lifeless> has anyone considered having a grub partition
<cjwatson> yes, it's been done
<cjwatson> we set it up that way by default on GPT - but not everyone has the partition
<lifeless> ok
<psusi> cjwatson, I think I left it blank initially because I didn't want any auto reinstalling.... but maybe an empty list causes it to go wrong?
<cjwatson> and stressing the partition table algorithms with an extra partition by default on DOS partition tables is a pain for other reasons
<lifeless> what machiens ship with EFI at the moment, just macs ?
<slangasek> cjwatson: do you think ubuntu-archive-tools would be an ok place to add a new script for batch-adding EC2 AMIs to the ISO tracker?
<cjwatson> lifeless: GPT != EFI
<lifeless> cjwatson: I thought that EFI was needed to boot GPT though ?
<cjwatson> slangasek: sounds ok, there or cdimage
<cjwatson> lifeless: no
<slangasek> cjwatson: ok
<lifeless> cjwatson: ah
<psusi> it would be nice if it just built all modules in when installing on gpt with the grub partition
<cjwatson> that's a lie the EFI manufacturers tell you
<slangasek> heh :)
<lifeless> cjwatson: ok; so - what BIOSes boot GPT in consumer machines ?
<psusi> lifeless, all of them... the bios just blindly loads sector 0
<cjwatson> psusi: yes, it's possible that could break it; that's why I'm asking for a log of the *upgrade* where it breaks with set -x in grub-install, not just of a single grub-install run
<cjwatson> lifeless: the GPT spec includes a legacy MBR
<lifeless> gotcha
<cjwatson> sorry, "protective MBR"
<cjwatson> psusi: wouldn't go quite that far - some BIOSes check for a valid MBR partition table
<psusi> hrm... I'll see if I can empty the list back out with a reconfigure and see if that replicates the problem.... and I'll get the log
<cjwatson> which is why GPT specifies the PBMR
<cjwatson> *PMBR argh
<lifeless> :)
<psusi> cjwatson, well, true... but when they find it they load an execute, don't care if a gpt table follows ;)
<cjwatson> psusi: right, *if* they find it. :-)
<cjwatson> just saying, there does have to be something there that looks enough like an MBR to fool some BIOSes
<psusi> cjwatson, so edit grub-install and add a -x to the shbang line?
<psusi> or set -x on its own line?
<cjwatson> psusi: better to put 'set -x' somewhere just below
<psusi> k
<cjwatson> wgrant: I fixed at least one cause of that in grub2 1.98-1ubuntu2.  of course there may be others.
<cjwatson> wgrant: you do have to have /proc and /sys mounted when upgrading grub-pc, in case that isn't stating the obvious ...
<psusi> yea, looks like it isn't running it when I reinstall grub-pc after reconfiguring it to empty the list of devices
<cjwatson> of course grub-pc explicitly warns in that configuration
<cjwatson> but I'm sure some people are clever and ignore the warning ;-)
<cjwatson> still, I'd prefer it didn't break in that case
<psusi> then again, when I put sdc back in the device list, I don't get anything either
<psusi> set -x makes the shell stop and tell you what it is about to do and ask you to confirm and single step throuhg the script right?
<wgrant> cjwatson: I'm booted normally, so yes, they are mounted. Do I have to do anything to force it to update its mappings?
<cjwatson> wgrant: you shouldn't - it should work it out automatically
<wgrant> Because still I get http://pastebin.ubuntu.com/410329/
<cjwatson> wgrant: it might be worth just deleting /boot/grub/device.map (keep a copy for later analysis)
<wgrant> I upgraded about half an hour ago.
 * wgrant tries.
<cjwatson> it shouldn't normally need it any more
<cjwatson> psusi: no
<cjwatson> RTFM :-)
<psusi> oops, it wiped out the -x when I reinstalled the package ;)
<psusi> yea, verbose output, looks like it's detecting it when I put the device back in the auto install list with reconfigure
<cjwatson> I'm not interested in that
<cjwatson> well, probably not
<psusi> the strange thing is that I'm pretty sure the list was empty before so it never should reinstall
<cjwatson> "never reinstall" is a bit of a myth with grub2 right now
<psusi> ?
<cjwatson> it often updates the stuff in /boot/grub/ anyway
<psusi> btw, how does that get populated on a normal install?  and what if the block device changes?
<cjwatson> so if you tell it to never reinstall, it can get out of sync.  that's why it's NOT RECOMMENDED IN BIG LETTERS unless you really know what you're doing.
<cjwatson> grub-install populates it, normally
<cjwatson> if the block device changes, grub-pc.postinst should notice and reask
<psusi> could the conf be subtly different when I empty the list after populating it vs its default state before?
<cjwatson> I don't see how
<cjwatson> hard data would help to reduce the need for speculation. :-)
<psusi> because I don't recall ever answering that question before today
<psusi> I'm trying to reproduce it to get some hard data, but now I can't make it fail ;)
<cjwatson> I think you must be mistaken.  It's really very careful indeed to forcibly ask you if that question is left blank
<cjwatson> I could be wrong, but ...
<psusi> when I originally installed I was not using lvm and I don't recall being asked that question
<psusi> installed with ubiquity before without lvm, then migrated to lvm
<cjwatson> oh, sure, it's set on initial installation
<cjwatson> but I don't see how it could end up blank
<cjwatson> and you explicitly said above:
<cjwatson> 01:43 <psusi> cjwatson, I think I left it blank initially because I didn't want any auto reinstalling.... but maybe an empty list causes it to go wrong?
<cjwatson> were you misremembering up there?
<psusi> then today after it botched up again, I ran dpkg-reconfigure and the list appeared to have no devices checked, so I checked sdc and now everything seems fine... even when I uncheck it again
<cjwatson> well, not sure I can help then - I guess I'll need to wait for somebody who can reproduce it
<psusi> I assumed I had done it on purpose since it was blank... but now that I think about it I don't think I ever saw that question before, and shouldn't have unless I ran a reconfigure before right?
<cjwatson> it's asked when disks change, and in some cases on upgrade from karmic
<cjwatson> (the cases that can't be worked out reliably automatically)
<cjwatson> I suppose you no longer have a raw copy of what the variable was before, via something like debconf-show
<psusi> hrm.. I did add the SSD then have lvm migrate the root fs over and reinstalled grub to boot from it...
<psusi> but that was a manual grub-install, not reinstalling the package, so no debconf
<cjwatson> well, in that case the old by-id values would have been invalid when you ran dpkg-reconfigure, and it would have discounted the old values, making it appear empty
<psusi> aha
<cjwatson> should've asked on the first upgrade of grub-pc though
<cjwatson> but perhaps there wasn't one
<psusi> ahh, so it stores the /dev/disk/by-id value too so it can check if it has changed?
<cjwatson> it stores only the by-id value
<cjwatson> what it shows you in the UI is a different matter
<psusi> hrm.... because the by-id didn't change when I migrated the fs to the new ssd
<cjwatson> I don't believe you
<cjwatson> do you mean by-uuid?
<cjwatson> by-id is tied to the hardware
<psusi> either one I think
<psusi> not for lvm
<psusi> at least I don't think it is
<cjwatson> oh, right
<cjwatson> but you just said you were installing to sdc, not to the LVM
<psusi> yea, I set (hd0) to be sdc in devices.map
<cjwatson> so why does the by-id for the LVM bits matter?
<psusi> good point... so if it stored the by-id before, then I changed hd0 in devices.map, could that confuse it?
<psusi> because before the ssd hd0 was /dev/mapper/nvidia_blah
<cjwatson> messing about with device.map is certainly not recommended.  I don't know that I see how it could have confused it in this case, but it sounds like you've been doing some pretty odd things.
<psusi> hehehe, you got that right ;)
<cjwatson> the packaging should be *completely ignoring* hd0 etc.
<psusi> hell, at one point I even tried booting using an lvm snapshot as the root
<cjwatson> there's no way that stuff can be made reliable, so we don't use it any more
<cjwatson> the only effect of it is to cause there to be a different value in the fallback 'set root=' commands in grub.cfg, which isn't used anyway unless there's some catastrophe that makes UUIDs unusable
<cjwatson> which probably means the fs isn't usable either
<psusi> yea... I've been wondering about that... what happens to search when there's more than one fs found with the same uuid?  like if you have an lvm snapshot?
<cjwatson> grub's built-in LVM support probably doesn't understand snapshots?
<psusi> it seems to see the snapshot, but not understand the exception list so it just looks like a duplicate of the original, iirc
<cjwatson> but if it does, ignoring snapshots is probably the right fix, otherwise weirdness will probably ensue
<psusi> I've been thinking of looking into fixing that since it would be nice if you could snapshot then upgrade and have the choice of which version to boot until you know it works
<cjwatson> seeing as the boot image needs to be in sync with /boot/grub/, I'd rather it just ignored snapshots
<cjwatson> that seems more likely to be useful
<psusi> what do you mean needs to be in sync with /boot/grub?
<cjwatson> the ABI between grub's kernel image installed to the boot record and the modules in /boot/grub is not stable
<cjwatson> if they end up at different versions, you often get hosed
<psusi> ohh
<cjwatson> normally this is not too much of a problem since it's grub-install that updates the modules in /boot/grub/ - the master copies live under /usr/lib/grub/
<cjwatson> BUT, if you have grub installed to one device and then grub-install to some different device, the grub kernel image on the first device and /boot/grub/ may then be out of sync
<psusi> right... but if you did that in a snapshot, it would update only the snapshot copy, then modify the core, which may not be able to then use the original /boot
<cjwatson> so you have to be somewhat careful about consistency when using grub on multiple-disk systems
<cjwatson> indeed, and I don't think that the case for installing grub on snapshots is particularly compelling (note that this is independent from *booting* the snapshot, which you can do with just grub.cfg changes)
<psusi> yea, just have to point it to the snapshot root to load the kernel image from, and change the root parameter to the kernel
<slangasek> lamont: what's an 8-letter word in ia64 for "return"? :) (bug #555127)
<ubottu> Launchpad bug 555127 in xulrunner-1.9.2 "build failure on ia64" [High,Confirmed] https://launchpad.net/bugs/555127
<cjwatson> psusi: so I suppose something like http://paste.ubuntu.com/410341/
<psusi> cjwatson, might be easier to check the status bits... o gets set on the origin and s on the snapshot
<cjwatson> psusi: that appears to be only in lvs output and the like, which isn't available to grub
<cjwatson> it has to work with the raw metadata header
<cjwatson> but if I've missed something, patch welcome :-)
<psusi> ahh, figured there was a flags dword somewhere in the nitty gritty
<cjwatson> doesn't seem to be, the display code does stuff like
<cjwatson>         else if (lv_is_origin(lv))
<cjwatson>                 repstr[0] = 'o';
<cody-somerville> cjwatson, You wouldn't happen to know off the top of your head the partman bug where if you have a sdcard drive that always shows up as /dev/sdb regardless if theres a card or not in it and then you boot from a usb device (which will show up as /dev/sdc) partman will fail looking for /dev/sdb1?
<cjwatson> so in fact I think I'm checking the wrong thing there
<psusi> cjwatson, and what's lv_is_origin do?
<cjwatson> cody-somerville: is preseeding involved?
<cody-somerville> Yes.
<cjwatson> psusi: lots of indirection :)
<cjwatson> cody-somerville: do I get to see?
<cjwatson> also logs?
<cody-somerville> cjwatson, https://pastebin.canonical.com/30185/
<cjwatson> cody-somerville: (TBH I'd rather you filed new bugs rather than trying to find existing bugs - I can always mark them as duplicates)
<cody-somerville> cjwatson, https://launchpad.net/bugs/466616
<ubottu> Error: Could not parse data returned by Launchpad: list index out of range (https://launchpad.net/bugs/466616)
<cjwatson> cody-somerville: odd.  any local modifications to the installer here?
<Terminus> hello. question regarding pam-config, should all possible modules be stackable? want to know before i file a bug for that on samba.
<Terminus> the current winbind pam-config prevents modules of lower priority from stacking.
<slangasek> Terminus: they should, there's a bug, I've just fixed this in the Debian package's svn - please file a bug report
<slangasek> I didn't realize it would affect any modules in practice, or I would've filed it
<Terminus> slangasek: basically change requisite to [success=end default=ignore] right?
<slangasek> yep
<cody-somerville> cjwatson, It is a custom d-i build (just to include a few udebs), but no modifications to the partman udebs
<Terminus> slangasek: well, i don't know if it would affect any other modules either... this is only for common-password btw.
<Terminus> everything else seems to stack properly.
<cjwatson> cody-somerville: ok, I ask because I can't find any calls to sfdisk anywhere in partman
<slangasek> Terminus: yep, I know
<Terminus> okidokie then. bug report it is.
<slangasek> Terminus: when it's filed, please throw me the bug number :)
<cody-somerville> cjwatson, Ah, interesting. I think I might know what that is.
<cjwatson> cody-somerville: oh?
<cody-somerville> cjwatson, custom recovery installer stuff. I assumed this build Steve tested didn't have it but it appears it does.
<cody-somerville> cjwatson, I'll get QA to test a standard Ubuntu image with that preseed file and see if they can reproduce.
<cjwatson> ah.  y'all broke it then? :-)
<cody-somerville> cjwatson, in the case Steve tested, most likely.
<cjwatson> AFAICS the only things in d-i that call sfdisk are grub-installer and lilo-installer, both of which run rather later than partman
<Terminus> slangasek: filed. bug #556996
<ubottu> Launchpad bug 556996 in samba "winbind pam-config potentially breaks stacking with modules of lower priority in common-passwd" [Undecided,New] https://launchpad.net/bugs/556996
<cody-somerville> cjwatson, Sorry. I should have spotted that myself. Thanks for taking a look.
<Terminus> nice.
<Terminus> !botsnack
<ubottu> Yum! Err, I mean, APT!
<cjwatson> slangasek: don't suppose this would be the cause of bug 556785 too?
<ubottu> Launchpad bug 556785 in shadow "Passwd in Ubuntu Lucid has started giving errors since last update" [Undecided,New] https://launchpad.net/bugs/556785
<cjwatson> seems a stretch, but ...
<slangasek> cjwatson: unlikely; that's probably a duplicate of the bug ttx fixed in the samba update this morning
<slangasek> which is related, except for the part where it's already fixed
<cjwatson> ok
<Terminus> slangasek: ah... the passwd problem? filed a bug on that one too with the comment on stacking as well but it was marked duplicate.
<slangasek> right
<Terminus> while we're talking about this, pam_mkhomedir.so isn't suitable for inclusion in the winbind pam-config, right?
<slangasek> Terminus: I wouldn't think so, since a) not everyone necessarily wants it, b) pam_winbind supports its own mkhomedir option
<slangasek> Terminus: I think it would be better for libpam-modules to ship a (disabled-by-default) profile for pam_mkhomedir
<Terminus> slangasek: yeah, that would be nice. only difference between mkhomedir and pam_mkhomedir.so is that the latter uses /etc/skel...
<slangasek> ah
<slangasek> could you file a wishlist bug on pam for this, too?
<Terminus> slangasek: sure. which package though?
<slangasek> 'pam' :)
<Terminus> ok. hehe
<Terminus> still have another bug to file about libpam-mount having problems creating directories. keep on forgetting this one. >_<
<Terminus> slangasek: i see you're also subscribed to bugs for libpam-mount. i've filed two bug reports there if you're interested, bug #556239 and bug #557025
<ubottu> Launchpad bug 556239 in libpam-mount "mounting cifs uses uid and gid options by default" [Undecided,New] https://launchpad.net/bugs/556239
<ubottu> Launchpad bug 557025 in libpam-mount "pam_mount.so chown to user when creating directory fails" [Undecided,New] https://launchpad.net/bugs/557025
<slangasek> Terminus: I'm afraid I'm unlikely to be much help on those; the XML config file format gives me the heebie-jeebies, I'm only subscribed to libpam-mount to keep track of any fallout from the pam-auth-update integration
<Terminus> slangasek: ah... yes. it's not exactly the most beautiful config file. i also see you've seen the mkhomedir wishlist. forgot about the default.
<pitti> Good morning
<Pslam> Ah i'm afternoon
<dholbach> good morning
<geser> good morning pitti and dholbach
<dholbach> hey geser! :)
<pitti> hey geser, how are you?
<geser> I'm fine
<m4rtin> morning all; any sponsors around to have a look at a patch for lucid regression in bash-completion?
<bigon> could some one have a look at bug #549234 please?
<ubottu> Launchpad bug 549234 in hellanzb "Please sync hellanzb (0.13-6) from debian unstable" [High,Confirmed] https://launchpad.net/bugs/549234
<zyga> hello
<zyga> mvo: hi
<zyga> mvo: I'll try to fix the other bug today, I had update my know-how with dbus to get into that code properly
<mvo> zyga: cool
<zyga> mvo: I did one cool thing yesterday though, I rewrote command-not-found to be a dbus service
<zyga> mvo: it's super fast and responsive now
<lifeless> zyga: err
<lifeless> zyga: why?!
<zyga> lifeless: because it stays in memory
<lifeless> zyga: I don't see why a dbus service has any reason to be faster, unless its using up memory for no purpose
<zyga> lifeless: and python startup time is no longer an issue
<zyga> lifeless: responsiveness == startup time mostly
<zyga> lifeless: now it's giving you output in 0.021 seconds
<lifeless> uhm
<zyga> lifeless: previously it was 0.5 +
<lifeless> command not found is 3 python files
<zyga> lifeless: yeah but it opens several files, reads databases
<zyga> lifeless: talks to apt
<zyga> lifeless: all in all it's not free
<lifeless> the databases are not python startup time though
<lifeless> zyga: how much memory does it use
<zyga> lifeless: true
<zyga> lifeless: let me check
<lifeless> there are good algorithms for fast string match search (where fast == examine a smal fraction of your database)
<zyga> lifeless: I'll upload the package to my ppa though
<zyga> lifeless: I know, I measured what's long
<lifeless> I think it would be a _much_ better idea to use those, than to waste memory.
<zyga> lifeless: python startup
<zyga> lifeless: database initialization (cold cache, stating lots of files)
<zyga> lifeless: and the minor part was actually giving you the output
<lifeless> zyga: sure; thats why I'm saying change the algorithms in the db you use.
<lifeless> search requires an appropriate data structure.
<geser> pitti: do I read it from the TB meeting log correctly that it is yet undecided if maverick is going to sync from testing or unstable (pending a discussion on the ubuntu-devel mailing list)?
<zyga> lifeless: the database is good, really
<pitti> geser: yes; well, the default mode is "unstable"
<lifeless> zyga: then why are you stating lots of files?
<zyga> lifeless: it's gdbm, there is just one lookup really
<zyga> lifeless: python stats ~500s files on startup
<zyga> lifeless: I stat 10 files to find the database and configuration
<lifeless> zyga: it can, depending on what layout you have
<lifeless> getting rid o the eff
<lifeless> and the package would help
<lifeless> go to a single module
<zyga> lifeless: I encourage you to try to see how old c-n-f worked
<zyga> eff?
<lifeless> possibly even get rid of the python library altogether
<zyga> lifeless: it's best to rewrite the client in C
<lifeless> sorry, fingers haven't quite learnt this keyboard yet
<lifeless> egg
<geser> pitti: ok, will wait on the results from this discussion for how to set the default for requestsync for maverick (if the result doesn't come to late)
<lifeless> zyga: I have looked ;)
<zyga> lifeless: the new code is in lp:command-not-found, do check it out too
<lifeless> zyga: anyhow, I really question the benefit of a continually running service, for something needed very rarely and only taking 0.5s today.
<lifeless> zyga: I'll have a browse round the new code tomorrowish
<zyga> lifeless: the service closes after period of inactivity
<lifeless> zyga: does it ever get called twice in a row anyway ?
<zyga> lifeless: huh?
<lifeless> zyga: note that a second call is going to have nearly no python startup time anyway, because all the stuff being stated has its dentries in cache
<zyga> lifeless: I know that having a warm cache is helpful
<zyga> lifeless: but new code is much more responsive anyway
<zyga> lifeless: next step is to rewrite the client into pure C
<lifeless> zyga: its not clear to me /how/ it can be more responsive.
<zyga> lifeless: and finally (maybe) integrate into bash
<lifeless> cold cache it has to start the service up as well as do what it was doing before.
<zyga> lifeless: because cold cache is not everything
<zyga> lifeless: python + apt
<lifeless> zyga: yes, but if the service *is not running* its still doing the same work, as the version in lucid at the moment, right ?
<zyga> lifeless: yes, the initial startup time is same
<zyga> lifeless: but after that it's only better
<lifeless> hmm
<zyga> I wrote the code yesterday and did some benchmarks
<lifeless> ok
<zyga> and it's really there
<zyga> lifeless: I encourage fixes though
<persia> zyga: Whilst you're fiddling with command-not-found, might you be able to make it also work when Contents.gz is on ports.ubuntu.com rather than archive.ubuntu.com?
<zyga> lifeless: my goal is fast small and lean program
<zyga> persia: it doesn't work like that
<mvo> zyga: I would be interessted in the figure for C client without dbus
<zyga> persia: database is the most difficult thing in the whole program
<mvo> zyga: benchmark figures
<zyga> mvo: I'll try to make them (it's in line with my new job anyway)
<persia> zyga: Hrm?  How does it work then, because it fails completely for armel and powerpc last I checked.
<mvo> zyga: I'm not sure that dbus is worth it, its a good experiment, but it just does not feel right
<zyga> persia: ask mvo :-)
<zyga> mvo: why?
<mvo> persia: right, it does not work for them, there is a data-collector running that builds the db and it needs access to a mirror
<mvo> persia: its currently running on rookery
<mvo> persia: all that is really needed is a mirror then those can be integrated
<zyga> mvo: actually
<zyga> mvo: current code does more, the service loads apt.cache
<zyga> mvo: and gives you the summary of the package
<mvo> zyga: a basic C client prototype should be pretty quick, no?
<zyga> mvo: yes, I'll get to that
<persia> mvo: So UnifiedDataExtractor/mirror/do-mirror isn't the place to fix this?
<zyga> mvo: first the client, finally the service
<mvo> persia: that would work too, just requires a bit of disk-space and bandwidth
<zyga> persia: there is some room for improvement
<zyga> mvo: (do you have the time to run the script I sent you some time ago?)
<mvo> zyga: still not sorry :(
<zyga> mvo: ok
<mvo> zyga: I hope by the time beta-2 comes out
<zyga> mvo: cool, no rush
<persia> mvo: OK.  That makes sense.  Same issue as madison/rmadison in some ways.  Thanks :)
<mvo> persia: there is a spec to include it during the build process
<mvo> persia: but it did not finish for lucid, maybe lucid+1, if LP makes it
<persia> Oh, cool.  In that case I'll delete my local branch, since there's no point in having it on my todo list if it's better done in LP.
<mvo> persia: well, it would be nice to have it for lucid
<mvo> persia: at least for armel
<mvo> persia: all I need is a server to run the extraction on that has a lucid  mirror of archive.ubuntu.com and ports.ubuntu.com
<zyga> mvo, persia, lifeless: I have .deb files if you are interested in checking this
<zyga> lifeless: 29M res, 49M virtual
<lifeless> thats quite a bit for a netbook or smaller machines
<zyga> lifeless: it's not different to what c-n-f had
<zyga> lifeless: old version consumed the same amount of memory each time you made a typo
<zyga> lifeless: (I work on a netbook all the time BTW)
<zyga> lifeless: it's not perfect (especially for embeded)
<lifeless> yes, but the memory is freed after
<zyga> lifeless: but it's not worse really
<lifeless> if you want to work on lower memory footprint, we could do that
<zyga> lifeless: if you work in the shell it doesn't matter - the memory will be taken again in a moment
<zyga> lifeless: I think that as long as your terminal is open c-n-f keeps starting and stopping all the time
<zyga> lifeless: the service makes the process cheaper
<zyga> lifeless: but to make one point clear - the new code can run without the service
<zyga> lifeless: it's not that the interface requires the service ;-)
<zyga> lifeless: on my machine empathy takes more memory
<zyga> lifeless: then mono
<zyga> lifeless: I'll try to tweak gc settings today, maybe we can get the memory level even lower
<zyga> lifeless: (not counting firefox obviously - it takes all the memory)
<zyga> lifeless: if we disable apt.cache() (it's a new feature) the service uses 9MB of memory
<tseliot> mvo: do you know what happened in bug #552548 ? It looks like dpkg made a backup of the files in /etc/ati but didn't install the new files there e.g. they have amdpcsdb.default.dpkg-bak but no amdpcsdb.default
<ubottu> Launchpad bug 552548 in fglrx-installer "fglrx broken after update to 2:8.721-0ubuntu7" [Medium,Triaged] https://launchpad.net/bugs/552548
<mvo> tseliot: for a falure like this it would be helpful to get /var/log/dpkg.log and /var/log/apt/term.log
<tseliot> mvo: ok, I'll ask users to attach those files to the report, thanks
<mvo> tseliot: thanks
<mvo> tseliot: speaking of video drivers, update-manager has a check for SSE support before uprading nvidia-glx from hardy. that is still needed, right? for -173, 180, 185?
<tseliot> mvo: let me check, I think they added back the support for SSE but I don't know to what driver. I'll let you know
<persia> mvo: I have such a server, but would need somewhere to post the results.  Does the architecture of the server matter (my armel mirror is on a powerpc machine, but I can netmount, etc.)
<mvo> tseliot: thanks, I let it in for now
<persia> mvo: Alternately, could we maybe run it on the primary archive server *before* the mirror split?
<mvo> persia: arch does not matter as long as the debs are all there
<mvo> persia: I guess so, I don't have access to this machine though afaik
<persia> mvo: Do you need real access, or just to run a cronjob?
<mvo> persia: just a cron job
 * persia checks for the archive-admin-of-the-day
<persia> cjwatson: Do you know if the pre-split mirror has disk/processor to spare for such a cronjob?
<persia> Would add support for armel/ia64/powerpc/sparc to command-not-found
<cjwatson> it's pretty locked-down, I'd rather not run more code on it
<cjwatson> and there'd be an issue with getting the results off
<cjwatson> but ask IS?
<tseliot> mvo: it looks like support for SSE is back in -173 so you can remove it from your blacklist
<bdrung> pitti: around?
<pitti> hi bdrung
<mvo> tseliot: supports or requires? the check I have in update-manager is to ensure that the CPU has SSE support if the nvidia driver is in use (173,180,185). is that still a valid check? or will it fallback to some non-sse code if the cpu does not support it?
<bdrung> pitti: can you un-blacklist pwdhash? asac and chrisccoulson agreed on it.
<pitti> sure, I can; I'm just curious about the rationale?
<chrisccoulson> pitti - bdrung has volunteered to maintain it ;)
<asac> ack. bdrung is committed to maintain it and upstream is very responsive
<pitti> right, but I thought the point was that it's much easier to use Firefox' automatic plugin upgrades than having to maintain it for three years in universe?
<tseliot> mvo: right, I meant to say that they support non-sse cpus in 173 again (i.e. you can remove it from your list). You might want to add 195 to the blacklist instead (and keep the other versions)
<pitti> asac, chrisccoulson, bdrung: unblacklisted
<bdrung> pitti: but there are many benefits of having a package instead
<chrisccoulson> thanks
<bdrung> pitti: thanks
<zyga> persia: if you and mvo manage to harvest the data for other arches
<zyga> persia: do let me know
<zyga> persia: I want to run a simple script on the archive to improve the quality of the harvested data in maverick and beyond
<zyga> persia: also if you harvest the data with current technology please send me the scan.data file
<persia> zyga: What sort of script?  I can certainly generate local data, etc.
<zyga> persia: let me dig it up
<zyga> persia: the biggest quality problem with current c-n-f data is update-alternatives
<zyga> persia: if you read the code you'll see what hackery we did to get some of that data out of the install scripts
<zyga> persia: but it's time to fix the problem once and for all, we need more package metadata
<zyga> persia: this metadata can be added over time but we need to know _all_ packages that use update-alternatives
<zyga> persia: eventually I will file a bug for each package and add some data to the control file that says what update-alternatives are provided by each package
<zyga> persia: then c-n-f will have perfect data and will never lie or miss a package
<persia> XB-Alternatives-Provided: or similar?
<zyga> persia: yes, something like that - does it already exists?
<zyga> exist
<persia> That's something you *definitely* want to discuss in Debian (or we miss ~14000 packages)
<persia> It doesn't exist to my knowledge: that's just the format that would let it work without a policy bump.
<zyga> persia: I realize that, I hope to meet some people at the next UDS, I'm not really sure how to approach this on the political/debian-and-ubuntu front
<zyga> persia: I still believe in plain technology, I'll write a spec for this metadata, fix all the packages in ubuntu and hope debian syncs back
<persia> zyga: It's not so much political/debian-and-ubuntu it's that such a change ought be done *in Debian*.  We aren't going to be able to sensibly maintain that delta.
<zyga> persia: right, I want debian to adopt the changes, I don't really know how debian syncs changes from ubuntu nowdays
<persia> You really want to start in Debian for that.  The chances you can get all those patches accepted is staggeringly low.
<zyga> persia: I suspect that about 1000 packages could be using alternatives today so it's not an easy target
<asac> pitti: so you already did the blacklisting/removing based on chrisccoulson extension list? nice.
<zyga> persia: even if it's harmless one-liner per package?
<pitti> asac: yes, yesterday
<pitti> asac: might avoid a few people installing beta-2 and unsuported extension packages ;)
<pitti> and likewise, I think u-m will clean up removed packages
<persia> zyga: Yes, because that suddenly means that Ubuntu Developers have to manually merge every Debian upload for those 1000 packages, so it's something on the order of 500 developer-hours per cycle.
<persia> Which is roughly equivalent to one person spending 20 hours a week doing nothing else at all.
<zyga> persia: I see, well that does suck - I don't deny that
<zyga> persia: as I said I hope to talk with some people to know how to execute this best, I'm not really familiar with debian
<zyga> persia: and how to approach them to make this happen
<asac> very good
<zyga> persia: ultimately this could require updating debian packaging standards
<persia> zyga: I'd suggest starting by contacting the Debian Maintainer of command-not-found, who likely can help develop a strategy.
<zyga> persia: does debian have command-not-found today?
<persia> (and yes, it will eventually need a policy bump if it's mandatory)
<zyga> any debian devs around? ;-)
<persia> zyga: Yes, in squeeze and sid.
<zyga> persia: cool, let me check that package
<cjwatson> the best way to make this work in Debian would be to figure out a way to solve Debian #43720 that's compellingly correct enough to overcome historical problems with its interface (cf. Debian #45614), and have it emit the appropriate headers somehow
<ubottu> Debian bug 43720 in debhelper "add support for alternatives somehow (and other redundant requests)" [Wishlist,Open] http://bugs.debian.org/43720
<ubottu> Debian bug 45614 in debhelper "debhelper: dh_alternatives scripts?" [Wishlist,Open] http://bugs.debian.org/45614
<cjwatson> or, even better, add declarative alternatives to dpkg
<tseliot> cjwatson, mvo: do you know why this user reproduced bug #555837 (getting an Exec format error) ?  The script has a hashbang
<ubottu> Launchpad bug 555837 in nvidia-common "package linux-image-2.6.32-19-generic 2.6.32-19.28 failed to install/upgrade: run-parts: /etc/kernel/postinst.d/nvidia-common exited with return code 1" [Undecided,New] https://launchpad.net/bugs/555837
<cjwatson> tseliot: probably bug 430958
<ubottu> Launchpad bug 430958 in sigmundr "Merge the documentation branch with the docs series" [High,Fix released] https://launchpad.net/bugs/430958
<cjwatson> err
<cjwatson> bug 512096
<ubottu> Launchpad bug 512096 in dpkg "[MASTER] Exec format error : package failed to install/remove : installation/removal script returned error exit status 2" [High,Fix released] https://launchpad.net/bugs/512096
<cjwatson> or else perhaps filesystem corruption.  get them to send you a copy of that file
<zyga> persia: found him, thanks for the suggestion
<tseliot> cjwatson: ok, thanks
<dyllan> anybody else having a problem with the network manager applet not working properly?
<lifeless> you could also get that with a wrong-arch binary being called
<lifeless> e.g. the interpreter, or something invoked, was actually amd64 on an i386 kernel
<persia> lifeless: That actually works just fine if you have qemu-kvm-extras-static installed (but most folk don't)
<pitti> lool: your recent logcheck sync added a "mimeconstruct" dependency, which is in universe, and also pulls in a whole slew of new perl modules (also in universe); should we revert the dependency or do the MIRs?
<bdrung> pitti: pwdhash is uploaded and sits now in NEW
<pitti> bdrung: thanks; will be processed during regular archive days
<bdrung> what's the easiest way to get the source package name for a binary package name?
<bdrung> (of a not possible installed package)
<pitti> apt-cache show pkgname
<pitti> Source:
<pitti> (if that field is not there, it's identical to the binary name)
<persia> PKG=foo apt-cache show $PKG | grep Source: | cut -d: -f2 || echo $PKG ?
<bdrung> thanks
<lifeless> bdrung: apt-get source pkg, ctrl-C
<persia> apt-get --dry-run source plg ?
<bdrung> lifeless: not a good idea
<lifeless> bdrung: how so?
<lifeless> persia: +1
<bdrung> k, --dry-run would work, but then i have to parse the output
<lifeless> bdrung: you didn't specify machine-processable
<lifeless> machine processable, a python script is probably best
<bdrung> forgot to mention: for scripting ;)
<wgrant> mdt bin2src!
<persia> That works lovely, but has more dependencies :)
<bdrung> wgrant: ?
<wgrant> multidistrotools has a handy utility, but that's only really practical if you are using mdt for other purposes.
<mvo> tseliot: thanks, so I make it check for 180, 185, 195 and SSE, correct?
<tseliot> mvo: yes, that's correct. Thanks
<mvo> tseliot: great, thanks. code is updated
<tseliot> great :-)
<apw> i have a couple of machine which have been updates as of today, and unlike a new install still have the bright light from above background instread of the new purple background in gdm
<apw> does anyone know what package i am missing
<arand> apw: plymouth, mayhaps?
<apw> i get plymouth ok, its nice [sic] and purple, but then i get the older downlight on transition to X, not the default background
<james_w> as part of gdm?
<persia> apw: Are you sure you don't have some leftover setting?  I had to manually change my preferred theme from (purged) human to the new one to get the new background.
<apw> persia, no this machine is not customised as far as i know
<apw> i try and keep it as virgin as possible while still being useful, so that i catch these sorts of things
<persia> apw: I hadn't thought I'd set the background manually either :)
<apw> its not the main background, as that is ok, its just in gdm
<persia> Might be a bug in the detect-if-the-user-changed-something code though.
<apw> just in that middle ground
<apw> persia, any idea how i might change it
<persia> apw: Actually, no.  The way I used to know how to do it doesn't exist anymore.
<apw> hrumph
 * apw throws hit toys out of his pram ... "i want purple"
<persia> Dunno why precisely.  That background makes my eyes hurt, being just ever so slightly out-of-focus
<apw> persia, its not designed to be looked at ... silly
<apw> persia, i have to agree its nasty on the eye if you stare at it
<persia> What's the point of having the default interface be something that's not designed to be looked at again?
<apw> its particularly vile behind this touchscreen which gives it a slightly sparkly feel
<apw> persia, heh ... i'd ask the design team that
<apw> but they never answer me
<persia> If it was about it being interesting and artistic, I'll support it, but if it's specifically designed to make people want to change it, I question the motives.
<lool> pitti: Argh, sorry about that; I guess we need to patch logcheck to use something else
<lool> pitti: It's three calls to a /usr/bin helper to send emails in src/logcheck
<apw> pitti, i have no idea what we are going to do about your lid thingy
<lool> pitti: If you have suggestions for a replacement apart of sendmail, I'm happy to hear about them!
 * lool needs to run now
<pitti> apw: at this point it's probably between moving the logic into xorg, or fixing non-native resolutions, or refining the lid logic in the kernel; but I have no idea which of those is easier
<apw> lid matching is just plain broken on a huge number of systems, so upstream has pulled back from the lid detection in the kernel as unworkable
<pitti> seb128: you are running with a docked laptop, too, right? does it still work with current kernel?
<pitti> apw: right, understood
<seb128> pitti, define work
<apw> it seems windows doesn't need the initial state, so most bioses are broken wrt to the initial value
<pitti> seb128: my DVI screen just switches off as soon as X starts
<apw> pitti, is it _off_ or blank
<pitti> apw: off
<apw> why would it ever be off if its there
<seb128> pitti, I don't have that issue with -19
<pitti> in very technical terms, the standby light is yellow, not green
<seb128> I do get screen being blank after user switch though
<seb128> and no way to turn it back on until xorg restart
<pitti> seb128: you get the correct resolution on the DVI? is the internal screen on as well (in gdm)?
<seb128> no
<apw> i would expect you to find your lcd is on, and so is your dvi and that your desktop is spread over both
<seb128> I get some 1024 instead of 1900
<apw> not what you want either but, that is what i'd expect
<seb128> but I fix it with the gnome capplet
<seb128> sorry time for a phone interview, be back in a bit
<pitti> apw: if it just affects my particular system, it's probably not such a biggie (I can put an xrandr configuration into gdm's home dir), but at this point I don't know how many systems are affected
<apw> pitti, i suspect its more than you ...
<apw> am testing myself here as wel speak
<pitti> apw: in karmic both monitors had 1024x768, which was ugly, but at least it worked (that also worked with KMS; lots of mode switches, but *shrug*)
<seb128> pitti, I do boot with laptop lid close though
<seb128> not sure if that makes a difference
<pitti> seb128: yes, I keep it closed all the time
<ion> persia: The blurry font rendering Ubuntu uses nowadays donât bother you, though?
<pitti> seb128: in fact, opening and closing again fixes it, since that triggers the lid actions in X
<apw> pitti, do you get gdm on both?
<pitti> apw: on the internal one; DVI is off
<apw> pitti, yeah thats what upstream found, open/close transitions work everywhere but initial 'is open/closed' is completely bust
<apw> i wonder how win7 does it as it clearly doesn't use that
<pitti> apw: if I open the lid and close it again, X's lid actions fix the LVDS first, and then DVI
<persia> ion: I use a low enough DPI (72) that it's not so bad for me.
<apw> pitti, do you even get grub on DVI ?
<pitti> apw: yes, grub/plymouth/VTs work
<persia> ion: If someone optimises for beauty over number of simultaneous elements on the screen, you may have found a kindred soul.
<pitti> apw: but as soon as X wants to switch to 1024x768, DVI goes off
<ion> Not having bothered to make a real solution, i just run sudo perl -i -pwe 's/\000\Klcddefault\000/lcdlegacy\000\000/g' '/usr/lib/gnome-settings-daemon-2.0/libxsettings.so after g-s-d updates. :-P
<pitti> apw: during boot (grub/plymouth/VTs), DVI is in 1280x800 (which is the LVDS's resolution)
<apw> pitti, i get all that _and_ gdm on my VGA port with the lid closed
<pitti> apw: X has never liked 1280x800, and seems to pick 1024x768 as a "compromise" for both displays
<apw> heh yeah this is a squarer one so i get more native looking res
<pitti> apw: I'm just building some postgresql updates, but after that I can try booting with VGA instead of DVI
<apw> pitti, ok with the lid closed i get desktop out on VGA
<pitti> apw: also on LVDS?
<apw> its gone into mirror mode by default it seems
<pitti> right
<apw> when i open the lid, its on both the same
<pitti> that's what it has done here until karmic
<apw> which is not what i expected
<pitti> apw: I still see whether the screen is on or off when the lid is closed (there's a small gap to look through)
<apw> unfortuanatly it doesn't have anything better, dvi or hdmi
<apw> pitti, it looked to be black on mine
<pitti> how wonderfully consistent all this stuff is :-)
<apw> ahh both on 1024x768 as you conjectured
<pitti> apw: mind putting up your /var/log/Xorg.0.log somewhere while gdm is up after booting (with the lid closed)?
<apw> non-native for both ... gah
<apw> pitti, ahh its a x800 here too, so same mangling
<pitti> apw: so I guess moving the lid logic into X will just lead to the very same problems then, and wouldn't help at all
<apw> who chose to mirror i wonder
 * apw isn't sure he would expect the kernel to be making that decision
<pitti> apw: X, I mean
<pitti> but without the lid state it's not that obvious
<ion> This was discussed here recently. bryce knew about the X logic that applies.
<pitti> if you attach a beamer and have the lid open, you certainly want cloning by default
<pitti> with an external monitor you'd rather want only that, in full resolution
<apw> i used to gfind VGA and HDMI did differnt things, one mirrored by default and one extended desktop by default
<persia> Just as a minor complication: consider "convertible" devices where the lid state can be "closed" and the display still viewable (which often triggers a landscape/portrait change in other environments).
<apw> but i think i found they all extended by default after
<pitti> back in karmic I used to have an xorg.conf which forced resolution; I might just dig that back out of my bzr tree then..
<pitti> but it doesn't help for the broken live system boot, of course
<apw> pitti, well we need to know if its different for DVI than VGA, if so then its likely not right
<apw> pitti, OH have you tried disabling you LVDS by default?
<pitti> apw: how?
<apw> you need to know the name of the LVDS as known to drm
<pitti> apw: that's in the kernel log and easy to find out
<apw> kernel boot line video=LVDS-1:d
<pitti> apw: with a kernel option?
<pitti> right
<apw> you can also see it in /sys/class/drm
<apw> be interested to know if that could help
<pitti> /sys/class/drm/card0-LVDS-1
<apw> so LVDS-1 is the right name i am told ... never tried it myself (as yet)
<apw> actually will do it now as i have a test setup
<pitti> apw: I guess xorg.conf is a better solution, though, since it also works in undocked mode
<pitti> if I undock, I actually do want to use the LVDS :)
<pitti> apw: but I'll try that for completeness
<pitti> c'mon psql, build faster
<apw> pitti, yeah be nice to know if then open close enables it as i would expect
<apw> pitti, i am concerned that KMS generally leads us to a need to have default options settable for video things in the kernel
<apw> pitti, and wonder if we are getting to where the user tools need to know that and how to do it
<apw> pitti, ok video=LVDS-1:d made my VGA come up as the only screen and as the native resolution
<pitti> apw: ok, trying the video= option and VGA instead of DVI now
<apw> pitti, not been able to get the LVDS back as yet
<seb128> re
<seb128> pitti, sorry I had a phone call, back
<seb128> pitti, do you need me for any testing?
<seb128> pitti, in summary I'm usually working with lid close + dvi screen and booting docked
<seb128> pitti, gdm resolution is lower that what it should, desktop config has an xrandr config
<seb128> pitti, I don't have issue on boot but dvi cut after user switch and doesn't come back until xorg restart
<seb128> pitti, resuming undocked after a docked suspend leads to no active screen too until I switch between vts which bring the screen back on too
<apw> pitti, i wonder if specifying the native res for the dvi might work
<apw> pitti, doesn't seem to ... hrm
<pitti> seb128: did you get the full resolution in gdm with -18 and earlier?
<seb128> no
<pitti> apw: sorry, back now; took a while, my BIOS is going mad (unrelated to the screen issue)
<pitti> apw: so disabling LVDS works, as expected; haven't tried VGA yet (that's when BIOS acted up and stopped booting at all)
<pitti> I'll continue trying this later on; I need to run out for some 1.5 hours now for an appointment
<apw> pitti, ok ... not managed to work out how to re-enable the LVDS which is sucky
<pitti> apw: anyway, the xorg.conf resolution workaround seems better in that case anyway; X ignores it when there's only the internal LVDS
<lamont> Setting up irqbalance (0.55+20091017-3ubuntu2) ...
<lamont> start: Unknown job: irqbalance
<lamont> I'm guessing iz bug?
<jdstrand> mvo: hi! do you have the kern.log for bug #556343?
<ubottu> Launchpad bug 556343 in bind9 "upgrade error on 8.04 -> 10.04 " [High,Incomplete] https://launchpad.net/bugs/556343
<jdstrand> mvo: I don't think it is apparmor, but want to be sure
<mvo> jdstrand: I can provide it, its a VM that I just need to fire up
<jdstrand> mvo: thanks
<Keybuk> barry: please don't unmark bugs as "Fix Released" just because one person, with clearly different symptoms, is still having issues
<Keybuk> those people should file new bugs, since their problem is unrelated
<MacSlow> pedro_, not really a rb-bug... but related... https://bugs.launchpad.net/bugs/451086 is about to be fixed today... just wanted to mention it, should it happen to come up tomorrow (rb bug day)
<ubottu> Launchpad bug 451086 in notify-osd "Rhythmbox Notification Bubble shows wrong cover art" [Medium,In progress]
<pedro_> MacSlow, thanks, i'll make sure to communicate that to the triagers
<MacSlow> tseliot, do you know now much work it would be to compile an xorg 1.7.4 for lucid from package-sources?
<tseliot> MacSlow: the whole x stack or only the xserver?
<MacSlow> tseliot, mostly just the xserver... as ATI/AMD fglrx driver for the 5870 only works with 1.7.4 and below... I couldn't get it to like 1.7.6 which comes with Lucid
<tseliot> MacSlow: is this bug #554191? i.e. X segfaults with fglrx
<ubottu> Launchpad bug 554191 in fglrx-installer "fglrx causes X to segfault" [Medium,Triaged] https://launchpad.net/bugs/554191
<slytherin> can any of the archive admins please approve jboss binaries from new queue? It is one of those packages which was removed from archive because of FTBFS.
<MacSlow> tseliot, no... the issue I get with trying fglrx is an undefined DPMSEnabledSwitch() being reported in /var/log/Xorg.0.log
<tseliot> MacSlow: can you file a bug report about it, please? I can report it to upstream and maybe get the fix in time for Lucid
<MacSlow> tseliot, ok
<tseliot> thanks
<lepagee> Today'S ISO image does not boot
<pitti> apw: so, no difference for me with VGA vs. DVI; I'll follow up in the bug report
<cjwatson> lepagee: we produce lots of daily builds, you need to be more specific
<lepagee> http://cdimage.ubuntu.com/daily-live/current/
<lepagee> this one, now
<cjwatson> which architecture?
<lepagee> it say: "BUG: soft lockup - CPU#0 stuck for 61s! [event 0:6]"
<lepagee> 32 bit
<lepagee> on a pentium 4
<cjwatson> http://iso.qa.ubuntu.com/ records some successful tests, so it is not happening for everyone
<cjwatson> that's a kernel bug then
<cjwatson> #ubuntu-kernel, or file a bug on the 'linux' package in Ubuntu
<lepagee> all other Ubuntu since 4.10 run fine
<lepagee> cjwatson: #ubuntu-kernel is a private channal
<cjwatson> doesn't look private to me
<cjwatson> anyway, like I say, it's a kernel issue, you can file a bug about that
<ogra> cjwatson, i think -kernel wasnt migrated after the freenode update, you cant speak if you are not identified
<cjwatson> ah
<cjwatson> subtly different from private, that
<cjwatson> anyone can identify
<ogra> indeed
<ccheney> is it expected (or a bug) that when using the human theme that checkmarks in menus are white on beige, it seems very hard to see them
<user0> something really needs to be done about the partitioner during installation of karmic
<user0> it's one thing to say "commit changes to disk" and another to format a partition without confirmation
<slytherin> can any of the archive admins please approve jboss binaries from new queue? It is one of those packages which was removed from archive because of FTBFS.
<jdstrand> cjwatson: hi. is the ordering of devices listed by /proc/mdstat supposed to be consistent with a raid1 install? I ask because if I use ext4, I have 'active raid1 vdb5[1] vda5[0]' but with ext3 I have 'active raid1 vda1[0] vdb1[1]'
<jdstrand> cjwatson: notice vda and vdb are listed in a different order
<cjwatson> jdstrand: I thought it was basically whatever mdadm felt like, or maybe the kernel's md subsystem
<cjwatson> does it matter?
<jdstrand> I think http://testcases.qa.ubuntu.com/Install/ServerRAID1 depends on the ordering used with ext4
<apw> ogra, ais the kernel channel meant to have migrated somehow, something we are meant to have done?
<jdstrand> at least, that is my theory as to why following that works with ext4 and doesn't work with ext3
<jdstrand> (steps 16 and 17 are where things go awry)
<jdstrand> well, really 16.5, since I shutdown the machine, add the disk then boot
<cjwatson> jdstrand: that I don't know - pretty surprised that it would make any kind of difference though
<ogra> apw, i think so, dont ask me what has to be done though
<jdstrand> cjwatson: maybe it the ordering doesn't, but something is weird. I'l keep poking at it. thanks
<jdstrand> s/it//
<Damascene> hello, please what we can do about this? https://bugs.launchpad.net/vte/+bug/263822/
<ubottu> Launchpad bug 263822 in vte "RTL (right to left) support in terminal (BiDi)" [Low,Triaged]
<Damascene> no one is responding
<Damascene> we want to install mlterm for rtl languages but no help from any
<jdstrand> kees: you seem to have written most of http://testcases.qa.ubuntu.com/Install/ServerRAID1. can you read backscroll from the last 5 minutes and comment?
<jdstrand> kees: make that 8 minutes
<soren> jdstrand: The order in which they're listed depends on the order in which they're discovered at boot (and thus added to the md device), doesn't it?
<soren> jdstrand: The number in the brackets denote the ordering in the RAID set, I think.
<jdstrand> soren: that would make sense, so as such, it shouldn't matter... hmmm...
<soren> jdstrand: I can't find any docs on the format of mdstat, but if I'm reading the code correctly, both my statements above are true.
<soren> jdstrand: Does it fail in any way?
 * dholbach hugs soren
 * soren hugs dholbach 
<dholbach> :-)
<soren> dholbach: Hey, man :)
<dholbach> how are you doing? :)
<soren> I'm doing great! Having fun at $NEWJOB and all that. Good times.
<dholbach> :-)
<dholbach> great
<jdstrand> soren: it isn't that it fails per se, it is that with ext3 after shutting down, adding the first disk back and rebooting, both disks are active (ie there is no sync). this causes fsck to fail hugely
<soren> jdstrand: Erk.
<soren> jdstrand: I'd classify that as failing :)
<jdstrand> soren: well, yes, but I don't know if it is a test case issue or an actual failure
 * soren reads it again
<jdstrand> soren: as I move from 16 to 17, I have to do some stuff that isn't listed (ie, shutdown, then add the disk and start up)
<jdstrand> what I affectionately call '16.5'
<jdstrand> I'm going to try ext4 again
<jdstrand> it worked once, whereas ext3 has failed 3 times
<soren> Yeah, there's certainly a step missing in the test case, IMO.
<soren> At any rate, if two disks turn up that belong to the same RAID set, but they're not in sync.. Man, I don't know. This is why I've never liked the boot degraded raid stuff.
<jdstrand> ok, if '16.5' becomes 'shutdown the system, add both disks, start the system'
<jdstrand> then with ext4 when I start up, I don't need to -a the disk, but cat /rpoc/mdstat shows it is recovering (ok)
 * jdstrand tries ext3 again
<soren> jdstrand: Which one takes precedence in that case?
<soren> jdstrand: Whichever one is discovered first?
<jdstrand> soren: well, mdstat gave me:
 * soren shudders at the thought
<jdstrand> active raid1 vda1[2] vdb1[1]
<soren> Really, this is exactly what is wrong with "boot degraded raid".
<jdstrand> 1464256 blocks [2/1] [_U]
<jdstrand> hmm
<soren> If you've got flaky hardware such that the disk that happens to work on boot alternates, there is /no/ way you will not have data loss.
<jdstrand> my swap has 'vda5[0] vdb5[1]'
<jdstrand> notice that for '/' we have vda1[2]
<soren> Ah, so [0] is no more?
<jdstrand> soren: correct
<psusi> jdstrand: wait, you remove one of the legs of the mirror, then add it back later and it's now out of sync and you're getting bad data from the out of sync disk?
<jdstrand> soren: actually, it seems to have fixed itself after syncing
<jdstrand> psusi: I am follwoing http://testcases.qa.ubuntu.com/Install/ServerRAID1
<jdstrand> psusi: I do step 16. then I make up step 16.5 (shutdown, add missing disk back, boot) and proceed to 17
<jdstrand> (17 isn't needed with ext4)
<psusi> oh dear, this seems to say to boot degraded on one disk, then boot degraded on the other disk, so now both are out of sync with each other
<jdstrand> psusi: yes it does
<jdstrand> psusi: which is why I was thinking it may be a faulty test case as opposed to a bug
<psusi> ok, so yea, when you reboot with both disks mdadm should decide one is failed and you have to manually re-add it, which is step 17... and at that point is when you run a fsck and fail?
<soren> jdstrand: If I'm brutally honest, I'd say the test case is right. The "feature" is wrong :)
<jdstrand> psusi: I have not had to do step 17
<psusi> no... test case is rather pedantic, but should work....
<jdstrand> psusi: with ext4, it just showed up and started syncing
<psusi> ohh, yuo mean when you reboot with both disks again, mdadm just picks them both up and thinks everything is fine and in sync?
<jdstrand> psusi: with ext3, yes. with ext4 it syncs first
<soren> The test case exercises the feature correctly, I think.
<soren> (apart from the missing step 16.5)
<psusi> hrm... that's odd... wonder why the fs makes a difference.... afaik, mdadm should see that both disks have the other disk marked as failed, so you have to do step 17 to manually re-add one, at which point it will resync the whole disk
<soren> psusi: Do you know which one it will favour? I've been trying to work that out. I'm assuming the one with the most recent timestamp.
<psusi> I think it just takes the first one it detects
<soren> Hmm... Well, no.
<soren> Yeah, I was just about to say.
<soren> It will have ot.
<soren> to, even.
<psusi> so when it finds the first disk, it should activate the array with one failed disk... when it finds the second disk, it should fail to activate it since that disk says the other already active disk is failed
<soren> One would hope.
<psusi> so when you use ext4 and it does the resync, it resyncs correctly and everything is fine right?
<jdstrand> psusi: yes
<psusi> but with ext3 it skips the resync for some reason, and fsck fails
<soren> Spectacular.
<jdstrand> I need to redo my ext3 install-- seems something went wrong as grub wasn't installed to the 2nd disk
 * jdstrand tries for the 5th time
<mpt> tremolux, hi, how's the bug-fixing going?
<tremolux> mpt: hiya!  it's going well I think
<tremolux> mpt: did you have any particular bugs you are thinking about?
<mpt> tremolux, no, not really -- I have personal bugbears, but they're not the same as the most important bugs
<tremolux> mpt: yeah, I know the feeling
<mpt> mvo, how's work going for you? Are you still concentrating on upgrade stuff?
<jdstrand> soren, psusi, kees: ok. confirmed on a fresh install with ext3/raid1 that after both have been removed (step 16), adding the disk back results fsck complaining wildly about /dev/md0 containing errors
<jdstrand> I'm going to file a bug
<mpt> mvo, in bug 347256 pgadmin was given a lovely vector icon, but in USC it still shows the crusty bitmap. Is that just because app-install-data-ubuntu needs updating?
<ubottu> Launchpad bug 347256 in pgadmin3 "pgadmin3 has ugly icon" [Undecided,Fix released] https://launchpad.net/bugs/347256
<psusi> jdstrand: and by add back you mean just plug the disk in, not mdadm add right?
<jdstrand> psusi: yes
<jdstrand> psusi: shutdown, add disk, boot. boom
<jdstrand> bug #557429
<ubottu> Launchpad bug 557429 in linux "booting out of sync RAID1 array fails with ext3 (comes up as already in sync)" [High,New] https://launchpad.net/bugs/557429
<psusi> jdstrand: can you boot from another disk and mdadm -E each component disk just before the failure?
<jdstrand> psusi: the failure is very early in boot -- when it tries to bring up '/'
<psusi> jdstrand: hence boot from another disk ;)
<jdstrand> psusi: maybe I misunderstand?
<psusi> i.e. livecd
<jdstrand> let me try
<chrisccoulson> directhex - libevolution5.0-cil should still be in the archive shouldn't it?
<directhex> chrisccoulson, probably not. doesn't work. no life from upstream in making it work with modern e-d-s
<chrisccoulson> directhex - oh, ok. i was going to disable the mozilla plugin in beagle, but i need libevolution5.0-cil (unless i turn off the evolution support too)
<directhex> we've been turning off evolution support globally in mono packages
<directhex> beagle we have some crashers which is why it's not been updated in debian
<chrisccoulson> directhex, am i ok to just turn it off in the current version then, or should i just leave it for now?
<directhex> chrisccoulson, frankly, beagle is dead upstream. do what you like to it
<smoser> cjwatson, i wonder if you would consider having the ssh installer drop the user into a screen session that was running d-i rather than directly attached to d-i.  (i also wonder if you're the right person to ask).
<chrisccoulson> directhex - ok, thanks :)
<kees> jdstrand: are you waiting for resync to finish?
<jdstrand> kees: you are referring to my raid issue?
<kees> jdstrand: yup, based on scrollback
<jdstrand> kees: if so, see my newly filed bug #557429
<ubottu> Launchpad bug 557429 in linux "booting out of sync RAID1 array fails with ext3 (comes up as already in sync)" [High,New] https://launchpad.net/bugs/557429
<kees> jdstrand: ... wow.
<kees> jdstrand: that's an intense regression in md.  I lack the imagination to understand how it involves the filesystem, though.
<jdstrand> kees: I have no idea. I just happened to notice it
<jdstrand> (lucky me)
<kees> jdstrand: pretty weird.  perhaps the problem is that neither drive is seen to "fail", just go missing.  still, odd.
<jdstrand> psusi: superblocks.txt attached to the bug
<jdstrand> kees: notice that even with ext4 'sudo mdadm -a /dev/md0 /dev/MISSING-DEVICE' is not needed
<jdstrand> kees: it just comes up as out of sync and starts doing stuff (see psusi's explanation in backscroll)
<jdstrand> kees: I also updated step 17 in http://testcases.qa.ubuntu.com/Install/ServerRAID1 to explictly poweroff, reconnect the disk (so both are there) and poweron the system
<jdstrand> kees: I left your 'sudo mdadm -a...', even though it doesn't seem to be required
<kees> jdstrand: yeah, that's the step that makes no sense -- it should stay "ejected".
<kees> this is a change in md behavior.
 * jdstrand nods
<psusi> jdstrand: wait, this is taken after you booted from each individual disk, but just before reconnecting both?
<jdstrand> psusi: no. it is from after reconnecting both
<jdstrand> psusi: would you prefer just before?
<psusi> jdstrand: ahh, what's it look like just before, yea ;)
<jdstrand> psusi: ok, hold on
<jdstrand> (thank goodness for snapshots)
<psusi> at that point they both SHOULD say degraded with the other disk marked as failed... which SHOULD prevent them from both being activated when you reconnect both...
<kusum> cjwatson: Hello
<kusum> I had a little problem understanding how after grub loaded , ubuntu starts to run as if dual boot
<Caesar> cjwatson: is it accurate that it's not possible to preseed a more complex disk layout that involves two LVM PVss/VGs ?
<psusi> jdstrand: that looks right... what about disk2 after booting with disk2 alone?
<jdstrand> psusi: getting it now...
<psusi> jdstrand: so did I see that test procedure had you use debconf to configure mdadm to automatically activate the degraded array, instead of passing the kernel command line to force it?  I wonder if that has something to do with it
<jdstrand> psusi: I answered yes to the debconf question
<jdstrand> (booting degraded)
<jdstrand> psusi: disk2 superblock attached
<psusi> yep... that's what it should look like alright...
<jdstrand> psusi: would it be useful if I attached both disks, booted into the live cd and grabbed the superblocks at that point?
<jdstrand> (ie without booting off those disks)
<psusi> jdstrand: maybe.... booting from the livecd should not automatically activate the arrays, so the superblocks should not change, but you might try manually activating the array and see if it properly detects the failure or if it screws the pooch
<psusi> jdstrand: when you boot with one disk, you get the warning abut being degraded and are given 15 seconds to abort activating degraded or not, right?
<jdstrand> psusi: I don't see a warning cause of plymouth, but there is a pause yes
<jdstrand> (I assume cause of plymouth)
<psusi> hrm... I thought plymouth was supposed to show you important things like that...
<psusi> jdstrand: can you boot with nosplash and noquiet boot options to disable that?  after plugging both disks back in, the udev script tries to do an incremental build when it detects each disk.  That should fail for both disks, then eventually after a timeout, the fallback script should try to do the degraded activate... at that point only one disk should be activated and the other ignored
<akgraner> davidm, ping
<davidm> hi akgraner
<akgraner> davidm, mind a pm?
<davidm> akgraner, not at all, welcome to call also if need be
<akgraner> call would be better
<jdstrand> psusi: I didn't get to grub in time, but after a long pause it flashed a screen at me very clearly stating I am booting in degraded mode (each time with disk1 and disk2 removed)
<psusi> jdstrand: long pause like 3 minutes?
<jdstrand> psusi: no, 15 seconds or so
<psusi> ohh, right, I think the 3 minute timeout got removed and now it just dose a udevadm settle then falls back if it can't find the root
<psusi> jdstrand: did you still get that timeout and message about degraded when you reconnect the second disk?  or does it just plod along happily like nothing is wrong at all?
<psusi> until the fsck fails of course
<jdstrand> I don't think I got the timeout, let me check
<jdstrand> I can make the VM available if desired
<jdstrand> or just follow the Install/ServerRAID1 guide
<jdstrand> psusi: no pause. straight to file system errors
<psusi> ok, then the error seems to be when udev does the --incremental
<psusi> that SHOULD only activate the first disk
<psusi> well, actually it should fail to activate in degraded mode
<psusi> then the fallback should only activate the first disk after the 15 second timeout and warning
<jdstrand> psusi: I'm going to have to move along atm. I'm sure this is reproducible by following the instructions in the bug (it happened here many times)
<jdstrand> psusi: I updated the bug with everything
<psusi> k
<jdstrand> psusi: thanks for looking into it :)
<psusi> jdstrand,kees: wow, it does it under karmic as well... after activating and modifying each leg of the mirror degraded alone, mdadm --incremental happily inserts the second one back into the running array as if it were clean, no resync, so you get a munged fs with random chunks from each disk
<jdstrand> erk
<jdstrand> I wonder why ext4 works then
<soren> jdstrand: It's possible that ext4's fsck just doesn't see any problems.
<soren> jdstrand: Don't know if it's plausible, though.
<soren> jdstrand: Oh, right, you say it actually syncs when you're doing ext4?
<jdstrand> soren: no-- when I boot in with ext4, the disks are syncing
 * jdstrand nods
<soren> Ok.
<psusi> hrm... weird.. I used ext4 just now testing it on karmic and it didn't sync
<highvoltage> slangasek: howdy, do you perhaps know which version of the edubuntu seeds was used to build http://people.canonical.com/~ubuntu-archive/livefs-build-logs/lucid/edubuntu-dvd/20100407/livecd-20100407-i386.out ?
<highvoltage> slangasek: latest is revision 774 but it seems that an older one is used, since it still contains ubiquity-slideshow-ubuntu
<slangasek> highvoltage: it should have used whatever was current - however, seeds that correspond to tasks have to go through two publishing cycles before they're reflected in the archive
<nemo> I'd like to get Hedgewars 0.9.13 officially into Lucid - will avoid nag messages for Ubuntu players and a generally empty server.  I should just go ahead and file a bug noting the existing debian package?
<highvoltage> slangasek: ah yes, right
<slangasek> jibel: I'm concerned that the bug pattern you've added for 553745 may be too broad; I've seen a lot of backtraces that are the same, but I've also seen some that don't match despite segfaulting in the same function
<jibel> slangasek, hm, no chance to identify the pattern before the retracer then ?
<slangasek> jibel: I don't think so.  OTOH, it's possible that we have a large enough sample size now that it won't matter
<jibel> slangasek, I remove that pattern for now. ping me if you want to reenable it later.
<nemo> heh. there's no lucid-backports section yet.  Should I be waiting until launchpad has one? (was taking my cue off of https://bugs.launchpad.net/karmic-backports/+bug/485168)
<ubottu> Launchpad bug 485168 in karmic-backports "Please backport Hedgewars 0.9.12 to Karmic" [Undecided,Fix released]
<slangasek> jibel: cheers
<rickspencer3> slangasek, hi
<slangasek> rickspencer3: hi
<rickspencer3> slangasek, I just sent a note to ubuntu-devel about default search provider in 10.04
 * slangasek nods
<rickspencer3> it's a it of a last minute change
<rickspencer3> I am concerned about documentation and translations folks
<rickspencer3> I was wondering if you could suggest a way or otherwise help me connect to these folks so I can see if there is any kind of support I can provide
<slangasek> rickspencer3: ubuntu-doc, ubuntu-translations lists are the normal way to contact them
<asac> rickspencer3: ask ubuntu-doc@lists...
<asac> heh
<rickspencer3> thanks slangasek
<slangasek> translations? translators, maybe
<sebner> rickspencer3: I'm curious, mind explaining the switch back to google?
<rickspencer3> sebner, well
<rickspencer3> there are a lot of parties involved
<rickspencer3> so I can't be as transparent as I'd like
<rickspencer3> sebner, don't you think it's for the best, though?
<sebner> rickspencer3: sure, I always prefered google of yahoo but you posted quite a lot reasons about the switch to yahoo so I was wondering why you switch back
<rickspencer3> mmm
<rickspencer3> well, I hate to have to be coy about it
<rickspencer3> but I can say that, on balance, I think it's best for everybody, including Ubuntu itself
<sebner> rickspencer3: np, I understand when you can reveal it
<sebner> *can't
<rickspencer3> I can only be transparent about the fact that I can't be transparent ;)
<sebner> heh
<sebner> nvm :)
<ajmitch> rickspencer3: you know it'll spawn all sorts of gossip & conspiracy theories :)
<rickspencer3> ajmitch, what can I do?
<sebner> well ...
<sebner> â¬â¬â¬â¬â¬â¬â¬â¬â¬â¬â¬â¬â¬â¬â¬â¬â¬â¬
<ajmitch> sit back & enjoy some of the wilder ideas?
<rickspencer3> right
<rickspencer3> it is what it is
<sebner> ajmitch: I guess 99% will say â¬â¬â¬â¬â¬â¬
<slangasek> ajmitch: I think it's clear: the only reason Ubuntu would stop sending search results to Yahoo and put money in Microsoft's pocket is because Microsoft now controls Google and we just don't know it yet
<rickspencer3> just so you guys know, after the mobs storm my house, my heart was in the right place
<ajmitch> sebner: right, most likely
<rickspencer3> slangasek, I'm afraid that's the last we'll hear from you
<slangasek> :)
<rickspencer3> somewhere in redmond a little light on a control board lit up just now
 * sebner waves goodbye to slangasek 
<ajmitch> slangasek: just what I needed for submitting to slashdot!
 * sebner thinks google replaced "Ubuntu" with "Windows 7" in the search results so Ubuntu had to switch back
<psusi> say, anyone got a second to do a quick bzr merge, push, and dput?  bug #534743 just has a one liner change to fix a critical fail to boot error for dmraid users I'd like to get in for beta 2
<ubottu> Launchpad bug 534743 in dmraid "dmraid causes udev event feedback loop in Lucid" [High,Triaged] https://launchpad.net/bugs/534743
<james_w> psusi: the start of a long night... :-)
<sebner> rickspencer3: can I assume that Yahoo is now pretty p*ssed off?
<psusi> better to get it in for beta 2 and run into trouble than slipping it in after and running into trouble at release ;)
<psusi> and I REALLY hope this serious regression doesn't make it into release
<james_w> psusi: "a second [...] quick [...] one liner [...]" makes me nervous ;-)
<psusi> well I've been trying to get it in all week now so it wouldn't be last minute, but ;)
<james_w> I'm not sure there are any more respins planned anyway
<james_w> and you haven't answered Scott's question in the bug
<slangasek> james_w: there are not
<slangasek> it could still be uploaded in anticipation of the freeze lift, though
<psusi> james_w: ohh, we discussed it a bit on irc while he posted that.. as I explained in the initial description, the change event is created by dmraid removing the partitions the kernel detected on the physical disk
<james_w> psusi: well, please update the bug
<james_w> there's too much uncertainty there for me to upload it given my unfamiliarity right now
<psusi> well, he asked a question that was already answered previously, but ok ;)
<james_w> and given that it won't be in beta 2 anyway I don't feel the need to do it now
<psusi> doh
 * psusi crosses fingers for rc
<nxvl> lamont: ping
<lamont> sup?
<cjwatson> smoser: I don't think I object, but it's not a component I know well and I don't expect to have time to implement it.  It should probably be raised as a wishlist upstream
<smoser> fair enough
<cjwatson> Caesar: I thought that was perfectly possible - there's an in_vg specifier and such - but I'm not in front of my laptop to check right now
<cjwatson> kusum: sorry, not really sure I understand the question
<lamont> sup? <-- nxvl
<nxvl> lamont: Ng just ping me about terminator, i already have the package but got a few request from my debian sponsor, POX is quite nitpicky and want some man pages fixes first, for ubuntu i was waiting for it to land in debian, but Ng told me he talked to you about uploading it
<lamont> nxvl: yeah - I wants it for lucid
<nxvl> lamont: should i just upload to the ubuntu archive or do i need to do somethng special?
<lamont> and if the nitpicky issues are sufficient, we'll just have to make Ng do an SRU for it then
<lamont> it needs a bug report, and the pain
<lamont> https://wiki.ubuntu.com/FreezeExceptionProcess <-- nxvl
<nxvl> lamont: the issues i've been asked to fix are an issue that has been forever with the manpage (a really huge line that needs to be that way but lintian complains) and a minor really easy to fix issue with a "-"
<Laney> so it won't take long to fix and sync ;)
<lamont> ah, those are minor imo
<nxvl> Ng: ^^
<lamont> though if you committed the issue with the "-" for Ng before he pushes 0.92, that'd be lovelish
<nxvl> Ng: can you please start with the bugs and stuff and i will ack and upload afterwards?
<Ng> yep, I'm just tidying up the release and then I'll file the bug
<nxvl> lamont: I: terminator: hyphen-used-as-minus-sign usr/share/man/man1/terminator.1.gz:74
<cjwatson> you should be able to suppress the groff warning about the long line too
<cjwatson> something like .na and .ad around the line in question, or words to that effect.  see 'info groff' for more details
<highvoltage> man I wish Launchpad had a way to moderate comments on a bug
<CRASHME> :DCC SEND "a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a" 1370673706 3500 4
<lamont> highvoltage: but if anyone can moderate..... :-(
<highvoltage> lamont: well, maybe a troll button and if 10 people mark someone as a troll in a thread it just blocks them from commenting further
<Vbitz> why would a nornal boot prosess spawn a root prompt
<highvoltage> Vbitz: running and old Lucid alpha?
<Vbitz> nope only got the iso about 3mounths back
<Vbitz> a problem with filesystem mounting created a root prompt
<cjwatson> if it can't mount the root filesystem for some reason, there's not a whole lot else it can do
<Vbitz> then after it displayed the prompt and i typed some random command to test the input it booted fine after that
<lamont> Vbitz: sounds like maybe the disk too > 30 seconds to show up?
<lamont> I have machines like that
<Vbitz> so the disk took to long to mount causing a problem that created a root prompt
<cjwatson> there's a rootdelay= boot parameter, IIRC
<lamont> cjwatson: yep.  my machine in question has it set to something like 90, takes about 52 seconds to show up
<Vbitz> that is a major exploit problem
<cjwatson> no it's not
<Vbitz> would any key at startup cause that
<cjwatson> you have physical access - that implies root
<lamont> Vbitz: if Ihave physical access to the console and can boot the machine, I own the box
<Vbitz> good point
<lamont> most notably, adding 'break' to the end of the kernel boot parameters....
<lamont> or better yet, boot a recovery kernel;
<Vbitz> is there any dangers to switching runlevel
<Vbitz> when i did it once it made my screen glow and heat up
<highvoltage> Vbitz: heh, I repasted that to my lug channel
<Vbitz> where
<fooscript> Hi! :) Does "kubuntu-dev? exist... or have been ever ?
<fooscript> okey... maybe something easier...  While compiling kdelibs :"CMake Error at cmake/modules/MacroEnsureOutOfSourceBuild.cmake:17 (MESSAGE): kdelibs requires an out of source build.  Please create a separate build directory and run 'cmake path_to_kdelibs [options]' there."  I do not understand. Could anybody explain me in simple words? I came do kdelibs, mkdir build, cd build, cmake .. and... no result :/ What is this path_to_kdelibs?
<fooscript>  aah.. .bashrc is taken from KDE building tutorial. Anybody?
<Laney> there is #kubuntu-devel I believe
<fooscript> Laney: Whoops. .<idiot> I tried #kubuntu-dev ... Sorry :)
<fooscript> bye
<slangasek> kirkland: kqemu in release notes - as this was in universe, I probably won't put it in the release notes unless you think it's going to be a common concern
<Ng> lamont: nxvl: https://bugs.launchpad.net/ubuntu/+bug/557671 - not super useful, but it gets the ball rolling
<ubottu> Launchpad bug 557671 in ubuntu "Update Terminator to 0.92" [Undecided,New]
<Ng> nxvl: you should note that the Depends have changed since the previous version
<nxvl> kees: does mk-sbuild-lv changed name?
<Ng> err, not Depends, Recommends.
<nxvl> Ng: is that on trunk?
<Ng> nxvl: yep, right now trunk and 0.92 are exactly identical
<nxvl> ok
<nxvl> Ng: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=567967
<ubottu> Debian bug 567967 in terminator "do not recommend python-xdg" [Normal,Open]
<nxvl> i'm fixing that
<Ng> nxvl: hrm, yeah fair bug
<kees> nxvl: it is named "mk-sbuild" now
<nxvl> ohhh
<nxvl> ok, i have that
<lamont> Ng: afk about 90 min then will look
<Ng> lamont: cool. I'll be away from consciousness by then. I hope all goes well :)
#ubuntu-devel 2010-04-08
<cody-somerville> If you were going to introduce someone to Ubuntu, would you go ahead and install Ubuntu 9.10 for them or would most folks recommend waiting for 10.04 at this point? I've heard a lot of great things about 10.04.
<jdong> cody-somerville: at this point wait for 10.04 to hit final
<cody-somerville> Cool.
<psusi> whoa... I really pissed something off when I ejected a dvd that had music on it I had previously been listening to with rhythmbox and put in the livecd and tried to open it... the drive vanished from nautilus and /var/log/kern.log is filling with errors saying "VFS: busy inodes on changed media or resized disk sr0"
<psusi> it's like the old disk is still mounted but doesn't show in /proc/mounts
<psusi> hrm... closing rhythmbox seems to have fixed it.... that shouldn't happen should it?  what IS supposed to happen if files are in use when the media is ejected?  I thought the fs was forcibly unmounted and all fds to files there were invalidated?
<lamont> nxvl: still around?
<poningru> OMG we were in a Univeristy challenge question
<LaserJock> is that a good thing or a bad thing?
<nigelb> crimsun, ping?
<nxvl> lamont: here
<lamont> nxvl: I figured I'd let you have the 0.92 upload honors. FFe is blessed, we win, kthx.
<nxvl> just uploaded it \o/
<crimsun> nigelb: pong
<ScottK> lamont and nxvl: Accepted.
<nigelb> crimsun, can you sign up for an hour or 2 as review leader for patch day? https://wiki.ubuntu.com/PatchDay
 * nxvl HUGS ScottK 
<crimsun> nigelb: May 5 looks to be a Wednesday, which would place it squarely mid-workday for me?
<ScottK> nxvl: Go fix me some FTBFS.  BTW, I fixed courier for you (your last upload FTBFS)
 * nxvl runs away silently :P
<nxvl> will start squashing them on the weekend
<ajmitch> #ubuntu-reviewers is the regular channel for it?
 * ajmitch thought it'd be -reviews
<psusi> wow..... just tested installing lucid beta 2 ( or today's nightly that apparently will be beta 2 ) installing to 1.5 tb wd green drive.. takes 11 minutes normally, then when I edit /etc/mke2fs.conf and add lazy_itable_init=1, install time goes down to just over 5 minutes... gets rid of a 5:30-6:00 period of sitting at 5% while running mkfs
<psusi> from liveusb
<psusi> that seems a pretty damn significant performance improvement... any chance of getting that option set for lucid release? :)
<TheMuso> psusi: Does it fix a bug, other than performance, and is it safe to use that option in most cases?
<IntuitiveNipple> Can someone take a look at bug #555500 and maybe push it for release please?
<ubottu> Launchpad bug 555500 in grub2 "Buggy BIOS hard disk workaround missing; causes: "Geom Error"" [High,In progress] https://launchpad.net/bugs/555500
<psusi> TheMuso, no, just takes the mkfs time from 5.5-6 minutes down to ~15 seconds... doesn't seem to be any risk per se... just doesn't init the inode bitmaps and sets a flag on the bg descriptors to tell the kernel that so it initializes them when needed and until then assumes they are unused
<TheMuso> psusi: ah.
<persia> psusi: Does that affect later runtime performance significantly?
<psusi> persia, doesn't seem to... the rest of the install seems to proceed at the same rate as before... and the itable only needs initialized if the kernel actually needs to allocate inodes from that bg... and generally speaking, a lot more inodes are allocated than needed, so most bgs can remain with uninitialized inode bitmaps indefinately
<persia> OK.  I suspect the user has to pay the 5 minutes at some point, but distributed over the lifetime of the install, this may be less obviously apparent.
<psusi> only if they actually use all of the inode tables... most often this is not the case
<psusi> since generally, many more inodes are reserved than the fs will ever have files to use
<psusi> cjwatson, added ubiquity to bug #556621 since this has such a large impact on installing from the livecd.  If it is not made system wide default via mke2fs.conf, then ubiquity at least should consider specifying it when calling mkfs
<ubottu> Launchpad bug 556621 in e2fsprogs "lazy_itable_init not on by default" [Undecided,In progress] https://launchpad.net/bugs/556621
<cjwatson> psusi: I don't think ubiquity should touch it - mke2fs(8) says that it's 1 by default, so why isn't it?
<cjwatson> oh, maybe it doesn't say that
<psusi> cjwatson, you know, I thought so at first but now I get it... the man page is just misleading
<cjwatson> psusi: please don't ever use the ubiquity upstream project for bug tracking.  I'll fix it up
<psusi> if you specify lazy_itable_init, then the VALUE defaults to 1 if you don't explicitly =1
<psusi> but if you don't say anything, the default is 0
<cjwatson> yeah, I've arrived at that reading now
<psusi> if setting it in mke2fs.conf to be a system wide default is not done, ubiquity could add the -E lazy_itable_init when calling mkfs... it makes such a huge difference on these larger drives...
<psusi> ohh, yea... I guess that should have been ubiquity(ubuntu) but my lp-fu is weak
<cjwatson> yeah, I've made that change locally and will test.  thanks!
<cjwatson> I have an external 1TB disk that should be a good test target
<psusi> cool
<lifeless> persia: I was in ubuntu-universe-sponsors. Its expiring; what should I do?
<psusi> after monkeying with this a bit and looking at the fs with debugfs while testing with e2defrag, it seems the default behavior is with unint_bg feature on by default for ext4, mke2fs leaves the BLOCK usage bitmaps in each bg uninitialized and sets the flag indicating such on each bg, but without lazy_bg_init=1, it goes ahead and initializes the inode tables and inode allocation bitmaps in each bg to zeroes
<psusi> with lazy_itable_init=1 it also leaves the inode tables and bitmaps uninitialized and sets corresponding flags in the bg descriptors indicating this is so
<persia> lifeless: If you wish to continue as a sponsor, join ubuntu-sponsors (I'll do that now unless you countermand me before I finish)
<psusi> cjwatson, btw, given any thought to moving to gpt as the default partition label yet when using the full disk on disks over 1tb? ;)
<lifeless> persia: I'd like to. But I'm not able to upload to 'main' yet
<TheMuso> psusi: Does that not require the host system BIOS to be able to work with GPT? Yes I know there is the GPT/mbr sync stuff...
<psusi> TheMuso, nope.... since gpt still has an mbr
<TheMuso> ok
<psusi> it just looks like the entire disk is used by one partition of type e8 I think it was, unless you use gptsync
<persia> lifeless: That's OK.  Just pick stuff you *can* upload from http://qa.ubuntu.com/reports/sponsoring
<persia> lifeless: "unseeded" is the useful keyword (code improvements to make discovery easy are very welcome)
<psusi> and grub should still install and boot fine... it will use blocklists otherwise, but prefers to dump the core in the grub dedicated gpt partition which could be created by default when using a full disk initializing it with gpt as well by default
 * psusi needs to try that out next
<psusi> but wife says it's time for bed now, so night
<ccheney> heh just got an icon merge from munchkinguy tonight
 * ccheney will have to carefully examine it to make he sure he doesn't end up screwing up the merge :)
<kusum> can anyone here expalin me the preseed file
<pitti> Good morning
<dholbach> good morning
<mdke> morning dholbach
<dholbach> hey mdke
<geser> good morning
<geser> pitti: Hi, have you some time to review and sponsor https://code.edge.launchpad.net/~geser/pkg-create-dbgsym/strip_-O_some_more/+merge/22977?
<pitti> geser: I got your mail; will look at it ASAP, promised
<seb128> urg
<seb128> the current beta2 iso partition screen behave weirdly
<seb128> it change the device "sda<n>" numbers on the fly
<stefanlsd> didrocks: do you know if quickly dialogs are broken? mine in lucid dont seem to work
<seb128> ie I delete a partition I don't care about, sda8 and I still get a sda8 in the refreshed list but it's an another one
<didrocks> stefanlsd: no, it should work, let me try
<seb128> and sda6 I wanted to keep is now showed as sda8
<seb128> ev, cjwatson: ^ known issue? what info would be useful in a bug?
<didrocks> stefanlsd: (well, it has been renamed to quickly add dialog btw)
<didrocks> working here
<ev> seb128: news to me.  Can you run ubiquity in debug mode (`ubiquity -d`), reproduce the issue, then run ubuntu-bug ubiquity?
<seb128> ev: ok
<ev> sounds like it could be a bug in the freeze/thaw code in the partman component
<stefanlsd> didrocks: yeah. i picked that up (quickly tutorial incorrect there...) - i create it with quickly add dialog test. I import TestDialog and i get - from sourceswitcher.helpers import get_builder
<stefanlsd> ImportError: No module named helpers
<geser> pitti: no hurry, I just noticed there is now a second merge proposal to fix the same problem: https://code.edge.launchpad.net/~anders-kaseorg/pkg-create-dbgsym/dh_strip-O-X
<tkamppeter> pitti, hi
<didrocks> stefanlsd: ok, understood, someone changed the syntax and didn't think to add helpers.py to existing project :(
<seb128> ev: bug #557913
<ubottu> Launchpad bug 557913 in ubiquity "the manual partitionning screen change partitions numbers" [Undecided,New] https://launchpad.net/bugs/557913
<seb128> ev: do you need screenshots too or are the logs enough?
<ev> they would probably help to understand exactly what's going on
<seb128> ok
<primes2h> tkamppeter: Hi! Any ideas about this bug 557199?
<ubottu> Launchpad bug 557199 in system-config-printer "[Lucid Beta2] [Regression] A lot of strings are still in english or are not translatable" [High,New] https://launchpad.net/bugs/557199
<tkamppeter> primes2h, no, I think I need to contact Tim Waugh about that. I never touched the translation part of s-c-p and I also did not change any standard menu entry.
<tkamppeter> pitti, ping
<pitti> hello tkamppeter
<primes2h> tkamppeter: the big problem is that it affect documentation too, which deadline is coming. we don't know how to handle it into documentation.
<primes2h> tkamppeter: thanks a lot.
<primes2h> s/coming/ coming soon
<pitti> geser: it seems to fix different things
<pitti> geser: Anders' fix is for -X, while your's is for -O ?
<pitti> or, rather, -X-O
<pitti> meh, debhelper really becomes complicated these days
<pitti> this should get a test case
<tkamppeter> primes2h, I have discovered now, it seems that the I18n (/usr/share/locale) is missing in the package. I will fix this in tomorrow's upload.
<pitti> tkamppeter: /usr/share/locale/*.mo is stripped from main packages; they aren't supposed to contain them
<pitti> .mo files are shipped in language packs
<pitti> geser: but Ander's patch doesn't seem to make sense to me -- -X is for file names, not options
<geser> pitti: it's the same issue, http://launchpadlibrarian.net/43380277/barnowl_1.5.1-1_amd64.build shows how it started
<pitti> geser: I do understand your's, but still don't understand Anders'
<pitti> -O-Xautom4te.cache
<geser> pitti: the problem is that my first attempt in 0.39 only "fixed" for boolean flags as it stripped the -O only for the case statement
<pitti> with your's, the -O would be stripped, and you'd get a normal -Xfilename
<pitti> but with Ander's fix, you'd try to strip an -O from the _argument_ of -X
<pitti> but -X-O doesn't make sense at all AFAICS?
<geser> $p is unstripped at this place
<pitti> geser: oh, right; I read it as "further" strip, i. e. on top of your change; sorry
<geser> xopts gets the whole -O-Xautom4te.cache appended (and pkg_create_dbgsym doesn't know what to do with it)
<primes2h> tseliot: Hello, any news about this? bug #553954  dpm told me he would sponsor the exception if needed.
<ubottu> Launchpad bug 553954 in plymouth "[Lucid Beta 1] plymouth has a non translatable string coming up on screen" [Medium,Triaged] https://launchpad.net/bugs/553954
<geser> pitti: there are two different branches to fix the same problem
<tseliot> primes2h: it's on my todo list
<seb128> ev: bug updated
<geser> Anders' branch fixes it only for -O-X but leaves the other ones still broken, while mine branch should (hopefully) fix it for the other cases too
<pitti> geser: merged your's, and running tests now
<pitti> geser: if you fancy it, please write a test for it, then we can merge that later on
<pitti> to ensure it stays fixed
<pitti> geser: thanks!
<tkamppeter> pitti, then the .mo files were not forgotten, I was about to add them. Then the bug is in the language packs.
<pitti> tkamppeter: they do ship the .mo files
<pitti> /usr/share/locale-langpack/de/LC_MESSAGES/system-config-printer.mo
<geser> pitti: will do
<pitti> tkamppeter: s-c-p is translated just fine here
<tkamppeter> pitti, this makes it much more complicated. So the languiage packs need to get updated with every update of the applications.
<primes2h> tseliot: thank you. :-)
<tkamppeter> pitti, are mman pages also centralized?
<pitti> tkamppeter: man pages don't use gettext at runtime
<primes2h> pitti: did you checked strings reported in bug?
<tkamppeter> pitt, I asked because they were also omitted in s-c-p.
<pitti> tkamppeter: ah, right, some strings are missing; they just might not be translated, or the .pot file is missing them, then they are not translatable
<primes2h> pitti: both of them, some are missing from .pot and some are translated but are still in english.
<tkamppeter> pitti, perhaps the langpacks need to get re-generated with the newest .po and .pot files from s-c-p?
<pitti> primes2h: so the latter will just fix itself by translating them and updating the langpacks
<primes2h> pitti: this is a regression, in Karmic those missing were present.
<pitti> primes2h: did you check whether they are in the .pot/
<pitti> ?
<primes2h> sorry, I checked .po in launchpad.
<primes2h> pitti: comparing karmic and lucid .po files, some strings are missing in lucid
<primes2h> pitti: and others are present, translated a long time ago but they are in english
<primes2h> pitti: I'm downloading .pot file from launchpad now.
<tkamppeter> primes2h, pitti, the strings are indeed missing in the .pot file of the source, how can this happen? The main menu entries were always there.
<pitti> tkamppeter: perhaps po/POTFILES.in got broken? Or they aren't marked to be translatable any more?
<pitti> tkamppeter: sure enough:
<pitti>                        <property name="label">_Connect...</property>
<pitti> this is missing translatable="yes"
<pitti> i. e. it needs to be marked as translatable in glade
<pitti> followed up in the bug
<tkamppeter> pitti, perhaps Tim changed the Glade version making the translatable="yes" getting lost or the default changed so that from now on it is needed.
<primes2h> tkamppeter: a commit from upstream probably broke that
<tkamppeter> Is thgere a quick way to fix it?
<pitti> tkamppeter: add the flag manually with a patch, or open it in glade and tick the "translatable" check boxes again
<tkamppeter> pitti, and do I have translations for all languages then? Probably they are also missing?
<pitti> tkamppeter: I guess they were dropped from the language packs when they fell out of the .pot
<pitti> tkamppeter: but once they are translat_able_, LP will recover the old translations, and the next langpack update should have them again
<tkamppeter> pitti, only problem is that there are hundreds of strings in s-c-p and so setting all these translatable flags again can take me several hours.
<pitti> tkamppeter: it's just three or four in the menus, though?
<tkamppeter> primes2h, how many strings are really missing? Is the list in the bug report really complete?
<tkamppeter> pitti, primes2h: The bug report looks like that lots of strings are missing.
<pitti> tkamppeter: when you start the app, it's not that many; it's by and large in German
<primes2h> tkamppeter: in fact, it seems that there aren't a lot missing. There are a lot translated but still in english.
<primes2h> instead
<primes2h> tkamppeter: Those translated but still in english are explicitly mentioned in bug report, all the other are missing (like Â _Connect...
<primes2h> )
<tkamppeter> I have added comments to the bug to contact Tim Waugh.
<primes2h> tkamppeter: I didn't mention all translated but still in english (seems to be a lot)
<primes2h> tkamppeter: but those missing should be all reported.
<primes2h> tkamppeter: thanks
<didrocks> stefanlsd: ok, fixed your issue. You can grab latest trunk, "PATH=/path/to/quickly/trunk/bin:$PATH quickly upgrade" in your project
<stefanlsd> didrocks: thanks! will give it a try. dont see the trunk update yet
<didrocks> stefanlsd: should be better now. Branch diverged and I switched my ws. Rebased and pushed :)
<stefanlsd> didrocks: branching. thanks for the quick fix :)
<didrocks> stefanlsd: you're welcome :)
<tkamppeter> pitti, how do I add a locale to a US-only installed system so that I can test translations? Only "sudo apt-get install language-pack-de" does not work.
<pitti> tkamppeter: you need language-pack-gnome-de for GNOME packages
<tkamppeter> pitti, still says "Gtk-WARNING **: Locale not supported by C library. Using the fallback 'C' locale.".
<pitti> tkamppeter: installing the language pack should have generated the de_DE.UTF-8 locale; didn't it?
<pitti> tkamppeter: you can do it manually with "sudo locale-gen de_DE.UTF-8", but if it's not there, I suspect that the langpack is missing, too
<tkamppeter> pitti, now it weorks, LANG=de_DE.UTF-8 and not only LANG=de, awkward.
<cjwatson> LANG=de has never been valid
<cjwatson> if it worked, it was because you were lucky
<pitti> tkamppeter: it's a locale, not a language
<seb128> cjwatson, ev: let me know if you need extra details on bug #557913, I keep the box in the current disk state for now
<ubottu> Launchpad bug 557913 in ubiquity "the manual partitionning screen change partitions numbers" [Undecided,New] https://launchpad.net/bugs/557913
<cjwatson> seb128: I've commented; there is no need to keep the box in its current state, it's not a regression
<cjwatson> if anything, it's a confusing property of how partitioning works really ...
<seb128> cjwatson, ok thanks
<seb128> cjwatson, I guess it's not so much an issue nowadays with uuid used rather than device entries to do mounting etc
<seb128> cjwatson, I was concerned the install I wanted to keep would stop booting because the partition ordering is changing
<cjwatson> seb128: right, but there's nothing that can be done about that, as I say partition numbers are not a persistent thing stored in the partition table - the fourth logical partition is going to be 8 regardless of whether it used to be 9
<cjwatson> I didn't close it because I wondered whether there might be a less surprising way to present this in the UI
<cjwatson> warning when you delete a partition that would cause partitions to be renumbered?  I can see that being pretty annoying in some cases :-/
<seb128> I'm trying to think about that, I guess out of not showing the number in a such noticable way I don't see one
<cjwatson> I wonder what other partitioners do
<cjwatson> well, but as you say the renumbering could have real effects
<seb128> what confused me is that I noted what "sda<n>" I need to keep before starting the installation
<seb128> and I saw it listed as swap after doing changes
<cjwatson> right
<cjwatson> I understand that it's a problem, certainly, just not sure what to do about it
<seb128> I'm not sure either
<seb128> out of displaying a warning somewhere as you said to indicate that the changes leaded to partition numbering changes...
<seb128> but I'm not sure when and where
<seb128> and if it would annoy most users rather than help
<seb128> cjwatson, I commented on the bug, feel free to set it as wishlist or close it if you think that's it in the category of things which will not likely change, no point to keep buglist noise when not needed
<mdz> james_w, the sub-pages on https://wiki.ubuntu.com/DistributedDevelopment/Documentation seem to be very short, and usually someone would need to refer to more than one of them in order to complete a task. might it make sense to use includes to put them together on the page?
<james_w> mdz: I don't see why we can't provide an all-in-one page, no
<mdz> james_w, at least for the basic "get the source, make some changes, submit for review" workflow
<mdz> (currently 3 pages)
<james_w> yeah
<slangasek> ogra: did you forget to bzr push your debian-installer upload?
<ogra> slangasek, i dont think so
 * ogra checks
<ogra> https://code.edge.launchpad.net/~ubuntu-core-dev/debian-installer/ubuntu seems to have it
<ogra> oh, wait
<slangasek> ogra: UNRELEASED
<ogra> sorry i dont have that branch in autocommit to prevent accidents ...
<ogra> (which i apprently produced now nontheless :P)
<ogra> pushed
<slangasek> ogra: thanks :)
<mdz> Keybuk, had you not pushed that revision to Launchpad until just now? I swear I looked and didn't see it, and it's not in the revision history for my branch
<Keybuk> mdz: I pushed it this morning
<Keybuk> must have forgotten last night
<mdz> we must have raced
<Keybuk> http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/lucid/mountall/lucid/revision/298 FWIW
<Keybuk> my patch is quite a bit different from yours ;)
<mdz> Keybuk, but still a one-liner ;-)
<mdz> ah, you fixed -dev too
<slangasek> Keybuk: do you have thoughts on how plymouth is going to select a different image based on fb bitdepth?  Is this information exposed somewhere the script plugin can already grab it?
<Keybuk> slangasek: I don't think there's an existing function, but it should probably go alongside GetHeight etc.
<slangasek> Keybuk: ok. were you planning to work on the implementation?
<Keybuk> it wasn't a difficult implementation
<Keybuk> I'm not 100% sure it's not already there in fact ;)
<slangasek> I don't see it in script-lib-sprite.c in the package
<slangasek> and I didn't suggest it would be difficult, I'm asking if you're doing it or if I need to open a bug myself to keep it on the radar
<Keybuk> open a bug
<slangasek> (since the flavors will all need theme updates as well once this facility is there)
<slangasek> ok
<Keybuk> at this point of the release process, air traffic control is important
<Keybuk> obviously this depends on having some artwork
<slangasek> implementing the facility doesn't
<Keybuk> but LEAN development says I should not do that early ;)
<persia> But surely it calls to *document* it early, so that the theme providers can prepare, and since the best possible documentation is code ... :)
<Keybuk> I'm actually kinda saddened that we've ended up with a myriad of different *-logo themes!
<Keybuk> I can't work out why each one needs its own .script
<Keybuk> surely they could just Depend: ubuntu-logo and put a different ImageDir in their .theme file
<Keybuk> and refer to the same .script
<slangasek> Keybuk: background colors can't be set as variables in the theme file
<slangasek> if the script plugin allowed loading arbitrary vars from the theme, then it'd be fine
<persia> Also, I suspect the majority copied the ubuntu theme verbatim, rather than looking for ways to refactor for shared scripts.
<slangasek> perhaps, but I looked into this exact question because I was adjusting ubuntu-logo and noticed that flavors were gonna have to merge
<slangasek> and this made me sad too
<persia> With the current structure, aren't all core-devs implicitly also flavour-devs, so that if someone had time, everything could be refactored sanely?
<slangasek> if someone has time to refactor the script plugin to support loading arbitrary vars from .theme, yes
<slangasek> s/refactor/enhance/
<persia> Time is always the painful bit.
<Keybuk> slangasek: can't they?
<Keybuk> slangasek: sounds like that'd be a simple patch ;-)
<dholbach> mvo, geser: will ubuntu-dev-tools get another upload?
<dholbach> with the fixes you put in there? :)
<slangasek> Keybuk: well, feel free... :)
<Keybuk> slangasek: got any spare round tuits?
<slangasek> not me; I haven't grokked the script plugin yet, I'd have to sit down with it for a while to avoid making a mess
<geser> dholbach: yes
<dholbach> geser: awesome
<Keybuk> slangasek: bribe brejc8
<Keybuk> "hey, wouldn't it be REALLY SWELL if script did this" on #plymouth
<slangasek> ok :)
<Keybuk> cjwatson: http://thread.gmane.org/gmane.linux.kernel/969355
<cjwatson> inspired
<mvo> ArneGoetje: it appears that the package description of thunderbird-locale-nb-no is not valid utf8, could you please have a look?
<geser> dholbach, mvo: ubuntu-dev-tools 0.97 uploaded.
<dholbach> geser: THANKS
<mvo> geser: you rock!
<dholbach> indeed
<ogra> bah, plymouth splash has stripes on OMAP
<TrueTom> sudo echo 0x1f > /sys/module/acpi/parameters/debug_layer
<TrueTom> bash: /sys/module/acpi/parameters/debug_layer: Permission denied
<TrueTom> ?
<ogra> see the RootSudo wikipage
<ogra> (and please ask for support in #ubuntu, this isnt a support channel)
<TrueTom> ogra: thanks
<slangasek> pitti: wrt bug #553745, can you tell me anything about how to reproduce it?  do you visibly see plymouth crash when it happens, does it happen on startup or shutdown, does it always happen or only when certain plymouth messages are displayed, etc?
<ubottu> Launchpad bug 553745 in plymouth "plymouthd crashed with SIGSEGV in ply_event_loop_process_pending_events()" [High,Confirmed] https://launchpad.net/bugs/553745
<pitti> slangasek: hm, yesterday it consistently crashed at startup (i. e. I didn't see plymouth at all; just text cursor, and then immediately X/gdm)
<pitti> slangasek: today startup seems to work as well; shutdown has always worked so far, I see plymouth
<slangasek> pitti: hmm, ok
<pitti> slangasek: I only saw it the very first time yesterday when I reinstalled UNE on the mini 10; before that I just upgraded
<pitti> slangasek: hm, now it happens again; the difference is that I plugged in the AC
<pitti> it might speed up the boot just enough to make a difference in a race condition..
<slangasek> yes
<slangasek> now, not seeing plymouth may be bug #540801
<ubottu> Launchpad bug 540801 in plymouth "X server starts before Plymouth, or a very short time after (no or brief splash)" [Low,Triaged] https://launchpad.net/bugs/540801
<slangasek> but maybe that's a precondition of this bug
<pitti> (in my bootcharts I noticed that booting on battery is quite a bit slower, presumably due to CPU scaling down?)
<slangasek> I don't know what would scale the CPU down at that point
<pitti> slangasek: I can remove the .crash file and see if I get it again
<pitti> I just wondered yesterday why plymouth was gone (it has worked fine for weeks on the mini), but with the crash it's quite obvious why I don't see it
<slangasek> not obvious to me
<pitti> slangasek: well, plymouthd segfault -> no plymouth on screen?
<slangasek> why would plymouthd segfault that early? :)
<slangasek> it's not a 100% reproducible crash
<pitti> hm, indeed; I didn't see plymouth now, but no .crash file
<pitti> perhaps apport was started too late, or it didn't crash
<pitti> but anyway, I booted 6 times in a row and never saw plymouth
<pitti> (on startup)
 * pitti -> late lunch
<dholbach> Packaging Training session in #ubuntu-classroom with geser in 10 mins: Q&A about the Developer Membership Board
<seb128> slangasek, pitti: I get similar plymouth crashes on my mini too
<seb128> hum
<seb128> does anybody know how far we are from having another langpack installed on the CD?
<seb128> the directfb upstream changelog sneaked back in with the dh7 switch
<seb128> which is over one meg
<seb128> the package also has both gziped and ungziped versions of changelogs
<seb128> there is some space win to do there, but not sure if that's worth chassing that now
<seb128> ie if we will not use the space for anything else in lucid...
<cjwatson> don't know how far we are, but 1MB sounds worth saving
<seb128> seems we have also several times the openoffice changelog which is 1meg gzip-ed
<seb128> ie openoffice.org-style-galaxy openoffice.org-l10n-common openoffice.org-core
<seb128> they have the same upstream changelog
<seb128> cjwatson, k, I will fix the directfb one
<seb128> I don't fancy looking to openoffice though :p
<seb128> ccheney, ^ do you know if that would easy to change?
<seb128> hum
<seb128> I'm wondering if there is a debhelper bug there
<seb128> some packages have a ChangeLog.gz and changelog.gz identical installed
<seb128> but upstream has only ChangeLog.gz
<lifeless> I bet there is a .docs file lsiting ChangeLog
<lifeless> and debhelper is grabbing ChangeLog as changelog as a built in default
<cjwatson> agree
<cjwatson> debhelper >= 7.0.1 has defaults for upstream changelog
<cjwatson> so it's just that some package failed to notice the change
<cjwatson> (this isn't done in compat=6 and below)
<seb128> hum k
<seb128> "rules:	dh_installchangelogs -plibdirectfb-dev ChangeLog"
<seb128> directfb has that for example
<cjwatson> right, just remove ChangeLog probably
<seb128> well we add that as the "move the upstream changelog to the libdev"
<seb128> but debian changed to dh7 meanwhile so we have
<seb128> dh_installchangelogs
<seb128> dh_installchangelogs -Nlibdirectfb-dev
<seb128> dh_installchangelogs -plibdirectfb-dev ChangeLog
<seb128> I'm not even sure what the intend was with the -N
<seb128> shouldn't we just -XChangeLog in -plibdirectfb-...?
<cjwatson> TBH, you could now just say dh_installchangelogs and leave it at that, if you build-depend on at least debhelper (>= 7.0.1)
<cjwatson> or at least I'm pretty sure
<seb128> well it would install the upstream changelog in the lib then?
<cjwatson> oh, right
<cjwatson> it does it for the "main package", whatever's first in debian/control
<cjwatson> but that's overridable
<cjwatson> dh_installchangelogs --mainpackage=libdirectfb-dev
<cjwatson> try that?
<seb128> will do
<seb128> I've to figure how dh7 do overwritting first :p
<seb128> right now it just add extra calls
<seb128> so we get the dh7 dh_installchangelogs + the ones we added
<cjwatson> overrides in dh7 are only relevant if you're using dh(1)
<cjwatson> is directfb doing that?
<seb128>         dh --with quilt $@
<seb128> it uses
<cjwatson> hm, the import is out of date
<seb128> I guess I want to add some
<cjwatson> then:
<cjwatson> override_dh_installchangelogs:
<seb128> override_dh_installchangelogs:
<cjwatson>         dh_installchangelogs --mainpackage=libdirectfb-dev
<seb128> right, thanks
<seb128> trying that now
<seb128> next I look at why gtk2 has duplicates changelos too
<seb128> it uses debhelper 5
<kirkland> cjwatson: hi there ... question about the eucalyptus-* tasks in the ubuntu-lucid seeds
<cjwatson> kirkland: yu
<cjwatson> p
<kirkland> cjwatson: ttx and I were surprised to notice that they're not a proper superset of ubuntu-server
<cjwatson> is that important in any way?
<kirkland> cjwatson: ttx: ie, stuff like vim and screen aren't included
<kirkland> cjwatson: consistency
<cjwatson> I would have thought that the appropriate response would be to install the server task as well
<ttx> cjwatson: ah, interesting point.
<ttx> cjwatson: but the UEC installer doesn't give you that option
<lamont> I'd just like to shoot debian-installer / hardy-proposed.  Trying to remember what the fix was so that it would actually build on sparc
<cjwatson> I don't think task supersets are really the right way to do this; they introduce quite a bit of clutter into Packages and are less visible
<cjwatson> ttx: it would be trivial to make eucalyptus-udeb just always include the server task, if that's what you wanted
<ttx> cjwatson: I'm slightly worried about the timing, but apart from landscape-common, I can't see anything potentially harmful in there
<cjwatson> http://paste.ubuntu.com/411040/ or similar
<ttx> cjwatson: with your release team hat on, do you see potential trouble ?
<ttx> I'm ok with having those packages in... just wished we would have done that pre-beta :)
<kirkland> ttx: I agree -- I'd like to see an UEC install have Ubuntu Server + Euca-stuff
<ttx> cjwatson: that would add patch, screen, landscape-common, vim, apport, w3m and ubuntu-serverguide
<cjwatson> ttx: it seems OK to me; didn't we go to some effort to ensure that landscape-common was harmless by default?
<ttx> cjwatson: that's the key idea, yes.
<ttx> kirkland: ok, so please back out the addition of "screen" in the seeds, and locally test the change cjwatson pastebinned
<ttx> ..and if successful, upload a euca with that as soon as we unfreeze
<kirkland> ttx: will test
<slangasek> tseliot: have you looked into bug #552782 yet?  if not, I'm going to have a look
<ubottu> Launchpad bug 552782 in fglrx-installer "package fglrx (not installed) failed to install/upgrade: dpkg-divert: mismatch on package" [High,Triaged] https://launchpad.net/bugs/552782
<slangasek> (should be fairly easy to fix, though I'm pulling the package history to make sure we don't overlook any cases)
<tseliot> slangasek: I'm fixing a bunch of fglrx bugs today but I haven't worked on that yet. Help is always welcome ;)
<slangasek> ok
<slangasek> tseliot: is there a bzr branch for the package, do you work off lp:ubuntu/fglrx-installer directly, ...?  No Vcs-* fields in debian/control
<tseliot> slangasek: I work on this git master branch: http://www.phorogit.com/index.php?p=fglrx-packaging.git
<tseliot> which is also what upstream use so that my changes end up in their installer
<slangasek> tseliot: ah
<slangasek> tseliot: well, the package bzr is taking enough time to download, so for right now you'll just be getting patches against that. :)
<tseliot> slangasek: sounds good :-)
<tseliot> slangasek: in git we only have packaging scripts, so installers or blobs of any kind
<tseliot> s/so/no/
 * slangasek nods
<tseliot> so it might actually be faster to get that. Either way it's fine
<slangasek> faster to get it, but certain to take me longer to inspect the history <shrug> :)
<u-foka> Hy! After todays upgrade and reboot, I noticed that my system freezes with kernel panic imediately after I start empaty :( I can check my mail, ot surf the web without problems, but when I start empathy it freezes... but after I start with the older (18) kernel the problem disappears...
<u-foka> I will look around launchpad if that bug is already reported or not, but I wanted to inform you quickly because it seems to be hard regression
<u-foka> well it looks like Bug #495577 but that reported on karmic four months ago...
<ubottu> Launchpad bug 495577 in linux "empathy cause kernel-panic when executed" [Undecided,New] https://launchpad.net/bugs/495577
<u-foka> strange
<u-foka> anyone?
<slangasek> u-foka: "kernel panic" is far too generic for us to comment meaningfully; you should file a bug report showing /where/ the kernel panics
<u-foka> slangasek, but how to track that down, I'm locked inside X with the blinking num+capslock leds... If I was enough fast, I can go to a console before the kernel freezes and can read the end of the message
<u-foka> there is any way to get the full error, or I have to get a higher res terminal and take a photo of the error? 8-)
<slangasek> u-foka: switch to console, and launch empathy with 'DISPLAY=:0.0 empathy'?
<kusum> Could somebody explain me the lines in preseed.cfg file in wubi , please
<slangasek> u-foka: but yes, if the panic scrolls off your screen, you either need a higher-res console setting or to use a serial console to capture it
<u-foka> slangasek, yeah, and then how to save the error?
<slangasek> u-foka: a photo is a good start
<u-foka> okay
<u-foka> I'l be back in some minutes
<slangasek> or transcribing by hand - whichever is easier for you...
<ArneGoetje> mvo: confirmed
<mvo> ArneGoetje: I fixed it in the meantime
<mvo> ArneGoetje: no worries, thanks for verifiying
<ArneGoetje> mvo: ok
<slangasek> tseliot: patch posted to the bug
<nigelb> crimsun, I know its smack in the middle of a working week, but if you could spare one hour, would be great :)
<hdon> hi all. i have a really weird situation, not really a problem right now, but i don't understand how this is happening... http://pastebin.mozilla.org/713743
<slangasek> tseliot: what else are you working on for fglrx today?  Can we get that particular fix into the queue today, so it's available for people upgrading immediately post-beta?
<hdon> so it appears that SOCK_STREAM is surviving gcc -E without being substituted
<hdon> but if i compile (no -E) then it gets substituted, apparently
<slangasek> hdon: because SOCK_STREAM is an enum, not a #define; but I don't see how this is related to Ubuntu development?
<hdon> oh!
<hdon> thanks
 * hdon sleazes his way out the door
<cjwatson> kusum: please don't do this thing of asking the same question in multiple channels.  it's quite annoying for those of us who follow those multiple channels
<tseliot> slangasek: I have fixed 538071, 556653 and I'm almost done with 552903
<slangasek> tseliot: ok, cool
<u-foka> hy again! slangasek! Sorry, I found that not any update, but vmware-workstation, that I installed today, and it's vmnet module caused the problem..
<u-foka> it's still strange why only empathy was affected
<u-foka> but it seems it affected only the latest kernel because the module was only compiled for that
<slangasek> heh
<slangasek> well, now you know where to file the bug, anyway :)
<u-foka> yeah
<u-foka> thanks :)
 * apachelogger enters crying the channel
<apachelogger> dholbach: me@osiris:~/src/bzr$ get-branches kubuntu-members
<apachelogger> The team 'kubuntu-members' does not have any branches on Launchpad.
<dholbach> apachelogger: I didn't touch the script in years
<apachelogger> omg :(
<apachelogger> jpds: ^
<dholbach> apachelogger: I haven't had the need to use it for ages
<apachelogger> dholbach: I figured it could be useful for kubuntu since we have a billion branches associated with kubuntu-members
<dholbach> apachelogger: I usually just check out whatever I'm going to need next :)
<soren> apachelogger: I have a patch that fixes it.
<soren> apachelogger: ...almost.
<soren> Heh.
<soren> Hang on :)
<apachelogger> ^^
<dholbach> apachelogger: last rev I made changes to it: 18.3.5
<dholbach> apachelogger: since then: rainct, jpds :)
<apachelogger> k :)
<slangasek> seb128: can you tell me if bug #539951 is a regression?
<ubottu> Launchpad bug 539951 in xdg-user-dirs-gtk "[Lucid Beta2] Automatic folder renaming when changing language doesn't work as expected" [Medium,Confirmed] https://launchpad.net/bugs/539951
<seb128> slangasek, seems bug #486929
<ubottu> Launchpad bug 486929 in ubuntu-translations "Special user folders not moved when changing language" [Medium,Confirmed] https://launchpad.net/bugs/486929
<seb128> slangasek, not new no
<asac> doko_: is icedtea6-plugin supposed to work?
<slangasek> seb128: thanks, duping
<seb128> slangasek, yw ;-)
<doko_> asac: 556549
<asac> doko_: hmm. thats the reason why example applets dont work?
<asac> even if they dont touch security stuff?
<doko_> asac: the example applet should work, and it does work for me
<micahg> doko_: which applet are you using?
<ccheney> seb128: i'll take a look and see, we have code that is supposed to keep the duplication from happening but it seems to be broken for openoffice.org-style-galaxy, shouldn't be too hard to fix
<ccheney> seb128: and actually for openoffice.org-style-galaxy i'm not sure why it is even on the cd since the only rdepends is openoffice.org which is not supposed to be on the cd
<doko_> micahg: http://www.java.com/en/download/help/testvm.xml
<ccheney> seb128: if openoffice.org-style-galaxy really is on the cd that is a bug somewhere with the cds most likely and would free space on its own
<seb128> ccheney, no sure I was typing on an another box than the one I was installing on
<ccheney> seb128: ok
<seb128> ccheney, it's -human on the CD but it has the changelog too
<ccheney> seb128: and for -human the dir is a symlink
<ccheney> pointing to openoffice.org-common dir
<seb128> right
<seb128> so it's -common -core - l10n-common
<slangasek> ccheney: other than the fact that we keep ending up with openoffice.org-style-galaxy Provides: openoffice.org-style-default?
<seb128> those are real dirs and have the same 1meg changelog
<micahg> doko_: weird, wfm now too :)
<ccheney> slangasek: yea galaxy is bugged and if it is hitting the cd i need to fix that if its a bug in OOo packaging
<seb128> ccheney, uno-libs3 seems to have the same one too
<slangasek> ccheney: yes, this is a repeat of a previous packaging bug - which style was supposed to be the default?
<slangasek> ccheney: anyway, -common depends on -style-default | -style, and -style-default is the obviously-correct virtual package name; so it's just that it's being provided by the wrong package
<slangasek> ccheney: however, I don't actually see -style-galaxy being pulled into the CDs; this is only going to be an issue when installing OOo from the network (but it *will* be an issue there)
<ccheney> slangasek: all of the style packages provide openoffice.org-style
<slangasek> ccheney: it's not about -style, it's about -style-default
<ccheney> slangasek: and depending on if you install openoffice.org-kde or openoffice.org-gnome it installs a openoffice.org-style-* package already
<ccheney> slangasek: so is this a apt bug?
<slangasek> ccheney: I don't see a description of the actual problem in my immediate scrollback
<slangasek> ccheney: other than the comments about the CDs, and it's *not* on the CDs
<ccheney> slangasek: ok
<ccheney> seb128: looks like i might need to change all the arch packages to link to uno-libs3 doc dir (due to dependency chain) which would reduce the duplicates for that
<soren> apachelogger: See ubuntu-dev-tools trunk for a fixed get-branches script.
<apachelogger> soren: awesome, thanks \o/
<sebner> apachelogger: huhu :)
<apachelogger> sebner: ahoy
<sebner> huhu sistpoty|work :)
<sistpoty|work> hi sebner
<kirkland> ttx: i tested cjwatson's pastebin'd fix, rolled into a udeb, retrieved and installed early in a UEC install ... works well
<kirkland> ttx: cjwatson: I see no negative effects at this point
<kirkland> ttx: cjwatson: I suggest we commit this as soon as the freeze lifts, and start testing dailies again
<ttx> kirkland: ack
<kirkland> ttx: i'm going to upload it now, to get it into the queue
<maco> cjwatson: ping. is there a reason why udev should "breaks" not "conflicts" with casper? had a user in #ubuntu installing updates yesterday whose dpkg had wedged over it.
<slangasek> maco: because Conflicts are when there are overlapping files between the two packages - how did that wedge dpkg?
 * persia suspects something like policy 7.2 recommending Breaks for most uses that were conflicts pre-Breaks.
<maco> slangasek: its set to breaks currently. user was getting http://ubuntu.pastebin.com/fR5Pn1Ch when trying to update. had to "dpkg -P --force-depends casper" as the only way to get dpkg into a sane state
<maco> slangasek: crimsun said breaks goes into effect during the dpkg part, so if it had been breaks instead, apt wouldve caught it and not let it get so far and get stuck.  by stuck i mean it tells you "sudo dpkg --configure -a" and so you try that and then it just does the same thing again
<maco> slangasek: er... "if it had conflicts instead"
<slangasek> maco: casper 1.57 is the version from dapper - I think the user is Doing It Wrong
<maco> slangasek: oh O_O
<maco> how the heck did they.....
<slangasek> maco: the problem there is probably that they used an apt that doesn't understand Breaks
<slangasek> which was first added in edgy
<maco> udev version matches karmic
<maco> well karmic-updates
<maco> ok yeah ill agree with Doin It Wrong
<cjwatson> yeah, no sympathy :)
<maco> i suspect there is some howto for remastersys on the interwebs that instead of saying "use apt" hands out old old old dapper casper packages
<slangasek> hand-installing the wrong casper package would also cause the problem, sure
<maco> i just memoserv'd the person to tell them that
<ScottK> maco: Better a blog posting that names names.
<LaserJock> ScottK: public "peer" review? :-)
<ScottK> Exactly.
<tseliot> slangasek: I have fixed all of the bugs that I mentioned but the one you volunteered to have a look at. What shall I do? Upload?
<slangasek> tseliot: you should take my patch from that bug report, apply it, and then upload :)
<slangasek> tseliot: (in a manner consistent with the FeatureFreeze, that is)
<tseliot> slangasek: there's no patch from you there
<slangasek> tseliot: https://bugs.launchpad.net/ubuntu/+source/fglrx-installer/+bug/552782/comments/6 ?
<ubottu> Launchpad bug 552782 in fglrx-installer "package fglrx (not installed) failed to install/upgrade: dpkg-divert: mismatch on package" [High,Triaged]
<tseliot> slangasek: oh, sorry I was looking at bug 554298 (which is a duplicate)
<ubottu> Launchpad bug 554298 in fglrx-installer "installation of fglrx 8.721 fails when removing a diversion on libdri.so" [High,In progress] https://launchpad.net/bugs/554298
<tseliot> slangasek: we haven't added any diversions in the package in lucid, therefore I think I will just replace $PKGNAME with xorg-driver-fglrx in all of the lines in the preinst script instead of affecting only the line that you modified
<slangasek> tseliot: ok; I was being conservative since the bug people were reporting was about the very last diversion in the list which means the others weren't causing failures, but if none of these were ever in the fglrx package, I agree that's more appropriate
 * tseliot nods
<tseliot> slangasek: thanks a lot for spotting the problem
<slangasek> n/p
<kees> pitti: does gwibber zero it's passwords when it's done with them?
<pitti> kees: Nafai and I just finished a commit to mlock() them
<pitti> kees: but in Python you can't zero a string, they are immutable :/
 * kees wonders if the mlock ulimit is per-process or per-user
<pitti> kees: per session, I thought?
<pitti> kees: but anyway, a handful of passwords shouldn't get anywhere near the shm limit?
<tkamppeter> pitti, I have a problem with system-config-printer: Back in February when I wanted to take a 1.1.x GIT snapshot I have accidentally taken a 1.2.x GIT snapshot, but assigned 1.1.x version numbers to the package, not knowing that I am using an unstable test release.
<kees> pitti: it shouldn't but it should gracefully not die if mlock fails.
<tkamppeter> pitti, what should I do, advance to 1.2.0+HEAD, as this is the stable release with first bug fixes? Especially this instable release caused bug #555213.
<ubottu> Launchpad bug 555213 in hundredpapercuts "Make printer jobs viewer HIG compliant" [Low,Confirmed] https://launchpad.net/bugs/555213
<pitti> kees: it doesn't currently
<pitti> tkamppeter: depends on which direction is safer and less intrusive at this point
<pitti> tkamppeter: if it's just a couple of bug fixes towards 1.2.0 final, I'd do that one
<pitti> tkamppeter: if it was an early snapshot with not too many changes from 1.1, go bacak
<pitti> kees: it's using ctypes, so it won't except out; it just returns with -1
<davidm>  /msg akgraner how much of a disaster is it if I can't make SELF until Saturday morning? Was reminded by Debra she wants to go to Phoenix AZ from June 4th - June 12th?
<tkamppeter> pitti, thanks, I have asked Tim now.
<tseliot> slangasek: ok, committed to git and uploaded to lucid. Thanks again for your help
<nemo> huh
<nemo> W:Failed to fetch http://www.ksplice.com/apt/dists/lucid/ksplice/binary-amd64/Packages.gz  404  Not Found
<nemo> , W:Failed to fetch http://www.ksplice.com/apt/dists/lucid/ksplice/source/Sources.gz  404  Not Found
<nemo> , E:Some index files failed to download, they have been ignored, or old ones used instead.
<nemo> that's a bit odd
<nemo> I mean, I guess I can remove ksplice, but isn't typical for an upgrade to abort just due to missing packages
<cjwatson> that's not missing packages, it's missing package indexes, which is a different matter
<cjwatson> it doesn't abort either
<cjwatson> it's an error, but you can proceed with upgrades of packages not in those package indexes
<nemo> it didn't give me an option to procede
<nemo> it simply exited
<nemo> so I assume I have to manually remote ksplice
<cjwatson> "it"?  I assume you're talking about some frontend.
<nemo> cjwatson: upgrade-manager
<nemo> er
<nemo> update-manager
<nemo> the dist upgrade tool that is
<cjwatson> that's an error from 'apt-get update'.  Perhaps update-manager should tolerate it better somehow, I'm not sure.  Frontends that give you more control will let you proceed
<cjwatson> I can understand why it aborts though.  Entire missing repositories can have fairly significant effects on the correctness of an upgrade.
<pitti> cjwatson: would you have some time to accept the postgresql-* SRUs in unapproved? (bug 557408) or shall I accept them myself?
<ubottu> Launchpad bug 557408 in postgresql-8.3 "New upstream microreleases: 8.4.3, 8.3.10, 8.1.20" [Medium,In progress] https://launchpad.net/bugs/557408
<pitti> cjwatson: nevermind if you are busy with release tasks, it's not that urgent
<cjwatson> I'm not
<nemo> cjwatson: well. no big deal, wasn't like ksplice was critical. was just cool to play with
<MacSlow> ev, hey there
<ev> hiya
<MacSlow> mvo_, hey there
<MacSlow> ev, mvo_: I was wondering if anyone of you could tell me how to get a proper screenshot into the info-page of notify-osd inside software-center. Thanks in advance!
<cjwatson> pitti: done
<philsf> apport-collect is crashing on me http://paste.ubuntu.com/411195/ is this the right channel to ask about this?
<jdong> what would be the cause of dbus-monitor --system revealing spammy events that look like signal sender=org.freedesktop.DBus -> dest=(null destination) serial=913 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=NameOwnerChanged
<jdong> (several per second, 30% of CPU usage in system constantly)
<chrisccoulson> jdong, an application constantly restarting/terminating probably
<ScottK> slangasek: Still not having a great Plymouth transition on KDE: http://people.ubuntu.com/~apachelogger/screencasts/plymouth-uglyness.ogv any suggestions?
<jdong> chrisccoulson: ah. Seems like pulseaudio's PID keeps climbing by hundreds
<chrisccoulson> jdong, that will be it then ;)
<jdong> fun fun fun
<jdong> any hints on debugging that?
<chrisccoulson> heh
<chrisccoulson> i'm probably not the best person to ask about pulseaudio
<chrisccoulson> but crimsun might be able to help ;)
<jdong> indicator-sound-service seems to be using a couple percent of CPU constantly
* slangasek changed the topic of #ubuntu-devel to: Lucid Beta 2 released | Archive: feature freeze | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for dapper-karmic | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs
<slangasek> ScottK: hold that thought
<ScottK> OK.  Holding.
<nemo> anyone else have appearance preferences hang after switching to compiz?
<nemo> mine's been just sitting there, unresponsive, even though compiz seems to be working fine
<nemo> hung immediately after I clicked "keep settings"
<jdong> a lot of clone() -> wait4() looping
<nemo> doesn't seem to actually be doing anything though
<jdong> killing it with SIGSTOP stops the CPU usage
<jdong> ok, who do I whine about indicator-sound-service to?
<robbiew> \o/
<robbiew> we released on the right day this time :P
<robbiew> heh
<robbiew> nice work people
<jdong> well... removing the volume applet thing seemed to have helped
<nemo> hm. nothing obvious in xsession-errors
<nemo> nor strace or lsof
<nemo> gdb bt says it is hanging in theme_thumbnail_factory_init
<nemo> oh well
 * nemo kills it
<micahg> slangasek: should something be added to the release notes from beta 2 that the Firefox search engine will be changed back to Google?
<slangasek> ScottK, apachelogger: that video looks like a plymouth crash bug to me; any apport naggings afterwards?
 * ScottK looks at apachelogger.
<apachelogger> slangasek: apport reports are in /var/crash, right?
<slangasek> yep
<apachelogger> nothing then :(
<slangasek> ok
<ScottK> apachelogger: So not our fault.
<seb128> slangasek, hey, are we unfrozen? ie can I do syncs?
<slangasek> you can do syncs, yes
<seb128> thanks
<slangasek> we're not completely unfrozen yet, there are some things in the queue that I want to eyeball before letting them in
<seb128> slangasek, ok
<slangasek> pitti: tzdata's not in the freeze queue for lucid?
#ubuntu-devel 2010-04-09
<thiblahute> Hi, I am trying to make ubuntuone working since I upgraded like 1 month ago, but impossible. Here is the status, it is always like it  http://pastebin.com/utw1pewf
<jpds> thiblahute: Try: #ubuntuone
<thiblahute> jpds: Thanks will go see there!
<crypt-0> is Lucid stable enough to build packages on?
<lifeless> crypt-0: I'd surely hope so:)
<psusi> that's like asking if air is safe to breathe... if it weren't you wouldn't be there to ask the question ;)
<crypt-0> what i meant is am i likely to encounter any bugs that i wouldn't with lets say 9.10 while making a package
<RAOF> Lucid has been *extensively* tested for building packages on :)
<jdong> lol that's probably its most tested usecase ;-)
<crypt-0> and the wiki for creating them?
<jdong> and for me, apport's report dialog is very extensively tested too *grumble grumble grumble* ;-)
<crypt-0> and can u just use diff to make the patch?
<GrueMaster> crimsun: around?  Any new ideas on bug 528524?
<ubottu> Launchpad bug 528524 in speex "Sound not working in all apps through pulse on arm" [High,Confirmed] https://launchpad.net/bugs/528524
<crypt-0> since lucid is in a freeze will it make much difference oh how soon i get my package in?
<crypt-0> IIRC using release candidate cryptography software that is in the *main* reops and is the core package for disk encryption is a bad idea
<psusi> wow.... adding the largefile4 profile to ext4 on mke2fs to reduce the number of inodes on a 1.5 tb drive added almost 22 gb of usable space that otherwise would have been consumed by inodes
<psusi> ( and would have to be written to during mkfs without lazy_itable_init )
<psusi> say, didn't we used to have apps on the system menu by default to manage the gnome keyring, and to configure remote vnc access?  what happened to those?
<micahg> directhex: around?
<twb> What does the BC in XSBC-Original-Maintainer stand for?
<ebroder> XSBC refers to where to put the field. S means .dsc, B means .deb, C means .changes
<twb> Ooooh.
<ebroder> Err, well, let me start over. The "X-" means "dpkg, you don't know about this field, but don't barf and deal with it anyway"
<twb> (I'd only ever seen the old XS-VCS-* before it lots the XS)
<ScottK> S = Source and B = Binary.
<twb> The X- is obviously an RFC822 convention.
<ebroder> For fields dpkg knows about, it also knows where to put them, but for fields it doesn't know about, you have to tell it
<pitti> Good morning
<pitti> slangasek: no, I'll sync it from Debian
<pitti> oh, we are still frozen?
<RAOF> Argh.  Whoops!  Could I have an archive admin sync gnome-keyring-sharp for me?  Bug #557038
<ubottu> Launchpad bug 557038 in gnome-keyring-sharp "Sync gnome-keyring-sharp 1.0.0-3 (main) from Debian sid (main)" [High,Confirmed] https://launchpad.net/bugs/557038
<ScottK> pitti: We are, but slangasek told seb128 he could go ahead with syns.
<ScottK> syns/syncs
<pitti> ah, great; then I'll do a few, thanks
<ScottK> He said there were some things in the queue he still wanted to look at.
<ScottK> pitti: It'd be great if you could do Bug 558933 as one of them.  It'll help with NBS and it needs binary New and then another sync after ...
<ubottu> Launchpad bug 558933 in libqinfinity "Please sync libqinfinity 1.0~beta5-1 from Debian unstable (main) to Lucid (universe)" [Medium,Confirmed] https://launchpad.net/bugs/558933
<ebroder> pitti: If you're already doing syncs, could you look at bug #555620? :)
<ubottu> Launchpad bug 555620 in openafs "[FFe] Please sync openafs 1.4.12+dfsg-3 (universe) from Debian unstable (main)" [Medium,New] https://launchpad.net/bugs/555620
<ScottK> ebroder: That one isn't approved yet.
<ScottK> He's doing the syncing, not reviewing candidates.
<dholbach> good morning
<damascene> hello, I've sent a message to ubuntu-devel-discussion but got spam problem
<pitti> ScottK: done
<damascene> https://wiki.ubuntu.com/Mlterm
<damascene> the link is about the subject
<damascene>  pitti , I've been told you can help, message title was Mlterm installed with RTL languages
<damascene> may you help me?
<pitti> damascene: I have no idea about either of those, I'm afraid
<damascene> pitti, you can't help with the mail list nor with mlterm install for rtl languages?
<pitti> damascene: what's with the ML? what did you try to do?
<pitti> damascene: are you subscribed to ubuntu-devel-discussion?
<pitti> damascene: otherwise you can't send there
 * pitti -> doctor appointment, bbl
<dholbach> can everybody have a quick look at http://qa.ubuntu.com/reports/sponsoring/ and see if there's stuff that should still be going in? I get the feeling there's still a bunch of important fixes on there
<directhex> micahg, i am now
<micahg> directhex: I was about to sign off, but I fixed the using xul 1.9.3. issue and now I get the same results as you that it crashes before launching
<micahg> directhex: I was wondering if there's an easy way to add all the dbg symbols for it as the backtraces are mostly ??
<lifeless> apport-retrace can do that for you, I think
<directhex> is it a managed or unmanaged crash?
<micahg> lifeless: apport's not catching this
<micahg> directhex: when I launch ./foo.exe it shows me  a backtrace and crashes
<directhex> can i see the output? sounds unmanaged, so a ddeb would do the job
<micahg> directhex: http://pastebin.com/e3vk3vsj
<directhex> actually, i have an idea
<directhex> hm, trying to grab upstream, she's usually awake by now
 * micahg is normally asleep by now :)
<joaopinto> mvo, I am getting the wrong message on update manager during partial upgrades, on my translation, is it likely to be a translation error, or there could be something else picking the wrong string ?
<joaopinto> When it should display "Downloading packages" it shows "Error while downloading packages", this in portuguese
<mvo> #: ../UpdateManager/DistUpgradeFetcherKDE.py:128
<mvo> #: ../UpdateManager/DistUpgradeFetcherKDE.py:141
<mvo> #: ../UpdateManager/DistUpgradeFetcherKDE.py:143
<mvo> msgid "Downloading additional package files..."
<mvo> msgstr "A descarregar pacotes adicionais..."
<mvo> is what i have here
<joaopinto> that is now what is shown
<mvo> joaopinto: if that is incorrect it needs to be fixed in rosetta
<joaopinto> that one is correct, but that is not what I am getting
<mvo> what is the (translated) message you see?
<directhex> micahg, well, until miguel notices & shouts, she runs ubuntu with a suse theme anyway, so if you can throw your patch somewhere i can ask her to take a look
<joaopinto> "Erro ao transferir os novos pacotes"
<mvo> msgid "Getting new packages"
<mvo> msgstr "Erro ao transferir novos pacotes"
<joaopinto> ouch :P
<mvo> that does not look right
<mvo> :)
<sgnb> can someone here confirm my diagnostic of https://bugs.launchpad.net/ubuntu/+source/ocamlnet/+bug/257524 ?
<ubottu> Launchpad bug 257524 in ocamlnet "ocamlnet library compiled without SHM support" [Undecided,New]
<micahg> directhex: I think all I did was modify the GRE...I'd like to know where it crashes so I can start patching :)
<mvo> joaopinto: do you have the needed privs/group memberships to fix it in rosetta? or will we need a bug against language-pack-pt ?
<joaopinto> I don't deal with translations, I will file a bug, a just hope it lands in time, this bug has been visible for months so I guess there isn't much activity on the pt translation team
<joaopinto> unless they did like me and forgot to report it :P
<mvo> what is the correct translation?
<joaopinto> "Transferindo novos pacotes"
<joaopinto> hum, maybe I should check other strings, "Obtendo" instead of "Transferindo" would be a better verb
<joaopinto> can you show me some other "get package" string ?
<mvo> https://translations.edge.launchpad.net/ubuntu/lucid/+source/update-manager/+pots/update-manager/pt/+translate?batch=10&show=all&search=Getting+
<mvo> sure :)
<mvo> see above
<micahg> directhex: I have to head to sleep, will you be available in 6-7 hours?
<directhex> micahg, yes
<mvo> joaopinto: noce you have the bugnumber, please let me know and I target it to lucid
<hunger> My netbook edition box started to "flicker" after rebooting today (last upgrade yesterday). Looks like some window is covering the whole screen, gets killed, starts again, ... after logging in. Is that a known issue or did I break something myself yesterday? It did not do this yesterday evening.
<hunger> Must be something in the startup scripts... Maximus is not there, the ubuntu logo does not trigger the app start view and Alt-F2 does not work either:-(
<joaopinto> mvo, done, bug 559018
<ubottu> Launchpad bug 559018 in language-pack-pt "Wrong translation for "Getting new packages" on update-manager" [Undecided,New] https://launchpad.net/bugs/559018
<mvo> thanks joaopinto
<joaopinto> I am going to send a mail to the ubuntu pt ml, there should be someone from translation there
<slangasek> mvo: what's the status of bug #552542?  was that fixed for beta-2?
<ubottu> Launchpad bug 552542 in apt "DDTP translation strings breakage in Japanese(ja)/Simplified Chinese(zh_CN)/ Traditional Chinese(zh_TW)" [High,Fix committed] https://launchpad.net/bugs/552542
<seb128> slangasek, hey, do you review each uploaded queue during the freeze before accepting those?
<mvo> slangasek: fixed with subject: [ubuntu/lucid] translations_main_20100408.tar.gz - (Accepted)
<mvo> slangasek: so it should be in the archive and fixed now, I updated the bug
<slangasek> seb128: at least briefly; some people have been uploading packages to the queue assuming that FFe review will happen there, which is not what's *supposed* to be done, but better to spot these than to leave people thinking there was an FFe when there wasn't
<slangasek> mvo: great, thanks
<seb128> slangasek, is there anything we can do to avoid having things landing on tonight and break while everybody is away like it happened for beta1?
<slangasek> seb128: the queue isn't frozen now
<seb128> ok, I note for next time to not upload during freezes but queue locally and upload after
<seb128> thanks
<mvo> seb128: was a new gnome uploaded during the freeze? I assume it is, I get some upgrade calculcation errors that look transient to me
<seb128> mvo, not a new GNOME but quite some updates yes
<seb128> I was counting on the queue to be flushed after beta2 yesterday so things could build overnight and be tested today
<seb128> but instead seems queue is slowly reviewed and things will land again in time to break when everybody is in weekend
<seb128> *shrug*
<seb128> sorry for the rant, it's pretty annoying
<seb128> mvo, you shouldn't have too many errors, at least on i386
<mvo> seb128: its a bit unfortunate indeed. I will just wait a bit and see if the upgrader is more happy in ~2h or so
<mvo> seb128: heh :) one error is enough ;)
<seb128> mvo, other archs might hit arch all,any mismatch in gtk
<mvo> seb128: maybe its something new, I just don't want to start debugging to figure out its transient
<seb128> mvo, ok, so wait a few hours and try again before looking at the issue
<mvo> thanks seb128
<seb128> pitti, btw did you raise the unfreeze time and beta1 breakage at r-t meeting for discussion?
<seb128> pitti, we mentioned it early next week but I didn't follow up on that
<pitti> seb128: we discussed it during the meeting, but the "postpone thawing to Monday" strawman didn't find much agreement
<seb128> can you raise it again today?
<seb128> cf backlog there
<pitti> since it would just lead to more jamming
<seb128> this over half a day delay for nothing put us in the same situation
<pitti> seb128: but this time we thawed much earlier
<seb128> can we work on a way to avoid that?
<seb128> pitti, well, ideally we would have flushed the queue and would be testing things today
<seb128> pitti, but half of things are still blocked for no visible reason and time they are built will lead to after end of week...
<pitti> seb128: slangasek still wanted to look at some things in the queue; but I accepted some "obvious" ones, and I'll do some further cleanup
<seb128> bah
<seb128> pitti, thanks, still it puts us half a day later with build which should have happened over night and updates be tested now...
<pitti> right :/
<seb128> pitti, I just note to not upload during freezes again
<seb128> I will queue locally and upload when we unfreeze from now on
<seb128> so at least things go through when they should
 * hunger mumbles that the opensync-syncml plugin is not installable on lucid.
<seb128> I still would like to see the issue raised during the meeting today
<seb128> pitti, ^
<pitti> seb128: ok, can do
<seb128> thanks
<slangasek> pitti: this system-config-printer looks to me like it's missing an FFe; could you follow up on this with tkamppeter today?
<pitti> slangasek: we discussed that yesterday
<slangasek> pitti: ah, so it had an off-line FFe? :)
<pitti> slangasek: so although our current package says 1.1.17+, it's actually 1.2.0~git...
<pitti> slangasek: (git pull from wrong branch)
<slangasek> yeah, read the bug report
<pitti> slangasek: so I asked him in which direction the delta was smaller, towards 1.2.0 final or back to 1.1.17
<pitti> slangasek: I didn't give a blanket FFE, no
<pitti> but I'm happy to review the pacakge and see whether there's new features or UI changes, or just bug fixes
<slangasek> ok, thanks
<slangasek> aside from that one, the queue is now flushed
<seb128> slangasek, thanks
 * wgrant prepares to wake up to a broken world tomorrow morning :P
<pitti> slangasek: I went through the diff, it's not actually that big; couple of bug fixes and translation updates; the only thing that can be regarded as UIF/FF is bug 542975
<ubottu> Launchpad bug 542975 in system-config-printer "Lucid Beta 1 - Printer test page should display new Ubuntu logo" [Medium,In progress] https://launchpad.net/bugs/542975
<pitti> slangasek: (i. e. changing the printer test page to the Ubuntu one)
<pitti> slangasek: if that's alright with you (fine for me), I'll accept it
<slangasek> pitti: yes, go ahead
<sebner> pitti: regarding your poll about syncing from testing was right. I'm curious how many syncs after DIF were processed and how many of them were from unstable :)
<slangasek> if the docs team is putting photos of the printer test page in their docs, they have too much time on their hands ;)
<pitti> heh
<pitti> sebner: uh, interesting question; not sure whether it's possible to answer that
<pitti>  I don't think LP records the origin of a sync anywhere
<pitti> sync-source.py is by and large "download from debian, craft a _source.changes, upload"
<pitti> sebner: you could count the "Fix released" sync request bugs, though
<sebner> pitti: oh, kk. I just have the feeling that most of the syncs where from from Unstable after DIF which means we could sync from Unstable
<pitti> sebner: well, I'd fully expect most manual sync requests to be for unstable
<pitti> after all, the testing ones were already done :)
<pitti> sebner: but a manually requested sync had some human eyes on it, which isn't the same than importing everything wholesale and leaving us with the pieces that break
<apw> anyone know what just got dumped on the PPA buildds ?
<apw> amd64	10	 9104 jobs (four days)
<apw> i386	12	 16358 jobs (four days)
<apw> lpia	7	 2 jobs (31 minutes)
<apw> rebuild test?
<slangasek> apw: yes
<primes2h> tkamppeter: Hello, thanks a lot for the fix (s-c-p). Will new pot/po be imported automatically in Launchpad now?
<cjwatson> pitti: sync-source shoves in an Origin field that might be Debian/testing, Debian/unstable, etc.
<cjwatson> so it should be possible to mine that data
<damascene> pitti, I'm subscribed yes
<exco> unmounting a USB drive also removes it from /dev (e.g. /dev/sdc) ... bug or feature?
<pitti> exco: I'm sure what you actually did was to eject it
<pitti> exco: "umount /dev/sdb1" wouldn't remove it, but the nautilus eject symbol is meant to remove the entire device, yes
<pitti> (or "safe removal")
<apw> slangasek, dare i ask what time it is for you
<slangasek> apw: what's the worst that could happen if you did? :)
<apw> slangasek, heh ... i might find you are in london and at my door asking for a bed ?
<apw> (which is covered in test kit)
<slangasek> haha
<slangasek> nope, in Portland
<slangasek> and it's bedtime
<slangasek> so - 'night, all :)
<apw> its been bedtime for some hours ... night
<exco> pitti: yes, you're right. so it's a feature ;-)
<damascene> do I have to cry to make my mail inside any mail-list? I've this problem with ubutnu-desktop too
<damascene> I had to be in there channel for 4 days to get my e-mail message in.
<damascene> *their
<pitti> damascene: well, until you tell us some details about the problem, nobody will be able to help you..
<pitti> "it doesn't work" isn't helpful, since it works for everyone elase
<pitti> "else"
<damascene> pitti, my message was identified as spam 3.7
<damascene> my message to ubuntu-devel-discussions
<pitti> hm, we don't have spam filtering on most lists
<damascene> this is problem 2. the problem 1 described in the message.
<damascene> are  you sure?
<pitti> yes, since I manually weed out the spam on ubuntu-de, ubuntu-devel-announce, and some others
<pitti> damascene: perhaps you can put the full error email somewhere, including headers
<damascene> I can show you about 10 spam replay I got
<pitti> http://paste.ubuntu.com, for example
<damascene> I was going to do it
<damascene> pitti, http://paste.ubuntu.com/411533/
<damascene> and I wonder what do you prefer should I mention your name when I write you a message or not? you do it sometimes and you don't in another
<pitti> damascene: right, so the moderator needs to review/accept it
<pitti> but I'm not an u-d-d moderator
<damascene> well I think it's a general problem. I've tried more than 5 times with ubuntu-desktop I got the same message
<pitti> ev: ^
<pitti> damascene: SpamAssasssin might get confused about the Arabic letters in your name :/
<pitti> damascene: ev is a moderator, he'll get to it
<damascene> ok thanks. if there is Arabic it would be from evolution. my name is written in English in the message
<pitti> damascene: your paste shows quite a lot of Arabic headers, though
<pitti> Which is kind of weird
<pitti> those look like "Received:" headers
<pitti> headers should not be translated into any language..
<damascene> I'm using localize evolution
<pitti> ah, then evo probably just invalidly translate those
<exco> looking at ~80000 open ubuntu bugs and only ~300 per series ... there should be a call for tagging bugs to releases, not?
<pitti> exco: no
<damascene> maybe, I'll check with evolution people
<pitti> exco: moving 1000 new bugs to lucid won't magically create the manpower to actually fix them
<pitti> and would destroy our means to manage the bugs which we want to fix in a particular release
<damascene> by the way do you thing it's acceptable to install mlterm when a user chose to install rtl support, like installing Arabic support for example
<exco> pitti: you're right about the manpower ... though it does give a wrong impression of the state of the OS
<pitti> exco: why?
<pitti> those bugs are open, after all
<pitti> (not that those would give an accurate impression, since many are obsolete, duplicates, no bugs, etc.)
<joaopinto> damascene, are you refering to bug 263822 ?
<ubottu> Launchpad bug 263822 in vte "RTL (right to left) support in terminal (BiDi)" [Low,Triaged] https://launchpad.net/bugs/263822
<damascene> joaopinto, yes
<exco> sure, 300 bugs ... does look a lot better than xxxxxx ;-) ... quantity doesn't say much ofc
<pitti> exco: 300 bugs isn't the number of bugs in lucid that exist
<pitti> it's the bugs which we plan to _fix_ for lucid
<pitti> (well, very roughly anyway)
<exco> I'm atm trying to get some guys interested in Ubuntu here at HP ... UNR is looking quite nice on the slate ;-)
<exco> so maybe that'll one day shift some manpower towards Ubunto *dreaming*
<damascene> pitti, I've saved the message and opened it in gedit. no Arabic there.
<damascene> only evolution showing it translated
<pitti> damascene: ok, thanks
<damascene> for what. sorry for disturbing
<cjwatson> damascene: if you think it's a general problem, #canonical-sysadmin runs lists.ubuntu.com in general
<cjwatson> at best, people here only moderate individual lists
<damascene> ok thanks
<tkamppeter> primes2h, yes, the import of the translations into LP goes automatically AFAIK.
<primes2h> tkamppeter: ok, thanks.
<ev> pitti, damascene: approved
<damascene> ev, thanks
<ogra> pitti, no need to assign bugs to canonical-mobile, the armel bugs should all be subscribed to ubuntu-armel instead
<ogra> pitti, btw, i just filed bug 559144, any idea what to do about Error: command ['lspci', '-vvnn'] failed with exit code 1: pcilib: Cannot open /proc/bus/pci ?
<ubottu> Launchpad bug 559144 in udisks "udisks-part-id crashed with signal 7 in memcpy()" [High,New] https://launchpad.net/bugs/559144
<cjwatson> ogra: another SIGBUS; I see a pattern ...
<ogra> cjwatson, i suspect its the same one ... partman calls udisks-part-id, no ?
<ogra> to determine the partitions
<cjwatson> no, it doesn't
<ogra> i thought i saw udisks-part-id in the syslog
<ogra> uevd-work[921]: 'udisks-part-id /dev/sda1' unexpected exit with status 0x0007
<cjwatson> udisks-part-id is not available in d-i, and therefore partman does not call it
<ogra> ah, thats long before partman
<cjwatson> I am quite certain
<ogra> yeah
<ogra> i got confused because its in the syslog in various places
 * ogra will wait for the in-archive built kernel, all the sigbus could come from building the kernel with codesourcery 
<ogra> thats what you get for using older toolchains :P
<sebner> didrocks: grr, it seems new metacity wants to remove compiz (pretty old our version), who cares for compiz?
<pitti> ogra: hm, /proc not mounted? or doesn't ARM have a pci bus?
<didrocks> sebner: the new compiz package is built and published now
<ogra> pitti, arm doesnt have pci
<ogra> at least not publically exposed
<pitti> ogra: ok, so that part of the package hook is irrelevant then
<didrocks> sebner: (at least on {,fr,us}.archive.ubuntu.com
<pitti> ogra: any chance to get a backtrace for that?
<pitti> ogra: sudo gdb --args /usr/lib/udisks/udisks-daemon --replace
<pitti> then reproduce
<sebner> didrocks: just checked the main mirror though
<ogra> pitti, well, as cjwatson pointed out seems to be a sigbus ... the kernel was cross built, i'll wait for the proper build that should hit the archive later today
<pitti> ogra: ok
<ogra> pitti, partman seems to expose something similar so it might well be kernel caused
<sebner> didrocks: hrm, ok. It's here now :) Thx for the info
<didrocks> sebner: y/w :)
<cjwatson> ogra: alternatively, they do both link to libparted, so it could be a bug there
<ogra> cjwatson, well, we dont see it on other amrel platforms, i'll wait until i have a real kernel before making more noise
<ogra> *armel
<ogra> the kernel binary is built with gcc 4.3 codesourcery while the modules in the squashfs are gcc 4.4 from the archive, that can cause all sort of issues ... new omap kernel sits in the build queue
<DktrKranz> james_w: wrt launchpadlib, I haven't upload privs for it, mind sponsoring it for me? You can branch it from lp:~dktrkranz/ubuntu/lucid/python-launchpadlib/1.6.0
<james_w> not at all
<james_w> propose the merge, request the review from me, and I'll do it after lunch
<DktrKranz> ok
<NCommander> ccheney: ping
<pitti> chrisccoulson, tjaalton: do you have any useful information about bug 507062 already? if not, I'll forward it upstream and dive into the code a bit
<ubottu> Launchpad bug 507062 in libx11 "synaptic assert failure: synaptic: ../../src/xcb_io.c:385: _XAllocID: Assertion `ret != inval_id' failed." [High,Triaged] https://launchpad.net/bugs/507062
<chrisccoulson> pitti - well, it's not a race between threads, as synaptic is not doing any xlib calls outside the main thread
<chrisccoulson> that was my first thought
<pitti> chrisccoulson: this would happen if you call _XAllocID() twice
<pitti> without _XIDHandler() in between
<chrisccoulson> pitti - yeah, that would cause it
<chrisccoulson> but i can't see that happening in synaptic
<pitti> but so far I have no idea why that would happen
<pitti> chrisccoulson: all dupes I looked at went though XCreatePixmap()
<chrisccoulson> pitti - could be a clue ;)
<pitti> chrisccoulson: it affects all kinds of programs, though
<pitti> synaptic just happens to have gotten the master bug
<chrisccoulson> i was going to spend some time to look at it bug haven't got round to it yet
<pitti> chrisccoulson: ok, thanks
<pitti> chrisccoulson: I'll start forwarding it upstream and do some brain dumping then
<lamont> dammit  WTF DOES UPDATE-MOTD KEEP GETTING ALL THOSE DAMN SYMLINJKS
<lamont> when I remove a conffile, it's supposed to STAY GONE
<lamont> kirkland: ^^??
<chrisccoulson> pitti - also, synaptic never calls XInitThreads anyway (and dpy->lock->user_lock_display is a NULL pointer)
<chrisccoulson> iirc from when i ran synaptic in gdb
<kirkland> lamont: i'm having multiple conversations right now; file a bug, assign it to me
<lamont> ta
<lamont> kirkland: which package?
<lamont> meh . update-motd, ofcourse
<kirkland> lamont: which symlink
<kirkland> lamont: there is no update-motd package
<kirkland> lamont: pam handles update-motd now
<lamont> update-motd.d/9*
<kirkland> lamont: other packages drop symlinks into /etc/update-motd.d
<kirkland> lamont: those are probably update-notifier
<lamont> and then I dist-upgrade, and presto, they're all back
<lamont> update-motd package is 3.5-0ubuntu1 in lucid...
<lamont> mind you , it just delivers the directory
<Aquina> I started using Bazaar with launchpad. Can someone tell me whether I makes sense to upload for e.g. a KDevelop-project (directory structure *as is*) or rater create a packages and store them in a ppa? I must admit that I've got no clue about packaging though.
<lamont> ah, that's it - they're not listed as conffiles
<lamont> 559194 assigned
<tjaalton> pitti: yeah please forward upstream, and I'll see that the relevant people are notified
<pitti> tjaalton: I'm at it; thanks
<pitti> tjaalton: freedesktop bug 27552 now, I'll link it
<ubottu> Freedesktop bug 27552 in Lib/other "Lots of processes crash in XCreatePixmap() with _XAllocID: Assertion `ret != inval_id' failed" [Normal,New] http://bugzilla.freedesktop.org/show_bug.cgi?id=27552
<tjaalton> pitti: ok, moved to Lib/Xlib :)
<pitti> tjaalton: hm, did you commit the bug change? still "other" here
<tjaalton> pitti: yep, looks fine here
<cwillu_at_work> trying to rebuild dpkg from apt-get source; debian/rules binary fails with dpkg-shlibdeps: error: no dependency information found for /lib/libc.so.6 (used by debian/dpkg/usr/sbin/install-info).  Is this bogus, or did I forget a step?
<cwillu_at_work> (testing a fix for debian bug #575891, which may have left this system in an inconsistent state re: triggers and such)
<ubottu> Debian bug 575891 in dpkg "dpkg makes wrong assumption about readdir() and lose metadata files with btrfs" [Important,Open] http://bugs.debian.org/575891
<joaopinto> mvo, do you know any python library provide a class to handle debian control files ? I don't see such type of class listed on python-apt
 * cwillu_at_work reinstalls libc6
<cwillu_at_work> yep, bogisity
<mvo> joaopinto: what use case do you have in mind?
<joaopinto> hum, there is a apt.debfile.DscSrcPackage, not sure that would correctly handle .changes files
<mvo> joaopinto: you can use a TagFile() for this
<joaopinto> mvo, I just want need to read data from *changes and *dsc files
<superm1> hi mvo, would you mind taking a look at bug 558956?  I'm unsure of what the proper solution is to help this
<ubottu> Launchpad bug 558956 in mythbuntu-meta "8.04LTS->10.04LTS upgrade failed: Various packages have broken dependancies" [Undecided,New] https://launchpad.net/bugs/558956
<joaopinto> mvo, TagFiles is what I was looking for, thanks
<pitti> tjaalton: hm, I wrote a test program which does 10.000 XCreatePixmap() calls in a row, but it works fine; I guess it's not that simple :/
<mvo> superm1: hm, I need to ask for the full log
<superm1> mvo, which log?  i'll see if mrand has it
<mvo> superm1: main.log please
<superm1> mvo, okay, thanks
<mvo> superm1: hm, unless its the same as in the other report he send
<superm1> it's a little different
<superm1> that other report showed a problem with the usplash theme, and so we did a c/r/p for that usplash theme package from the plymouth theme package
<cwillu_at_work> mvo, do I point dpkg patches at you?
<mvo> cwillu_at_work: you can, cjwatson is doing most dpkg work these days though
<cwillu_at_work> ah, k
<cwillu_at_work> mvo, don't suppose you know of any bugs where /var/lib/dpkg/info files go missing mysteriously?
<mdeslaur> pitti: It appears cups in lucid is still affected by CVE-2010-0302. I don't know if kees already mentioned this to you or not. Are you planning on fixing in debian and syncing?
<ubottu> Use-after-free vulnerability in the abstract file-descriptor handling interface in the cupsdDoSelect function in scheduler/select.c in the scheduler in cupsd in CUPS 1.3.7, 1.3.9, 1.3.10, and 1.4.1, when kqueue or epoll is used, allows remote attackers to cause a denial of service (daemon crash or hang) via a client disconnection during listing of a large number of print jobs, related to improperly maintaining a reference count.  NOTE: some of thes
<pitti> mdeslaur: yes, I already committed the fix to Debian bzr
<mdeslaur> pitti: oh, great, thanks!
<pitti> mdeslaur: I kind of hoped that the previous version would go to testing at some point, but libkrb5 is stuck :(
<pitti> so I'll just do another upload
<mdeslaur> pitti: ok
<mvo> cwillu_at_work: no, but that sounds pretty scary
<cwillu_at_work> mvo, silly people were using readdir wrong :)
<cwillu_at_work> only seems to affect btrfs roots, was curious if anyone else had tripped over it
<superm1> mvo, he won't be able to attach it until later today, would you mind subscribing and responding at your convenience then?
<mvo> superm1: sure, thanks for pointing me to it
<cjwatson> mvo: bug 518856 - it's been "fix committed" for ages, but I'm guessing that's not accurate given how long it's been open.  I've moved its milestone to final for now, but what's its correct state?
<ubottu> Launchpad bug 518856 in update-manager "Support ends dialog should auto-detect universe" [Medium,Fix committed] https://launchpad.net/bugs/518856
<mvo> superm1: that reminds me, I should create a profile for mythbuntu
<mvo> superm1: a upgrade test profile I mean, then it gets tested automaticaly
<superm1> mvo, ooh, yes that would be spectacular :)
<superm1> mrand has been doing it painfully by hand currently and finding all of these problems
<mvo> cjwatson: I close it now, sorry
<Daviey> mvo: that is awesome, would it be possible to provide some user data?  Perhaps not this time, but for future?
<Daviey> ie, mysql tables?
<cwillu_at_work> mvo, cjwatson, http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=575891 is the bug I was talking about;  just tested the patch, and at the very least it no longer loses files from /var/lib/dpkg/info
<ubottu> Debian bug 575891 in dpkg "dpkg makes wrong assumption about readdir() and lose metadata files with btrfs" [Important,Open]
<mvo> Daviey: for a upgrade test you mean? sure
<Daviey> mvo: I am a happy boy, need to depreciate mrand now. brb
<mvo> superm1: ok, I can add a profile, it will still be painful to fix the bugs, but finding is easier at lest :)
<ScottK> cjwatson: When I was reviewing your debconf update in the queue yesterday, I noticed it also needs to be updated for python3.1 versus python3.0.
<ScottK> jdstrand: Is it your archive admin day today?  If so, I'd appreciate it if you would accept libqinfinity out of binary New as there's another sync waiting on it that we need for NBS resolution.
<jdstrand> ScottK: done
<ScottK> jdstrand: Thanks.
 * jdstrand nod
<jdstrand> s
<ScottK> ;-)
<cjwatson> mvo: ah, thank you
<cjwatson> ScottK: do you happen to know whether 3.0 should still be there?
<ScottK> cjwatson: It should not.  We only have 3.1 in Lucid.
<cjwatson> ok
<cjwatson> cwillu_at_work: I'd consider it once it's in the dpkg git repository - I don't think we can regard it as RC for lucid though given the general state of btrfs support right now
<ScottK> cjwatson: That's also true for debian/unstable.
<cwillu_at_work> cjwatson, absolutely
<cwillu_at_work> cjwatson, if I'm not mistaken, the dpkg maintainer is reviewing the patch as we speak
<cjwatson> ScottK: uploaded
<ScottK> Thanks.
<cwillu_at_work> cjwatson, that's actually why I asked before if there were any outstanding mysterious bugs with similar behaviour;  the consensus was that dpkg was simply lucky that the filesystems it was commonly used on didn't have this issue
<cwillu_at_work> er, rather: had behaviour which didn't trigger this issue
<pitti> tkamppeter: cups 1.4.3 update is in bzr now, works well
<pitti> tkamppeter: I upload this now
<cjwatson> mvo: how about bug 518866 - we're after UI freeze now, shall I bump that to post-lucid?
<ubottu> Launchpad bug 518866 in update-manager "Confirm dialog is confusing and too technical" [Medium,Confirmed] https://launchpad.net/bugs/518866
<cjwatson> mvo: and bug 540790
<ubottu> Launchpad bug 540790 in software-center "handling of untrusted sources is suboptimal" [Medium,Confirmed] https://launchpad.net/bugs/540790
<mvo> cjwatson: yes please for #518866
<mvo> cjwatson: 540790> I want to have a look if it can be improved without new strings, but it may have to be defered
<tkamppeter> pitti, great. I am too busy with s-c-p.
<ccheney> NCommander: hi whats up?
<pitti> tkamppeter: you're going to LF summit next wek?
<NCommander> ccheney: was going to ask you an OOo question but looks like the current ARM breakage is a gcc bug
<ccheney> NCommander: ok
<cjwatson> mvo: bug 522225 is still feasible, isn't it?
<ubottu> Launchpad bug 522225 in mysql-dfsg-5.1 "permissions incorrect on libmysqlclient16_7.0.9-1_amd64.deb" [High,Fix released] https://launchpad.net/bugs/522225
<cjwatson> (he says hopefully ...)
<mvo> cjwatson: dosn't that only affect lucid -> lucid?
<directhex> micahg, i patched up gluezilla so it doesn't crash, but doesn't display anything either. andreia will look into it at the weekend
<micahg> directhex: ok, thanks, feel free to ping me if I can help with any xul related stuff
<zyga> mvo: hi
<cjwatson> mvo: yes; it's milestoned because we still have to mention it in the lucid technical overview, and it'd be nice if we didn't
<pitti> mdeslaur: cups uploaded now (with 2010-0302 fix)
<cjwatson> mvo: also interested if you know what's happening with bug 553369 (sorry, I seem to be hassling you a lot today)
<ubottu> Launchpad bug 553369 in update-manager "[Lucid] Update-manager removed the hardware drivers during upgrade hardy2lucid" [High,New] https://launchpad.net/bugs/553369
<directhex> micahg, basically, i think your gre version patching is wrong (since that's what i fixed to stop the crashing), but some behaviour needs some love to make it actually work
<mvo> cjwatson: 522225> its a bit problematic as the release upgrade is usually what is tkaing care of this
<mdeslaur> pitti: thanks!
<mvo> cjwatson: we can add something, thats for sure
<mvo> cjwatson: I check the nvidia bug out
<mvo> cjwatson: and no worries, at this time of the release we tend to look at upgrade issues :) so all good
<mvo> zyga: hi
<mvo> zyga: lots of churn in trunk, you may wan tto upgrade
<zyga> mvo: sorry I was not of much help yesterday, my kids have a nasty cold and I'm babysitting them
<zyga> mvo: pulling now
<mvo> zyga: I'm also in the process of making the updates smoother
<mvo> zyga: no worries
<cjwatson> lool: have you looked at bug 555330 yet (or do you expect to be able to, soon)?
<ubottu> Launchpad bug 555330 in mime-construct "[MIR] mime-construct" [High,Incomplete] https://launchpad.net/bugs/555330
<mvo> ogra: every time I read orca I think of you, can't help it (just fixed some a11y bug)
<ogra> mvo, :/ i would have thought i'm more colorful
<mvo> ogra: a bit of a mechanical voice too :P
<ogra> heh
<mvo> ohh, commit r699
<tkamppeter> pitti, yes, I am organizing the OpenPrinting Summit.
<asac> tkamppeter: on hardy is it safe to just download the hplip.run thing from HP and run it?
<asac> or will that cause issues?
<pitti> tkamppeter: ah; good luck, and safe travels!
<pitti> tkamppeter: where is it this time? SF again?
<asac> tkamppeter: or is there a backport package somewhere?
<lool> cjwatson: pitti had pinged me, but after your ping I actually reviewed the new deps again and wrote up my MIR comments in the bug
<lool> ttx: Would you please look at LP #555330 when you have some time and tell me whether it's an issue to pull these new (very small) packages on the server radar for logcheck?
<ubottu> Launchpad bug 555330 in mime-construct "[MIR] mime-construct" [High,Incomplete] https://launchpad.net/bugs/555330
 * ttx looks
<ttx> lool: I don't have objections, but your latest comment seems to answer the question already ?
<lool> ttx: Yeah, first I thought it was on the ISO; but because logcheck is a server package, I wanted to make sure you had no objection to the new deps
<lool> since in the end you might have to look at logcheck bugs
<ttx> lool: if I object new perl libraries in main, I get fired :)
<lool> ttx: haha
<lool> Right, I should ask Jos next time
<ttx> heh
<cjwatson> mvo: also just a reminder that your support-timeframe-information branch had some comments from noodles that seem to still need to be addressed?
<slangasek> lool: logcheck is too on an ISO, it's on the DVD
<slangasek> lool: FYI :)
<chrisccoulson> hi persia, would you mind adding me to ubuntu-sponsors please? (my u-u-s membership expires soon)
<persia> chrisccoulson: Done.  thanks for sponsoring.
<chrisccoulson> persia - thanks :)
<mvo> cjwatson: thanks
<jcastro> mvo: also don't forget debian squid guy. :D
<cwillu_at_work> cjwatson, the dpkg patch just hit debian's git
<cwillu_at_work> http://git.debian.org/?p=dpkg/dpkg.git;a=commit;h=18b12083b5fee4e7e26e1382e50321e7956fcdb9
<lool> slangasek: Oh right, I only checked the Tasks field
<wcGary83> hi all! does anybody know how to currently add a sound applet in Lucid?
<ScottK> wcGary83: Help for Lucid is in #ubuntu+1
<jcastro> sound applet should run automatically, ensure sound-indicator is installed
<wcGary83> no luck... thanks though i will go to ubuntu+1!
<kirkland> cjwatson: slangasek: could one of you guys trigger a new eucalyptus build?
<kirkland> cjwatson: I'd like to verify the tasksel change we made yesterday (which didn't land in the over night build)
<slangasek> kirkland: eucalyptus build> you mean a CD build?
<kirkland> slangasek: sorry, yes
<kirkland> slangasek: server iso build
<kirkland> slangasek: sorry, euca on the brain
<slangasek> I have a salve that will help with that
<kirkland> slangasek: heh
<slangasek> yes, let me finish walking through the beta-plus-one-day checklist and I'll fire one off
<kirkland> slangasek: ack, thanks
<kirkland> lamont: hi
<slangasek> kirkland: running, ETA: 30 min
<kirkland> lamont: vvv
<kirkland> update-notifier-common.links:usr/lib/update-notifier/update-motd-reboot-required etc/update-motd.d/98-reboot-required
<kirkland> update-notifier-common.links:usr/lib/update-notifier/update-motd-updates-available etc/update-motd.d/90-updates-available
<kirkland> update-notifier-common.links:usr/lib/update-notifier/update-motd-cpu-checker etc/update-motd.d/20-cpu-checker
<kirkland> lamont: I would think that these should be considered conffiles by dh, since they're installed by dh_installlinks
<kirkland> (dh_link, rather)
<kirkland> lamont: is my understanding wrong?
<lamont> kirkland: dunno
<kirkland> lamont: okay, i'll do some testing
<lamont> I just know that if you dist-upgrade after removing the symlinks, they magically reappear
<kirkland> lamont: dist-upgrade from lucid->newer_lucid, or karmic->lucid?
<lamont> lucid -> newer lucid
<jdong> how does ureadahead detect the root filesystem? On btrfs, ureadahead refuses to create a pack for root.
<Darxus> What's the easiest way to get the debugging symbols for the empathy package on Karmic?  empathy-dbg exists on Lucid but not Karmic.  Mine's segfaulting on startup.
<ScottK> Darxus: http://ddebs.ubuntu.com
<Darxus> Sweet!
<Darxus> Yay!  empathy-dbgsym
<Darxus> So why is there an empathy-dbg un lucid?
<ScottK> Usually we either get -dbg from Debian packaging or they are added by devs that forget/don't know about ddebs.
<Darxus> Ahh.
<Darxus> Yeah I've seen -dbg packages mentioned all over the place and never noticed ddebs.
<Darxus> Damn.  Bit by package pinning again (to karmic, when the new package was in karmic-updates).  Current empathy package doesn't crash.
<apw> pitti, does the work items tracker now understand postponing an item in one milestone and copying it to the next?
<kees> mvo: I have a question about update-manager on hardy, are you still around?
<cjwatson> kirkland: symlinks into /etc don't get to be conffiles
<kirkland> cjwatson: even if i add them manually to debian/conffiles ?
<cjwatson> it's not a good idea anyway IMO!
<cjwatson> it involves the user editing stuff in /usr indirectly
<cjwatson> I'd strongly recommend some different approach
<kirkland> cjwatson: okay, thanks
<kirkland> lamont: ^
<cjwatson> for example you could write trivial conffile scripts in /etc that exec the programs in /usr
<kirkland> cjwatson: yeah, that's what i'll have to do
<kirkland> cjwatson: shell scripts that exec, rather than symlinks
<lamont> ah. makes sense
<lamont> ta
<kees> kirkland: what are you trying to have happen?
<kees> kirkland: I'm seeking to make sure that cpu-checker always runs.  :)
<kirkland> kees: update-notifier-common installs symlinks in /etc/update-motd.d
<kirkland> kees: but lamont wants to make sure that it doesn't run
<kirkland> kees: so he wants to break that symlink, and not have it come back on upgrade
<kees> "it"?
<kirkland> kees: cpu-checker, updates-available, phone-home, whatever
<kees> maybe update-motd needs a /etc/default file?
<kirkland> kees: hmm, i think we should just move away from symlinks
<kirkland> kees: use a simple shell script that execs instead
<kirkland> kees: and lamont can rm that file, comment out the contents, or chmod -x it
<kees> kirkland: post-lucid, though.
<kirkland> kees: that's fine with me;  lamont?  is this lucid-release-critical?
<lamont> that depends... you gonna ever update it in lucid?
<lamont> it offends me greatly, dunno if it properly qualifies as RC though
<kirkland> lamont: would you be willing to carefully review a debdiff and test it?
<kirkland> lamont: b/c i have one ready
<lamont> sure - it'll be later today though
<kirkland> lamont: http://paste.ubuntu.com/411714/
<lamont> there were others scattered around as well, of course
<lamont> but yeah, I'll review in a while
<kirkland> slangasek: i'm fixing a motd bug in mountall ... is it bzr managed?
<slangasek> yes
<slangasek> lp:ubuntu/mountall
 * kirkland doesn't see any uri in debian/control
<kirkland> slangasek: thanks
<kirkland> slangasek: http://paste.ubuntu.com/411728/
<kirkland> slangasek: pretty trivial fix, i'm going to push that up, if you don't have any objections
<slangasek> kirkland: I agree that the current behavior is buggy; but is there any reason we would care about having motd populated before the first login?
<kirkland> slangasek: i don't think so ... MOTD is about communicating with users upon login, right?
<kirkland> slangasek: and specifically text/console/tty/ssh logins
<psusi> pitti: I'm not sure you understood me in bug #558926.  There is no USB this is just a cdrom.  In a terminal cd /media/cdrom ( while you have a cd mounted ) and press the eject button.  The drive vanishes from the computer in nautilus.  Is this not a udisks problem?
<ubottu> Launchpad bug 558926 in udisks "Open files on ejected media confuse the system" [Undecided,Invalid] https://launchpad.net/bugs/558926
<xhaker>  /q crimsum
<xhaker> :/
<kirkland> slangasek: elmo might be able to answer that question better than me
<kirkland> elmo: <slangasek> kirkland: I agree that the current behavior is buggy; but is there any reason we would care about having motd populated before the first login?
<elmo> I don't care much about motd at all ;-)
<elmo> but if I were forced to, I can't imagine why I'd care pre first login, no
<kirkland> elmo: heh, cool, thanks for the input
<sabdfl> slangasek: https://bugs.edge.launchpad.net/ubuntu/+source/base-files/+bug/555916I was raised with me by the reporter, could you ask someone appropriate to take a view on it for Lucid?
<ubottu> Launchpad bug 555916 in base-files "NetBIOS name resolution broken, but extremely easy to fix" [Undecided,Confirmed]
<evarghese> question: has compiz been taken out of ubuntu by default?
<evarghese> it looks like it was taken out yesterday and put back in today without coverflow
<evarghese> is that right?
<hyperair> i haven't heard of anything of that sort.
<ScottK> There was a compiz upload yesterday.  You can check the changelog on launchpad.
<evarghese> ah ok gotcha
<slangasek> kirkland, elmo: ack, no objections to that change then
<kirkland> slangasek: thanks
<soren> Are the actual packages in Debian's NEW queue available somehow? I was about to submit a sync request for http://ftp-master.debian.org/new/python-cloudservers_1.0~a5-1.html, but can't seem to find a link to the actual .dsc and such.
<slangasek> sabdfl: adding 'wins' to nsswitch.conf is a very bad idea, WINS simply does not have the semantics Unix systems expect for host lookups; we have avahi for this - I'll follow up to the bug
<Laney> soren: no
<soren> Laney: Figures.
<Laney> however, there are one or two Ubuntu friendly ftp assistants who could help you out :)
<soren> Well, I can get the .dsc, I suppose. That's not really the problem.
<soren> I just wanted to give the authoritative reference to the .dsc in the sync request.
<soren> I don't have it myself since my sponsor apparantly re-"dpkg-buildpackage -S"'ed it.
<joaopinto_> hi
<Laney> soren: you can just upload it yourself as long as you get the orig.tar.gz identical to the one in Debian
<joaopinto_> is there a bug reported about a loop on the file system check when / is corrupted ?
<joaopinto_> I had to fix it so I can't report much more than this :\
<soren> Laney: That would unnecessarily upset my sense of correctness :)
<Laney> heh
<Laney> well you don't really have a guarantee that it won't be rejected from Debian
<Laney> so uploading -1 before it clears NEW is risky anyway ;)
<antivirtel> hello all
<antivirtel> can I ask someone to fix it plz: https://bugs.launchpad.net/ubuntu/+source/file-roller/+bug/177929 ? it is a very important thing for INTERNATIONAL use, and this is a very old problem, it reported and confirmed in december 2007
<ubottu> Launchpad bug 177929 in file-roller "We needs file encoding select function." [Unknown,Confirmed]
<persia> antivirtel: That's a *very* hard bug, and lots of work towards fixing it has been understaken, but there exists no reliable or good solution still :(
<antivirtel> persia but what can I do, there are a lot of important files in these zips... :S ?
<joaopinto_> hum, is there some easy way to cause a non severe ext4 fs corruption :P ?
<nemo> so I was reading: https://launchpad.net/~francesco-marella/+archive/unstable-evolution
<nemo> "3) Evolution-mapi: still not packaged, it needs more dependencies (openchange) to be packaged first. no way."
<nemo> That's the main reason I wanted to shift to 2.30, due to bug fixes for MAPI on the that branch
<nemo> Wondering what Francesco means - are there packages that aren't in package management?
<nemo> I'd like to avoid getting in a situation where I have to restore all my old evolution builds and maybe have forgotten which ones were which - I recall evolution has a lot of deps
<persia> antivirtel: It needs a reliable way to detect the encoding of the contents of the archive.  To the best of my knowledge, there is no metainformation guaranteed to be stored in zip files that would give the right information (I may be mistaken),  Some of the work in this area in the past has used a successive unpack model attempting different encodings based on a list from the user's current locale.  But it needs someone to dig through in detail
<persia> , and find something that works for all users.
<antivirtel> :S hmm... is it some other zip opening program ? like in windows: winrar ?
<evarghese> nemo, that makes it sound like an actualy mapi client implementation... is that correct?
<evarghese> or are we not still scraping exchange web
<evarghese> i.e owa
<persia> antivirtel: tar works slightly more sanely.
<nemo> evarghese: Unfortunately I've had a lot of issues w/ OWA at work, possibly due to sucky web gateway, possibly due to sheer size of GAL and number of e-mails
<nemo> evarghese: so. yeah. I've been building the MAPI (native) client for 2.28
<evarghese> same here :(
<evarghese> WOAH!!
 * evarghese hugs nemo 
<nemo> http://ftp.acc.umu.se/pub/gnome/sources/evolution-mapi/0.28/
<antivirtel> persia "sanely"?
<nemo> evarghese: also helped track down a bunch of bugs :)
<nemo> evarghese: but now I need to be on http://ftp.acc.umu.se/pub/gnome/sources/evolution-mapi/0.30/
<nemo> evarghese: esp since devs can't help me much w/ test builds unless I'm running 2.30
<antivirtel> persia it is installed
<evarghese> ah hmm
<nemo> sooo. wanted to try out Francesco's package, just thought I'd check to see if there'd be some major issue before I tried it
<antivirtel> so, please try to fix it: https://bugs.launchpad.net/ubuntu/+source/file-roller/+bug/177929 I go to win to open this fcking zip:S i leave BNC, bye
<ubottu> Launchpad bug 177929 in file-roller "We needs file encoding select function." [Unknown,Confirmed]
<nemo> hm. still unable to access keyserver.ubuntu.com, so I guess this is all purely abstract.
<crimsun> GrueMaster: I'll look in an hourish when I'm back from work
<GrueMaster> ok, I'll be here.
<cody-somerville> cjwatson, Is plymouth suppose to be in the minimal task?
<cjwatson> cody-somerville: yes
<cjwatson> cody-somerville: in lucid, it's critical to multiplex I/O during boot
<ccheney> http://www.engadget.com/2010/04/09/webos-port-of-xorg-in-the-works-openoffice-support-the-inevitab/ <- lmao
<rohan> is there any reason why the ubuntu lucid ISOs are not hybrid ISOs (which can directly be dumped to a usb stick)?
<cjwatson> rohan: there's a wishlist open for it.  just hasn't been done yet.
<cjwatson> (certainly won't change for lucid at this point, though!)
<rohan> cjwatson, thank you.. i thought there was a technical reason to it.
<rohan> and yes i understand it won't be changed for lucid now :)
<zyga> (if only ubuntu could make one disc for both x86 and x86_64 ... ahh dreams)
<ccheney> zyga: yea called DDCD :)
<cjwatson> I know, we'll weld two CDs together
<zyga> ccheney: DDCD?
<ccheney> zyga: http://en.wikipedia.org/wiki/Double_Density_Compact_Disc
<ccheney> zyga: old dead Sony tech
<zyga> cjwatson: jokes aside it's a big technical challenge
<zyga> cjwatson: and a cool idea (at least for me personally)
<ccheney> zyga: afaik it wouldn't be possible other than increasing storage space as the cd is too full to even fit a minimal difference of only the binary code parts
<zyga> ccheney: true, but it would be possible for a DVD edition
<ccheney> separating all binary code out and switching to xz for all packages might get us close, but that would be hard in itself, and very slow for older pcs
<rohan> zyga, opensolaris does have same ISO for both archs. but then it's because their kernel is made that way, to adapt to 32bit or 64bit on the fly.
<cjwatson> the DVD is full too
<cjwatson> at least in terms of a single-sided single-layer DVD
<ccheney> BDXL 128GB ftw :)
<zyga> cjwatson: I know both are full
<zyga> cjwatson: I just think that having one 'medium' (either CD or DVD) in some stripped fashion that can boot and install on both is cool
<cjwatson> it's a neat trick, and it's been done in Debian, but I don't think it's practical for Ubuntu images the way the world currently is
<zyga> and functional - apart from being cool
<rohan> cjwatson, debian has a multiarch disk?
<zyga> cjwatson: oh, debian has something like this?
<cjwatson> google
<cjwatson> nearly the entire top page of google hits for "debian multiarch cd" is relevant
<jibel> cjwatson, could you have a look at bug 557023 ? it appeared with the latest initramfs-tools.
<ubottu> Launchpad bug 557023 in initramfs-tools "update-initramfs: deferring update (trigger activated) / cp: cannot stat `/vmlinuz': No such file or directory" [Medium,Confirmed] https://launchpad.net/bugs/557023
<jibel> cjwatson, only 4 users are affected, maybe it's nothing maybe not.
<crimsun> GrueMaster: has PA worked correctly in Lucid for ARM boards prior to -0ubuntu11?
<crimsun> GrueMaster: I believe I've bisected the commit, but I would like to confirm before I dig into the asm.
<GrueMaster> I don't know.  I don't think so.  When was that release made?
<crimsun> GrueMaster: the upstream commit in question is 0d1154 (rework how stream volumes affect sink volumes), which landed in Lucid's 1:0.9.22~0.9.21+stable-queue-32-g8478-0ubuntu11
<crimsun> Mon, 22 Feb 2010 00:22:50 -0500
<GrueMaster> Ok.  Let me see if I can load the older version and test it.
<GrueMaster> I don't have any images earlier than 3/1, so I need to see if I can get it another way.
<GrueMaster> Looks like I will have to roll a new version.  This sucks.
<crimsun> GrueMaster: hmm, you shouldn't have to; you could forcibly downgrade to -0ubuntu10 using the version on LP (https://launchpad.net/ubuntu/+source/pulseaudio/1:0.9.22~0.9.21+stable-queue-32-g8478-0ubuntu10)
<crimsun> GrueMaster: just have to remember to manually toggle 'Line HP Swap'
<crimsun> anyhow, offline for a bit
<GrueMaster> I'll try it.
<slangasek> superm1: I'm uploading a new fglrx-installer to fix a FTBFS on i386; where should I send the debdiff so that it gets merged into the git repo/
<superm1> slangasek, email it to both me and tseliot, one of us can commit it
<slangasek> superm1: okie
<GrueMaster> crimsun: No luck there.
#ubuntu-devel 2010-04-10
<antivirtel> bb
<cyphermox> there's been a build failure of network-manager on amd64 earlier today, I'm trying to understand what went wrong: http://launchpadlibrarian.net/43575045/buildlog_ubuntu-lucid-amd64.network-manager_0.8-0ubuntu3_FAILEDTOBUILD.txt.gz -- my understanding so far is that it just failed because the dependencies were broken at that time for reasons other than NM's packaging, correct?
<ScottK> cyphermox: That's correct.
<cyphermox> awesome, thanks.
<cyphermox> what should I do about making sure it builds now? upload a new version?
<ScottK> cyphermox: No.  Ask a core-dev to retry it.
<cyphermox> ok
<ScottK> cyphermox: Hint: I'm a core-dev.
<cyphermox> I figured ;) could you please  run the retry?
<ScottK> Give me the url to the package page and I will.
<cyphermox> ScottK, I assume you mean this: https://edge.launchpad.net/ubuntu/+source/network-manager/0.8-0ubuntu3/+build/1684395
<ScottK> Yes. Thanks.
<cyphermox> actually, it failed for more than just amd64, so it's not entirely true
<cyphermox> also, a related package failed to build in the same way: https://edge.launchpad.net/ubuntu/+source/network-manager-pptp/0.8-0ubuntu2
<ScottK> cyphermox: SInce it built on i386, the others are probably archive squew as well.
<cyphermox> yup
<cyphermox> (and -2 was building fine... the change was in depends/recommends)
<ScottK> NM is retried on amd64.  It'll start soon, so let's see how it does.
<cyphermox> sure
<lifeless>  /win 110
<cyphermox> ScottK, thanks for running the retry, it seems to have worked properly this time
<cyphermox> ScottK, would you mind doing a retry for amd64 for network-manager-pptp? https://edge.launchpad.net/ubuntu/+source/network-manager-pptp/0.8-0ubuntu2/+build/1684401
<cyphermox> I believe the other archs could wait a bit longer without too much issues?
<ScottK> cyphermox: Done.
<ScottK> I'll give the others a try too.
<ScottK> Done.
<cyphermox> thanks a bunch
<crimsun> GrueMaster: ok
 * antivirtel is back (gone 00:05:11)
<hunger_p> my lucid box freezes in gdm since the last update:-(
<GNU\colossus> hi all
<GNU\colossus> what's the reasoning behind changing /etc/event.d to /etc/init in 10.04? I can't find anything in the bugtracker.
<persia> It's an upstream change.
<GNU\colossus> persia: and what's Upstart's reason for doing that? what's so bad about /etc/event.d/, now that all distros using Upstart actually adopted that path? is /etc/init/ at least going to be mandatory?
<persia> No idea, sorry.
<joaopinto> GNU\colossus, the change is described on karmic's release notes, but not the rational
<joaopinto> GNU\colossus, https://wiki.ubuntu.com/FoundationsTeam/Specs/KarmicUpstartPackagingPolicy
<GNU\colossus> joaopinto: thanks for digging that up.
<sistpoty> lamont: ghc6 made it on armel :)
<sistpoty> lamont: can you easily generate a list of armel packages where the build failed? (we'll need to rebuild all haskell packages more or less in order of http://orangesquash.org.uk/~laney/haskell-installability/armel.png, and I'm starting to loose track on which ones I've given back already)
<sistpoty> lamont: or do a mass give-back, in case the armel build-queue allows it?
<ScottK> sistpoty: Just go to qa.ubuntuwire.com/ftbfs and look.  You should get a pretty good list.
<sistpoty> ScottK: is that list constantly updated? (I've given back 1/3 of haskell this afternoon already)
<ScottK> sistpoty: I think /6 hours.  wgrant would know.  He can probably move it to more frequently on a temporary basis.
<sistpoty> ScottK: thanks, that's very helpful, indeed :)
<sistpoty> zul: any reason for the ltsp task at bug #522509 (can I mark that as fix released?)
<ubottu> Launchpad bug 522509 in ltsp "[FFE] tftpd-hpa doesn't start on boot" [Undecided,Fix committed] https://launchpad.net/bugs/522509
<directhex> where can i find the new logo font?
<ari-tczew> please move packages from SRU proposed to updates bug 421684 and bug 262235
<ubottu> Launchpad bug 421684 in obexd "[SRU] bluetooth send malformed files" [High,Fix committed] https://launchpad.net/bugs/421684
<ubottu> Launchpad bug 262235 in pyclutter "[SRU] Does not work on 64bit properly" [High,Fix committed] https://launchpad.net/bugs/262235
<GrueMaster> crimsun: found the fix for bug 528524.  I had thought NCommander's patch had been pushed into main.  It has not.  I just reimaged with Beta 2, tested (fail), installed libspeex1 & libspeexdsp1 from ppa, works.
<ubottu> Launchpad bug 528524 in speex "Sound not working in all apps through pulse on arm" [High,Confirmed] https://launchpad.net/bugs/528524
<crimsun> GrueMaster: phew, I was going crazy eebugging that asm
<crimsun> debugging, even. Anyhow, closing the pulse task. Thanks for confirming and testing!
<GrueMaster> Better you than me.  My asm experience is x86 only, and predates P4.
<GrueMaster> :P
<GrueMaster> I'm retesting on dove now.
<GrueMaster> Works on imx51 image.
<crimsun> great, I'll apply the patch and push to lucid
<apw> ogra_cmpc, was that kernel ok
<apw> don't suppose there are any archive admins on duty at the weekend
<GrueMaster> crimsun: This fix also works on dove image.  Good to go.  Thanks for your help.  If you are at UDS-M, remind me and I'll buy you a beer.
<crimsun> GrueMaster: you're welcome, thanks much for your assistance with all the arm sound issues.
<GrueMaster> I really should see about getting back into audio development again.  At least part time.
 * abogani waves
<slangasek> Keybuk: can you please confirm my analysis in bug #560175?
<ubottu> Launchpad bug 560175 in plymouth "switching from runlevel 5 to runlevel 1 locks up system" [Medium,Triaged] https://launchpad.net/bugs/560175
<Keybuk> slangasek: partially correct I think
<zul> sistpoty: no please go ahead
<sistpoty> zul: thanks!
#ubuntu-devel 2010-04-11
<wgrant> sistpoty, ScottK: It's been running hourly for a couple of weeks.
<wgrant> But it was broken yesterday because LP decided to break the API.
<slangasek> lamont: do you know why I'm unable to retry the compiz/ia64 build?
<slangasek> ArneGoetje: when do you plan to do final language packs for 10.04 final?  Do you expect there to be a respin between RC and final?
<ScottK> wgrant: I'd appreciate it if you could have a look at Bug #560422.
<ubottu> Launchpad bug 560422 in soyuz "Consistent retry failures on web UI" [Undecided,New] https://launchpad.net/bugs/560422
<wgrant> ScottK: I may be able to assist if you can find some Canonical person to look at the OOPS and get the traceback somewhere public.
<ScottK> Sigh.  Probably not much chance of that on the weekend.
 * ScottK wonders if slangasek is around and knows how to do it?
<slangasek> no clue, sorry
<slangasek> I probably don't have the access
<wgrant> OOPS-1562O184
<ubottu> https://lp-oops.canonical.com/oops.py/?oopsid=1562O184
<lifeless> whassup
<Keybuk>  /msg kees did you see the new Doctor Who yet?
<lifeless> wgrant: IntegrityError: duplicate key value violates unique constraint "buildpackagejob__build__key"
<Keybuk> err s/^ // :p
<wgrant> Fuck.
<wgrant> We have DB corruption.
<ScottK> \o/
<wgrant> I thought that was all fixed in Jan... :/
<ScottK> Have fun.
 * ScottK departs to go retrieve $TEENAGER from a distant location.
<lifeless> wgrant: sure its not a bug ?
<wgrant> lifeless: It probably is a bug. I meant that we thought we'd fixed all cases that caused anything like that.
<lifeless> pasted you the test
<slangasek> wgrant: ah, so is this probably related to my OOPS when trying to get a retry of an ia64 package earlier?
<lifeless> s/test/rest/
<slangasek> (compiz/ia64)
<ScottK> slangasek: That's the same one.
<slangasek> ah
<ScottK> (package)
<slangasek> heh, ok - hadn't looked at the bug
<wgrant> lifeless: Thanks.
<wgrant> lamont: You haven't been playing with builds in the last couple of days?
<lamont> slangasek: I know some nice people who could go look at (the brand new) OOPS-1562ED96 and tell  you why we can't retry it
<ubottu> https://lp-oops.canonical.com/oops.py/?oopsid=1562ED96
<lamont> wgrant: haven't been playing with builds lately, no
<slangasek> lamont: looks like these nice people are already doing so :)
<lamont> yeah - just walked back in, about to run off to dinner with the family
<lamont> and finally notciing the rest of scrollback... anyway, ew.
<wgrant> So, yeah, we have some impossible DB state. Easy to fix, but it will probably have to wait for Soyuz to appear on Monday.
<directhex> slangasek, you broke fglrx
 * sebner pets didrocks 
 * sebner pets directhex 
<sebner> didrocks: well, you too :D
<didrocks> sebner: thank you! :)
<sebner> heh :)
<directhex> looks like Bug #552548
<ubottu> Launchpad bug 552548 in fglrx-installer "fglrx broken after update to 2:8.721-0ubuntu7 (dup-of: 494699)" [Medium,Triaged] https://launchpad.net/bugs/552548
<ubottu> Launchpad bug 494699 in fglrx-installer "Does not support current Lucid kernel (2.6.32) or xserver (1.7)" [Critical,Fix released] https://launchpad.net/bugs/494699
<directhex> it's so totally not a dup of 494699
<wgrant> doko__: http://qa.ubuntuwire.org/ftbfs/test-rebuild-20100407/
<doko__> wgrant: cool, many thanks!
 * persia idly wonders why exim4 *and* postfix are both in main
<bigon> could someone make this sync plz? https://bugs.edge.launchpad.net/ubuntu/+source/hellanzb/+bug/549234
<ubottu> Launchpad bug 549234 in hellanzb "Please sync hellanzb (0.13-6) from debian unstable" [High,Confirmed]
<asac> james_w: hola ;) ... so what would it take to get branch imports going for ppas? is that in the pipeline?
<persia> asac: Do you really want that?  Would you not prefer auto-PPA upload from bzr push?
<asac> persia: is that mutually exclusive?
<asac> i would like both in the end ;)
<persia> Well, probably, unless one has different branch names for PPA->bzr and bzr->PPA to avoid loops.
<persia> But I expect that the development/integration effort would end up prioritising one of the features first.
<pbn> drÃ´le de cuite message...
<pyther> Hi. I was wondering if anyone knows where I can file a bug for icon-naming-utils?
<iulian> pyther: https://bugs.launchpad.net/ubuntu/+source/icon-naming-utils/+filebug
<pyther> iulian: I need to repot it upstream
<iulian> pyther: I don't know.
<iulian> Looks for its homepage.  Maybe it has a bug tracking system.
<iulian> s/looks/look/
<pyther> iulian: yah I've looked and come out pretty unsuccesful
<frenkel> there is a new release of wacom.ko that support 5 new Bamboo tablets and some others. is it possible to get this into lucid?
<persia> frenkel: We're past KernelFreeze, so it'd be very hard to get significant new kernel changes into lucid at this point.  I'd recommend asking for guidance on integration policies/procedures in #ubuntu-kernel: https://wiki.ubuntu.com/KernelTeam/KnowledgeBase may help give you some pointers as to how to help make that happen.
<frenkel> persia: i was afraid of that already
<frenkel> persia: thanks :)
<bigon> still nobody for syncing https://bugs.edge.launchpad.net/ubuntu/+source/hellanzb/+bug/549234 ?
<ubottu> Launchpad bug 549234 in hellanzb "Please sync hellanzb (0.13-6) from debian unstable" [High,Confirmed]
<bluefoxicy> holy crap
<bluefoxicy> I need to download 2,275M Of packages to upgrade to lucid
 * bluefoxicy downloads the 692M daily alternate CD instead.
<mkarnicki> hi guys, i'm seeking help: bzr push lp:~mkarnicki/+junk/hello returned: Agent admitted failure to sign using the key. //
<mkarnicki> Permission denied (publickey).
<mkarnicki> any hints? I have registered my ssh public key with lp
<ScottK> mkarnicki: Launchpad help is on #launchpad.
<mkarnicki> a, thank you ScottK
<bdrung> bigon: just wait. a member of ubuntu-archive will do the sync. (i assume it will be synced tomorrow)
<padraic> anyone running lucid with the nvidia gt240m?
<james_w> asac: I don't plan to work on it
<mkarnicki> padraic: i think i have g210m
<padraic> mkarnicki: does it work?
<padraic> i tried the live-cd with it and i just got a load of corrupt video after the bootscree
 * abogani waves
<abogani> I'm looking for sponsors: https://wiki.ubuntu.com/AlessioIgorBogani/linux-rtPPUApplication
<abogani> Thanks!
<mkarnicki> padraic: it's ASUS UL30VT, i think G210M. once i had 'the rainbow', but.. the next time i tried it worked fine
<lucas_> lool: around?
<zyga> iulian: hi
<iulian> zyga: Hello.
<iulian> Blah.
<jdong> stupid question that I don't seem to be very good at googling...
<jdong> why is it that I cannot alt-tab while dragging and dropping
<sladen> jdong: this could be related to the various there Grab() blocks modifier keys
<jdong> ah found a LP bug for it
<jdong> bug 111939
<ubottu> Launchpad bug 111939 in metacity "Not possible to alt-tab during a drag-and-drop operation" [Unknown,Confirmed] https://launchpad.net/bugs/111939
<jdong> who do I have to beg to accept the 1-liner patch?
<persia> Nobody: just upload it (or if you can't, submit a sponsorship request, or if it exists, wait)
<slangasek> directhex: by making it buildable and installable?
<directhex> well, 2 versions ago seemed pretty installed to me. but it's the issue with the stuff in /etc/ati/ not being replaced on update (i.e. all the files, which are required for the driver to work, are gone, and only .dpkg-bak versions are there)
<slangasek> directhex: which I haven't touched
<directhex> looks like luck is the biggest factor in why i hadn't been hit before, then
<slangasek> directhex: well, there is some dodgy conffile handling in the preinst that I noticed; since the comment says "these need to match what upstream wants but they have to be in /etc so fiddle around on upgrade", the right answer is probably to fix the preinst to nuke all of /etc/ati and make it a symlink to something under /usr
<directhex> slangasek, i agree. i don't think /etc is the right place for this stuff
<slangasek> directhex: and in fact, the package seems to take great pains to avoid etc/ati being tagged as conffiles, which at least partly explains the conflicts error on upgrade
<FeasibilityStudy> Anyone wanna tell me what this kernel failure might be?  http://pastebin.com/pVvcPdVc
<FeasibilityStudy> Apport tries to run, but it is denied permission (which is another bug to deal with).
#ubuntu-devel 2011-04-04
 * SpamapS_ just made his first real upload.. :-D
<TheMuso`> SpamapS: Awesome!
<c2tarun> is there any tutorial available for how to create a plugin for any application?
<TheMuso`> c2tarun: It depends on the application, and whether that application supports plugins.
<c2tarun> TheMuso`: its kontact.
<TheMuso`> c2tarun: Then you will have to find the developer documentation to look up the plugin API.
<c2tarun> TheMuso`: actually I am trying to look into this http://community.kde.org/GSoC/2011/Ideas#Project:_VOIP_Plugin_for_Kontact I thought to do my side research first, but failed to find on google how to create a plugin
<c2tarun> isn't there any basic steps for writing a plugin? :/
<RAOF> c2tarun: It's entirely application-specific; there's no guarantee that kontact even supports plugins.
<RAOF> (Although the GSoC idea suggests that it does âº)
<c2tarun> RAOF: yup. ok, so I'll ask in #kontact channel then :)
<c2tarun> anyone here is participating in GSoC?
<c2tarun> not as mentor.
<dholbach> good morning
<didrocks> good morning
<pitti> Good morning
<abhinav-> dholbach, thanks for your email reply :)
<dholbach> abhinav-, sure :)
<janimo> Riddell, hi, do you have a recent package example that used cmake and hardcoded /usr/lib/ paths that needs to be fixed for multiarch?I remember you mentioning something like this a while ago
<janimo> there's a FTBFS  which may be caused by something similar https://launchpadlibrarian.net/67912682/buildlog_ubuntu-natty-armel.igstk_4.2.0-4_FAILEDTOBUILD.txt.gz
<ohsix> hm
<ohsix> seeing lots of 404s on changelogs in aptitude lately, did something change?
<Riddell> janimo: cmake should be fixed to know to look in the multiarch directories
<janimo> Riddell, so you only worked around that in a specific package? Is the cmake fix in progress?
<janimo> is this affecting Kubuntu packages?
<Riddell> janimo: cmake itself should be fixed with the debian/patches/ubuntu_multiarch_library_directory.diff patch
<YokoZar> If a dummy package is removed entirely do we need to conflict/break it or can we just let it rot?  Will update manager remove dummy packages that no longer exist in the archive?
<YokoZar> Nevermind, answered my own question:    "If a package is completely replaced in this way, so that dpkg does not know of any files it still contains, it is considered to have "disappeared".  It will be marked as not wanted on the system (selected for removal) and not installed.  Any conffiles details noted for the package will be ignored, as they will have been taken over by the overwriting package."
<cjwatson_> in practice this never happens because there's always /usr/share/doc/$packagename/
<cjwatson> or more or less never
<YokoZar> hmm, that seems wrong somehow
<cjwatson> I would declare Breaks anyway.  It's cheap.
<cjwatson> actually, no, you want to get rid of the old package completely, don't you?  Conflicts+Replaces sounds appropriate
<janimo> co
<cjwatson> update-manager is useful for many things, but you shouldn't assume everyone is using it unless you have no other choice
<cjwatson> (of course, presumably an old dummy package hanging around isn't actually going to do any harm, so use your judgement there)
<YokoZar> Why not breaks/replaces?
<Laney> breaks doesn't enforce removal
<YokoZar> just deconfigure
<Laney> you can still have the files unpacked
<Laney> right
<YokoZar> Will these conflict lines do bad things if I define a new virtual package by the same name as the dummy package?
<YokoZar> I think that was my original intuition for wanting to use breaks
<cjwatson> if you plan to do that, use versioned Conflicts
<YokoZar> ahh, the one real use for versioned conflicts, makes sense
<cjwatson> right
<Laney> note that provides will only help for unversioned depends (if that's indeed what you are trying to take care of)
<OdyX`> ScottK2: Aye. Bugs were filed. apiextractor: #748331 generatorrunner: #748333, shiboken: #748334 and pyside got renamed: #740177
<Chipzz_> whoa, freenode is unstable today
<chrisccoulson> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Natty Beta-1 released! | Archive: Feature/UI freeze | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for dapper ->  maverick | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs | Current Friendly Patch Pilots: chrisccoulson
<nobuto> chrisccoulson: Could you review my debdiff on Bug #746538?
<ubottu> Launchpad bug 746538 in ubufox (Ubuntu) ""Needs restarted" message is not translated in Japanese(ja) locale" [Undecided,Confirmed] https://launchpad.net/bugs/746538
<chrisccoulson> nobuto, sure
<chrisccoulson> oh, it's for ubufox
<chrisccoulson> heh, we seem to be carrying a monster patchset for that now
<chrisccoulson> i should fork it ;)
<UBuxuBU> can i have a ubuntu page on my website?
<mterry> superm1, heyo, would you mind having a mythbuntu person look at https://code.launchpad.net/~mterry/ubuntu-seeds/mythbuntu.natty-gnome-system-tools/+merge/53423 ?  thanks
<Daviey> mterry, Have you tested it?
<mterry> Daviey, no?  it seemed straightforward.  But other flavors have used similar changes, so I believe it's safe
<Daviey> mterry, Great, I see xubuntu has adopted it.. fine with me, merged.
<Daviey> thanks for spotting it.
<mterry> Daviey, I did the package split, so I felt obliged  :)
<Daviey> heh
<mterry> slangasek, are you on "archive admin" duty today?  I have a sync I'd love to see happen: bug 746448
<ubottu> Launchpad bug 746448 in pylint (Ubuntu) "Sync pylint 0.23.0-1 (universe) from Debian unstable (main)" [Wishlist,Confirmed] https://launchpad.net/bugs/746448
 * mterry isn't sure why he put archive admin in quotes  :)
<cjwatson> mterry: I'll do a sync pass now
<mterry> cjwatson, thanks!
<mterry> cjwatson, note that that particular bug requires 3 syncs
<cjwatson> if ubuntu-archive is subscribed to it, then I'll pick it up
<mterry> cjwatson, well, they are all in the same bug.  perhaps I should have filed 3 separate ones?, but the other 2 are only needed to support new pylint
<hallyn> skaet_: good morning - please let me know if there is anything else you need from me on bug 727342.  (As I say it tests well for me)
<ubottu> Launchpad bug 727342 in open-vm-tools (Ubuntu) "FFE: open-vm-tools kernel module failed to build" [Critical,New] https://launchpad.net/bugs/727342
<ScottK> OdyX: All approved now.  Should get sync'ed soon.  Thanks.
<OdyX> ScottK: niiice. Thanks.
<cjwatson> mterry: it's fine the way it is.
<nobuto> chrisccoulson: Thanks for uploading!
<OdyX> ScottK: Would pyside-tools (currently in unstable, got out of Debian:NEW recently) be considerable ? It's only new functionality, but pretty much needed for correct PySide operation ?
<ScottK> OdyX: Yes, but it will need an FFe.
<ScottK> Please file the sync request as an FFe request and I'll review it.
<OdyX> ScottK: doing that now
<OdyX> ScottK: https://bugs.launchpad.net/ubuntu/+bug/750295
<ubottu> Ubuntu bug 750295 in Ubuntu "FFe: Sync pyside-tools 0.2.8-1 (universe) from Debian unstable (main)" [Wishlist,New]
<ScottK> OdyX: Just approved it.  It should at least get to Ubuntu New on the next round of syncs.
<OdyX> Nice.
<skaet> hallyn,   have gone in and approved it.   Thanks for getting this fixed.
<pitti> jdstrand, kees: releasing lucid kernels to -security/-updates: linux linux-backports-modules-2.6.24 linux-meta linux-restricted-modules-2.6.24 linux-ubuntu-modules-2.6.24
<jonny> cjwatson: Is https://wiki.ubuntu.com/SeedManagement#CD%20builds still accurate? It doesn't look to have been update since there was a unified live/install CD. I've been hunting around to find the list of packages one expects on a Live CD - is there a better way than looking at filesystem.manifest (or filesystem.manifest-desktop) on the CD? For example a way that doesn't require I get the CD?
<cjwatson> jonny: it looks fairly close to me, if you s/install/alternate/ and s/live/desktop/
<cjwatson> jonny: you can look at the .manifest and .list files alongside the CD on cdimage.u.c
<cjwatson> I've updated that documentation a bit - there's no point in it listing lots of seed names that are already in the STRUCTURE dependencies
<jonny> cjwatson: thanks. Is there some documentation somewhere about how the livecd is build - this is curiosity speaking now :) - As I understand it, Germinate spits out a bunch of potentially intersecting lists of packages, is there a tool beyond apt that reconciles those and makes the cd inside a chroot or something?
<jonny> *s/build/built ^
<cjwatson> jonny: livecd-rootfs builds the live filesystem
<cjwatson> https://code.launchpad.net/~cjwatson/ubuntu-cdimage/mainline (plus the submodules in configs/devel) does the rest of it
<cjwatson> hm, let me fix the mirroring there
<cjwatson> well, it should sort itself out in a bit
<superm1> Daviey, can you regenerate that meta package and upload too?
<YokoZar> is there an easy way to tell why apt wants to remove something on dist-upgrade?
<ohsix> use aptitude? :D
<YokoZar> ohsix: welp, aptitude wants to do something different from apt-get
<ohsix> shrug
<ohsix> at least aptitude lets you investigate its upgrade solution
<ogra_> ugh, aptitude
<juliank> YokoZar: There are debugging switchs to see this
<YokoZar> yeah that was my thought
<Daviey> superm1, ack, i wanted to check there wasn't anything else before doing so.
<juliank> YokoZar: Try -o pkgProblemResolver=true
<juliank> YokoZar: "-o Debug::pkgProblemResolver=true"
<juliank> But it can be very verbose
<YokoZar> juliank: $ sudo apt-get -o Debug:pkgProblemResolver=true dist-upgrade ?
<juliank> YokoZar: yes
<YokoZar> hmm doesn't seem to be changing the output up to the prompt...
<YokoZar> (the do you want to continue prompt)
<juliank> YokoZar: Try apt-get dist-upgrade -o Debug::pkgProblemResolver=1
<juliank> YokoZar: You just missed a colon, it seems
<YokoZar> yeah
<YokoZar> now if I can make sense of this output...
<juliank> YokoZar: you could put it on a paste bin and tell me what you're looking for
<juliank> http://paste.ubuntu.com/
<YokoZar> ahh I think I figured it out, obsolete version of a pacakge in an enabled PPA that was the same version as the fixed package I installed locally.  Apt wants to upgrade from dpkg -i installed package to one available on PPA, which in this case means getting the broken one.
<YokoZar> which had the side effect of trying to remove a fixed package that was also fixed in the ppa
<juliank> YokoZar: If needed, you can use pinning to overwrite this
<YokoZar> Yup.  Thanks juliank
<SpamapS> jhunt_: about the sendsigs killing OMITPIDS .. this seems somewhat broken.. I think the appropriate thing to do is to only care about processes with a goal of stop/ .. since the point of having no 'stop on' is that you run "forever" is it not?
<SpamapS> jhunt_: so whynot just replace that kill with a loop to stop all remaining jobs except rc?
<jhunt_> SpamapS: seems reasonable - that script just kinda "feels" too complex right now.
<jhunt_> I'm interested in the "vanilla upstart approach" too as it would be
<jhunt_> nice to keep separation between Upstart and SysV jobs (Upstart shouldn't
<jhunt_> need SyV)
<jhunt_> s/SyV/SysV
<jhunt_> We might need Keybuks thoughts on the preferred method for that one though.
 * YokoZar just vastly simplified some package rules files thanks to debhelper 7.
<smoser> jhunt_, can you verify for me that upstart doesn't care if a file is dos format ?
<smoser> i have to fix something in cloud-init when input is  dos format, i have to fix user scripts ("#!/bin/sh\r\n" -> "#!/bin/sh\n" ...)
<smoser> i'd like your statement as to whether or not i should do that for upstart jobs
<ion> It makes no sense to use \r\n in anything unixish.
<cjwatson> ion: except for TCP/IP protocols
<cjwatson> but yeah, files?  \n
<smoser> agreed. but user input is from windows, and i would like to not change their content except when required.
<smoser> because arbitrarily "fixing" things will break checksums that they might have calculated.
<cjwatson> I'm fairly sure upstart/libnih treats \r like \n
<smoser> at least that is why i wasn't going to change everything.
<smoser> ie, if you did a wget of a file, you wouldn't want wget to change its content.
<slangasek> mterry: sync> ack
<mterry> slangasek, cjwatson grabbed it for me, but thanks
<slangasek> mterry: ok, cool :)
<SpamapS> jhunt_: I wonder if we can complete the transition to an upstart-only shutdown in oneiric.
<jhunt_> SpamapS: would be good! I've added it to the wishlist: https://wiki.ubuntu.com/FoundationsTeam/OneiricPlanning#Ideas
<SpamapS> jhunt_: so another thing I was wondering is whether we can implement grouping in upstart jobs. If we could say   initctl --exclude-group shutdown stop-all   .. and let upstart do this internally.. that gives us a very clean way to terminate everything
<SpamapS> jhunt_: the problem with "disable spawning" is that you may need to spawn a few processes to shutdown cleanly.
<bryceh> @pilot on
<udevbot> (pilot (in|out)) -- Set yourself an in or out of patch pilot.
<bryceh> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Natty Beta-1 released! | Archive: Feature/UI freeze | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for dapper ->  maverick | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs | Current Friendly Patch Pilots: chrisccoulson,
<bryceh> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Natty Beta-1 released! | Archive: Feature/UI freeze | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for dapper ->  maverick | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs | Current Friendly Patch Pilots: bryceh, chrisc
<mterry> TheMuso, so ldtp and pyatspi2 don't get along packaging-wise (ldtp depends on pyatspi1 currently).  Is that just a packaging bug or is ldtp not compatible with atspi2?
<tgardner> cjwatson, I'm thinking vga=788 isn't gonna work so well on bare metal. see bug #745947
<ubottu> Launchpad bug 745947 in linux (Ubuntu Natty) "Fails to display video after grub (kernel lacks video output)" [High,In progress] https://launchpad.net/bugs/745947
<akheron> bug #660483, what should I do now?
<ubottu> Launchpad bug 660483 in couchdb (Ubuntu) "CouchDB 1.0.1 must depends by libjs-jquery >= 1.4.2" [Undecided,Confirmed] https://launchpad.net/bugs/660483
<akheron> I've proposed a patch
<bryceh> akheron, I'll take a look
<bryceh> akheron, can you also add to the changelog the bug number that your patch fixes
<bryceh> i.e.
<bryceh> +  * Don't link to system's jquery.js, as it's too old (LP: #660483)
<bryceh> akheron, sometimes I also like to mention the error message that goes away with the fix (so people with the problem can verify that this patch fixes it).  Totally not necessary though.
<bryceh> akheron, if you post an update ping me and I can upload it for you, the change itself (removing the link) looks fine
<akheron> bryceh: ok
<cjwatson> tgardner: seems odd because that was actually a change inherited from Debian
<tgardner> cjwatson, well, I've got it repro'd on at least one server.
<cjwatson> tgardner: wait, is this a recent regression?
<cjwatson> tgardner: they said it was fine in the alphas, and those used vga=788 too
<tgardner> I wonder if it has to do with modularizing CONFIG_FB_VESA
<cjwatson> I bet that we forgot to put vesafb in a udeb
<tgardner> cjwatson, hmm, lemme check.
<cjwatson> the installer has code to load it if it can
<tgardner> actually, I'm sure of it
<cjwatson> hm, it's in fb-modules
<cjwatson> -rw-r--r-- root/root     14288 2011-04-01 00:11 ./lib/modules/2.6.38-8-generic/kernel/drivers/video/vesafb.ko
<cjwatson> mind you, d-i is still on -7
<tgardner> cjwatson, and in modules/fb-modules:vesafb
<cjwatson> yeah
<cjwatson> does it actually work when modularised, at the moment? :)
<cjwatson> fb-modules is in the initrs
<cjwatson> initrds
<tgardner> cjwatson, dunno. I've been reading the stuff in Documentation/fb/fbcon.txt. it says if you specify vga= , then fbcon isn't loaded (which kind of looks like what is happening)
<cjwatson> d-i explicitly loads fbcon
<tgardner> cjwatson, I'm not nearly as familiar enough with this frame buffer stuff and early boot.
<cjwatson> http://bazaar.launchpad.net/~ubuntu-core-dev/rootskel/ubuntu/view/head:/src/lib/debian-installer-startup.d/S40framebuffer-module-linux-x86
<cjwatson> tgardner: you can add BOOT_DEBUG=3 and drive stuff by hand, FWIW
<cjwatson> that gives you a shell at the start of /init
<tgardner> cjwatson, ok, gimme a minute. this is easily reproducible using VMware
<cjwatson> the execution flow is then the stuff in /init, then /sbin/debian-installer-startup, then /sbin/debian-installer
<cjwatson> (but you shouldn't need the last bit)
<cjwatson> it's nearly all shell, fairly easy to pick apart and run step by step
<cjwatson> kvm doesn't show it (either default or -vga std)
<tgardner> cjwatson, agreed, kvm was the first thing I tried.
<tgardner> cjwatson, BOOT_DEBUG=3 on the syslinux command line, right?
<cjwatson> yeah
<tgardner> no joy
<akheron> bryceh: ping, I added an updated patch
<bryceh> akheron, thanks
<cjwatson> tgardner: what variety of absence of joy?
<cjwatson> oh, hm
<cjwatson> you can type 'modprobe vesafb' blind
<tgardner> cjwatson, a total absense of joy with vga=788 (e.g. no display whatsoever). I verified that BOOT_DEBUG=3 works without vga=788/
<cjwatson> tgardner: that total absence of joy may be fixed by typing 'modprobe vesafb'?
<cjwatson> fbcon is non-modular
<cjwatson> is there a particular way to tell it to attach to a new fb, or is it just supposed to notice?
<cjwatson> I'm open to the option of deleting vga=788 BTW, I just want to try as hard as possible not to since it really makes the installer a lot more pleasant
<cjwatson> and actually, we used vga=788 in maverick
<cjwatson> it's not a new thing in natty
<tgardner> cjwatson, so if I blindly type 'modprob vesafb' then I get a console with BOOT_DEBUG=3. so, its definitely related to the modularization of VESAFB
<bryceh> akheron, looks good, upload sponsored
<akheron> bryceh: thanks
<akheron> my first upload :)
<bryceh> akheron, well then congrats :-)
<cjwatson> tgardner: aha, so then the question is what happened to the existing code to run that
<tgardner> cjwatson, at the point that the boot debug breaks, /proc isn't mounted.
<cjwatson> indeed
<cjwatson> cat /init
<bryceh> akheron, for reference, in the future when you have patches to sponsor you can check the topic of this channel to see if someone is listed as Patch Pilot on duty, and if so give them a holler, and they'll help you get stuff uploaded
<cjwatson> it's mounted right after that debug shell
<akheron> bryceh: ok
<tgardner> cjwatson, ok, that looks fine.
<akheron> bryceh: I actually once worked on a new package, but fixing existing packages seems to be way easier :)
<akheron> what comes to get the upload sponsored
<akheron> *getting
<cjwatson> tgardner: what does 'readlink /proc/self/fd/0' say, after you mount /proc?
<tumbleweed> we are much more forgiving of lack of perfection in existing packages :)
<tgardner> cjwatson, I exited busybox once to let init run, so /proc is now mounted, readlink /proc/self/fd/0 == /dev/console.
<bryceh> akheron, 'upload sponsored' means your patch has been added to the ubuntu repository and will be live to natty users once the package has finished rebuilding (typically a couple hours, depends on the package and build server loads)
<akheron> bryceh: yeah
<akheron> bryceh: but this fix was actually targeted to the lucid backport only
<bryceh> akheron, in this case since your patch is against lucid, it will also need to go through a review step
<akheron> ah, ok
<bryceh> subject: [ubuntu/lucid-backports] couchdb 1.0.1-0ubuntu3~lucid2 (Waiting for approval)
<cjwatson> tgardner: hm, not quite the right test, one moment while I experiment
<bryceh> I'm not sure how frequently lucid-backports gets reviewed though... could take anywhere from a few hours/days to maybe weeks
<akheron> is there a backports team or such that does the approving?
<bryceh> yes
<akheron> ok, sounds good
<akheron> and I'm not in that big a hurry, a few days is fine :)
<bryceh> akheron, I'm not sure exactly who is on the team, but https://help.ubuntu.com/community/UbuntuBackports has some more information
<cjwatson> tgardner: ok, reboot; in the first debug shell, 'modprobe vesafb; echo sh >/lib/debian-installer.d/S00sh' (no need to make it executable); exit twice; 'readlink /proc/self/fd/0'
<cjwatson> in kvm, that gives me /dev/tty0
<tgardner> cjwatson, ok, one sec while I get there
<tgardner> cjwatson, readlink /proc/self/fd/0 == /dev/console
<m4n1sh> pitti: send the brainstorm final mail to technical-board list. It might be in the moderation queue
<cjwatson> tgardner: hm, so d-i's assumption is that that means serial
<cjwatson> tgardner: is there a free vmware download that exhibits this, do you know?
<tgardner> cjwatson, you can use it as an eval for 30 days AFAIK
<cjwatson> ok, will just workstation do, do you think?
<tgardner> cjwatson, yep, I'm using 7.1.4
<cjwatson> ok, I can queue it up to give it a try, unless you want to continue
<cjwatson> IIRC there is some weird interaction with stdin and the console in the depths of busybox init
<tgardner> cjwatson, well, what would you like to try next? remember, I can get this on bare metal (buts a huge pain 'cause the server takes 3 minutes to boot)
<tgardner> cjwatson, I could always de-modularize VESAFB for the -server flavour, but that seems like a hack.
<cjwatson> I think what I ideally want is a set -x trace of debian-installer-startup, to see why it apparently isn't loading vesafb
<cjwatson> there's a lot of blind typing involved there though
<tgardner> cjwatson, ok, perhaps I'll let you handle it, ok?
<cjwatson> after that ... not sure, might involve building a debug busybox init?
<cjwatson> I'm happy to have a crack at it, although I do already have about a week's worth of work queued up that's beta-2-critical
<cjwatson> but I guess we have an understood fallback option
<tgardner> I'll dribble some notes in the bug report.
<cjwatson> thanks - I'll give you a shout if it's looking impossible for me
<tgardner> cjwatson, I'm sure you don't get enough email, so I've subscribed you to bug #745947. I'm sure this'll come up on skaet's radar pretty soon.
<ubottu> Launchpad bug 745947 in linux (Ubuntu Natty) "Fails to display video after grub (kernel lacks video output)" [High,In progress] https://launchpad.net/bugs/745947
 * tgardner --> lunch
<cjwatson> ta
<vish> SpamapS: hi, i think you also have to comment asking people to test the -proposed.. pitti uses a reply template for SRUs; otherwise people wont know how they have to test it.. (noticed it on the compiz bug)
<vish> or was that the initial ACK? (/me confused, normally used to seeing pitti do those :D )
<micahg> vish: that happens when it's accepted I believe
<vish> ok, seems something new.. i blame pitt-i ! ;p
<micahg> vish: or rather, when review/accepted at the same time, that notice is used since the package is building, it's hard to post it before it's actually accepted since you don't know when the package will build
<vish> ahhh! its still building
<SpamapS> vish: I do not have the ability to accept the package into -proposed yet, as pitti is still training me, so he will see that message and accept it.
<SpamapS> I'd make a template, but I'm hoping we'll finish with the training-wheels soon and I can just use his template.
<vish> SpamapS: cool, thanks! dint know that.. :) (thought you approved it)
<SpamapS> vish: well I "approve" it, but Pitti pulls the big red handle to make it actually go. :)
<vish> righto, i meant accepted :)
<sladen> ivanka-train: cunning.  how did you manage that?
<ivanka-train> sladen: which bit?
<sladen> ivanka-train: not dropping IRC while transitioining?
<ivanka-train> sladen: skillz
<ivanka-train> sladen: it will drop - but network manager handles the tunnels rather well without throwing its toys out
<hallyn> I pushed a package to lucid-proposed.  Where do I go to track whether I properly caused a package build?
<micahg> hallyn: was it accepted yet?
<hallyn> <shrug>
<hallyn> how do I tell? :)
<micahg> hallyn: you can look at launchpad.net/ubuntu/+source/foo to see about any package in the archive
<tgardner> hallyn, https://launchpad.net/ubuntu/lucid/+queue
<hallyn> (sorry, by 'pushed' i meant 'bzr push', not dput)
<hallyn> ok, thanks, lemme check those
<micahg> hallyn: ah, that's different :)
<micahg> hallyn: you should be able to do bzr lp-open in the dir I think
<hallyn> hm, i don't think i did it right
<micahg> hallyn: which package?
<hallyn> lp:ubuntu/lucid-proposed/qemu-kvm
<hallyn> it did update in bzr
<hallyn> but from the bzr source page i don't see how to go to package builds
<micahg> hallyn: that doesn't work yet
<micahg> hallyn: you can to create a source package like normal from the bzr branch and upload
<hallyn> micahg: doh.  are you saying that only doesn't work for -proposed?
<hallyn> or for anything?
<micahg> hallyn: you can't build from branch unless it's a source recipe for a PPA
<micahg> AFAIK
<hallyn> micahg: good to know.  i didn't know that :)
<micahg> hallyn: once you push the bzr branch, you can have to still use bzr-builddeb to create a source package
<hallyn> thanks, will just dput then
<hallyn> well do, thx
<hallyn> (was just trying to be as UDD as possible :)
<hallyn> slangasek: so i did a bzr push to lp:ubuntu/lucid-proposed/qemu-kvm, thinking (wrongly) that would kick a build.  Now I can't dput the src package from the same tree bc it sees it already there.  Should I bzr uncommit and push --force?  Is there something better to do?
<slangasek> hallyn: I don't understand what you mean, "it sees it already there".  Can you paste me the error?
<hallyn> it rejected in email, i can fwd that
<slangasek> yes please
<slangasek> hallyn: so the reason for the reject is that the 0.12.3+noroms-0ubuntu9.4 *version* already exists; it appears to have been a security update, so it was never uploaded to lucid-proposed
<slangasek> hallyn: you'll want to untag your version from the lucid-proposed branch, merge in the version from lucid-updates/lucid-security, and re-push your changes on top
<hallyn> slangasek: d'oh, but that's not in lucid yet either right?
<hallyn> (i checked the bzr tree and didn't see it there)
<slangasek> hallyn: the "lucid" bzr branch is never updated after the release
<hallyn> ah
<slangasek> so this is only in the updates and security branches
<hallyn> even with an SRU?
<slangasek> yes
<slangasek> SRUs are published in -updates
<hallyn> oh!
<hallyn> got it
<hallyn> slangasek: thanks much.  i think it's clear to me now
<slangasek> sure thing :)
<bryceh> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Natty Beta-1 released! | Archive: Feature/UI freeze | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for dapper ->  maverick | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs | Current Friendly Patch Pilots: chrisc
<hallyn> slangasek: yay, upload worked.  (now just waiting for approval)
<Keybuk> jono: hey
<jono> hey Keybuk
<jono> hows tricks?
<Keybuk> good thanks, you?
<poolie> hi keybuk
<poolie> RAOF_, hi, can you have a look at bug 749817 for me?
<ubottu> Launchpad bug 749817 in xorg (Ubuntu) "natty regression: screen goes black when external monitor is connected" [Undecided,New] https://launchpad.net/bugs/749817
<poolie> is there anything i can do to help move it along?
<penguin42> poolie: You might like to attach the output of intel_reg_dumper from the intel-gpu-tools package in both the normal and broken states
<poolie> ok, thanks
<penguin42> I also wonder, shouldn't that be against xserver-xorg-intel or whatever the correct intel specific name is?
<RAOF_> penguin42: No, we like X bugs to be filed against xorg.
<penguin42> RAOF_: Oh ok, didn't know that - I'd moved a few to the specific ones in the past
<Keybuk> jono: but in answer to your tweet, no
<Keybuk> I'm not attending LF Collab this week
<RAOF_> penguin42: No, that's generally right.  We just encourage people to *file* bugs against xorg, where we can dispatch them appropriately.
<penguin42> ok
<jono> Keybuk, np
#ubuntu-devel 2011-04-05
<Keybuk> jono: have a little matter of moving apartment
<Keybuk> and David is visiting too from tomorrow
<Keybuk> if Collab looked like anything other than an LF wankfest, I may have made some time
<Keybuk> but it's too warm outside to get sticky
<lifeless> LF ?
<azeem> linux foundation
<lifeless> ah
<azeem> it's the plumbers conference for business people or something
<Keybuk> it was supposed to be the plumbers conference, but for distro people
<Keybuk> but then they turned it into the Moblin conference
<Keybuk> which became the MeeGo conference
<Keybuk> now it'
<Keybuk> now it's the "let's do something that's not Linaro" conference, I think
<bradm> hey, I'm being affected by bug#727620, is there anything I can do to help with it in terms of info / whatever?
<robert_ancell> poolie, hey, have you got the mouse issue in unity again?
<poolie> robert_ancell, hi, which mouse issue?
<poolie> ignoring mouse input?
<poolie> i'm back to the classic ui at the moment
<robert_ancell> poolie, bug 750816
<ubottu> Launchpad bug 750816 in unity (Ubuntu) "unity stops responding to some input (mouse grabbed?)" [Undecided,New] https://launchpad.net/bugs/750816
<poolie> robert_ancell, i had it this morning (before applying today's updates)
<robert_ancell> poolie, I've had similar issues before, and it's actually been due to an interaction between the touchpad and the mouse.  In that case I move the touchpad and it starts working again.  I'm wondering if you've got the same thing
<poolie> interesting
<poolie> i can re-test in a bit
<robert_ancell> I think it's an X issue, but it seems to have reduced recently
<robert_ancell> thanks
<poolie> i guess i could start a guest session, so i (maybe) don't lose my work
<robert_ancell> poolie, heh, no rush, but ping me if you get it again
<poolie> the other X issue that's hurting a lot is bug 749817
<ubottu> Launchpad bug 749817 in xorg (Ubuntu) "natty regression: screen goes black when external monitor is connected" [Undecided,New] https://launchpad.net/bugs/749817
<bradm> poolie: at least you can get X, my laptop won't even boot since I've gone natty :-/
<RAOF> poolie: I've looked at your description - do you have a picture in both screens *before* logging in?
<bradm> bug 727620 seems pretty serious
<ubottu> Launchpad bug 727620 in xserver-xorg-video-ati (Ubuntu) "[Radeon HD 5650 and 5470] Driver crash during recovery boot and in normal boot (Regression from 2.6.38-3 to -4)" [High,Confirmed] https://launchpad.net/bugs/727620
<poolie> RAOF, yes, pretty sure i do
<poolie> the same as in maverick
<poolie> the gdm greeter is displayed in mirror mode
<RAOF> So something's setting strangeness.
<RAOF> I don't suppose a guest mode login works?
<RAOF> Also, could you set the drm.debug=0x04 kernel parameter (either from the command line, or via /sys/modules/drm/parameters/debug) and reproduce, then attach dmesg and Xorg.0.log to the bug?
<poolie> ok
<poolie> will just finish filing other bugs then try these
<bradm> natty really doesn't like ATI 5600 series cards, now my 2nd monitor has its screen shifted across a few cms, its very disconcerting
<poolie> bradm, looxury
<poolie> RAOF, i updated bug 749817 with the data you asked for
<ubottu> Launchpad bug 749817 in xorg (Ubuntu) "natty regression: screen goes black when external monitor is connected" [Undecided,New] https://launchpad.net/bugs/749817
<poolie> and it's still present in today's xorg update
<RAOF> poolie: Ta muchly.
<poolie> robert_ancell, i'm running unity again; if i hit that problem i will try wiggling the touchpad and trackpoint
<robert_ancell> poolie, ta
<RAOF> poolie: Incidentally: nice boot time!
<RAOF> poolie: Oh.  That dmesg seems to be truncated at ~6sec, which is before you hit the blank screen problem.
<twb> Can rmadison lag behind the actual pool?
<twb> Never mind, I found the problem.
<StevenK> twb: Yes, by up to 6 hours
<twb> (Somehow I accidentally uploaded one of my Debian packages to my company's in-house lucid apt archive.)
<twb> Probably happened a while ago and I only just noticed because it was i386-only, and only the router is still 32-bit.
<poolie> bryceh, do i need to wait for an updated xorg before i can apport-collect that data?
<bryceh> poolie, yep
<poolie> bryceh, would that be in natty-proposed already...?
<ScottK> lamont: Just uploaded postfix 2.8.2 to Natty.
<ScottK> poolie: No.  Nothing's there yet.
<bryceh> poolie, you're looking for xorg_7.6+4ubuntu2
<bryceh> poolie, or if you're in a rush, it's easy to fix locally
<bryceh> edit /usr/share/apport/package-hooks//source_xorg.py
<poolie> i'd be happy to just apply a patch or tweak it
<bryceh> around line 288
<bryceh>         "libgl1-mesa-dri*",
<bryceh> change to
<bryceh>         "libgl1-mesa-dri",
<poolie> k
<poolie> bryceh, ok, attachments attached; thanks
<poolie> hi ScottK
<ScottK> Hello poolie.
<ScottK> bryceh: Is that the same issue I just filed Bug 750967 about?
<ubottu> Launchpad bug 750967 in apport (Ubuntu) "Backtrace while attempting to report a bug" [Undecided,New] https://launchpad.net/bugs/750967
<poolie> scottk, i heard quite a different story about the python3 transition from allison the other day
<poolie> (i may have misunderstood)
<ScottK> Oh?
<poolie> but that was that basically packages did not seem very ready to go to python3 so it was unlikely ubuntu would drop python2 soon
<bryceh> ScottK, yep that's it
<poolie> if ubuntu is considering such a move that would obviously be a pretty strong motivation for bzr
<poolie> there aren't a lot of other reasons to move at this point
<ScottK> There's a lot of work to do, but I think it's achievable for 'P' if the project decides to focus on it.
<ScottK> Most of the major upstream stuff supports python3 (although we don't have it all properly packaged).  The major issue will, IMO, be the custom code that's used in Ubuntu only.
 * ScottK has no idea how hard a Python3 Ubiquity port would be.
<lifeless> ScottK: last I saw stats, most stuff *didn't* support python3 upstream
<lifeless> ScottK: but thats from a total population, not the 'we package it' subgroup
<ScottK> lifeless: In the broader python world I think that's true.  The stuff needed for a KDE/Gnome desktop though I think supports it.
<ScottK> I know PyQt and PyKDE do.
<ScottK> The Python3 stuff I've done has seen very little uptake, so it's still early going in the broader sense.
<ScottK> poolie: Wouldn't "Barry will haunt you if you don't go to Python3" be enough motivation?
<poolie> :)
<poolie> he is not the scariest ghost in the treehouse
<ScottK> True.
<ScottK> Upstream Python is, though, I think totally committed to Python3, so eventually if you want to do Python, you'll have to take the plunge.
<ScottK> If you're writing for python2.6 or later, it's pretty easy to also write stuff that is either valid python3 or 2to3 will handle.
<ScottK> So you can be 'working on it' even when you haven't decided to switch yet.
<poolie> scottk, that's true
<poolie> though, i wonder
<ScottK> So even if you aren't considering a near-term port, I think having coding standards that support making the eventual transition 'easy' are a good idea for now.
<poolie> if someone will fork py2.x if the transition is too hard
<poolie> yes
<ScottK> Maybe.
<poolie> i have no real evidence, i just wonder about it
<ScottK> Upstream's pretty clear that's the only way 2.8 would ever happen.
<ScottK> My experience so far is that code that's written with 2.6 features in mind is pretty easy.
<StevenK> I worry about the 3.x transistion for LP.
<ScottK> It will be "fun".
<StevenK> I think you're spelling it wrong.
<StevenK> ScottK: But, things like Zope, Twisted and Storm need to support it before we can consider it.
<ScottK> Yep.
<ScottK> It's a long term issue.
<ScottK> I still think coding standards to push to make compatibility easy when the time comes is what makes sense for now.
<StevenK> ScottK: The problem is that with Twisted, it wants to support a wide range of Python versions.
<ScottK> Yep.
<ScottK> I recently managed to convince the other maintainer on one project I'm working on to give up on python2.2.1 compatibility.
<StevenK> I don't remember 1.5 to 2.1 being this hard. :-)
<ScottK> It wasn't.
<lifeless> python had a psychotic break
<ScottK> python2 -> python3 is more discontinuous.
<ScottK> Not accidental though.  On purpose.
<didrocks> good morning
<Sweetshark> didrocks, all: good morning!
<didrocks> hey Sweetshark
<pitti> Good morning
<dholbach> good morning
<slangasek> mvo: hi there!  Have you seen that DonKult has a branch available that fixes bug #733741?  is it ok if I pluck the fixes in, or do you prefer to do so yourself?
<ubottu> Launchpad bug 733741 in apt (Ubuntu) "python-apt returns architecture == host arch instead of "all"" [High,Triaged] https://launchpad.net/bugs/733741
<mvo> slangasek: yeah, its on my radar, I want to upload it today
<slangasek> mvo: woohoo :-)
<mvo> slangasek: I want to look look at the other fixes in his branch too and coordinate with debian, but should be done today :)
<slangasek> mvo: cool :)
<buhl> Does anyone know why the beta1 is sooo much heavier on my system? - It's using three times more RAM idling...
<pitti> buhl: nvidia?
<buhl> pitti, Yes..
<pitti> buhl: that's bug 725434 then; we'll get it nailed for final one way or the other
<ubottu> Launchpad bug 725434 in cairo (Ubuntu Natty) "Nvidia drivers lead to extra memory usage for each process using libGL" [High,In progress] https://launchpad.net/bugs/725434
<buhl> pitti, Is there a temporary workaround?
<pitti> buhl: use nouveau?
<pitti> (perhaps with the experimental 3D drivers)
<buhl> pitti, Excuse me for maybe being a dumb-ass, but what's nouveau?
<infinity> buhl: The free nvidia driver.
<pitti> buhl: sorry; it's the default free driver for nvidia cards, i. e. what you get when you don't install the proprietary one in the "addidional hardware" app
<cjwatson> StevenK: the lag is no longer six hours; I believe the rmadison backend mirror updates hourly now
<pitti> buhl: in "additional drivers" you might also see the experimental nouveau 3D driver; worth giving them a shot :)
<StevenK> cjwatson: Neat!
<buhl> Pitti, So if i stop using the proprietary driver, it might work?
<pitti> buhl: the memleak will be gone, and 2D apps will still work; I don't know how well the 3D nouveau driver will work on your system, of course
<infinity> buhl: If you stop using the proprietary driver, it'll certainly fix this particular issue.  It may also, however, lead to other issues, depending on your chipset, and your usage patterns (ie: heavy 3D use)
<cjwatson> ScottK: python3 ubiquity> not desperately hard for oneiric, I think; the only real reason we were holding off was that it would commit us to shipping python3 on the CD
<infinity> buhl: The situation with nvidia and ati chipsets has always been a bit lose-lose in these cases.  The proprietary drivers work great until they explode, and there's little we can do about them except try to find a sweet spot, and due to lack of documentation, the free drivers always lag behind and seem a bit lackluster, especially on newer chips.
<cjwatson> bah, netsplit
<buhl> infinity, But as i'm using a relatively old chip, i might benefit from a free driver?
<infinity> buhl: Depends on how relatively old.  On the other hand, if you pretty much just do 2D/desktop type stuff, nouveau will probably be fine for you regardless.
<infinity> buhl: It pretty much just fails miserably at being a cutting edge 3D driver for, say, video gaming.
<buhl> infinity: I'm a student, so its mostly simulations and math-programs.. And its about 5 years old..
<infinity> doko: Mornin'.
<infinity> buhl: Well, as pitti says, one way or another, we'll find a solution to the non-free driver sucking, but there's no harm in you flipping to the free one, and if it does everything you need it to, win.  No need to worry about the binary pain.
<doko> infinity: you're in Europe?
<infinity> doko: No, but I assumed you were. :P
<doko> heh ...
<buhl> infinity, pitty: Thank you very much. Both of you! And i'm looking forward to benefit from your work!
<infinity> That was a long split.
<infinity> Clearly, we should have switched the free software world to AOL chat rooms a decade and a half ago.  This IRC thing's sketchy.
<cjwatson> ScottK: python3 ubiquity> not desperately hard for oneiric, I think; the only real reason we were holding off was that it would commit us to shipping python3 on the CD
<cjwatson> ScottK: so sort of wanted to make sure that the rest of the desktop would be switched over
<seb128> ev: hi, is there any web ui or something easy to use to query the ubuntu-geonames database?
<ev> seb128: http://geoname-lookup.ubuntu.com/?query=wandsworth
<seb128> ev: like bug #750395 points that lima, peru is not listed by the indicator not sure if that's a client or server side issue
<ubottu> Launchpad bug 750395 in Ubuntu Geonames "Missing/poorly prioritized entries in Locations dialog" [Undecided,New] https://launchpad.net/bugs/750395
<seb128> ev: ok, thanks, seems it's a server issue again :-(
<seb128> ev: is ubuntu-geonames being actively maintained? like is it worth waiting on those issues to be fixed or should we switch to another db?
<seb128> I'm close suggesting we switch to libgweather for the indicator since it has proved to be working and it's translated
<ev> seb128: the data is maintained by geonames.org.  They're, as far as I'm aware, the largest free source of that data.
<seb128> ev: well geonames.org does list lima,peru
<seb128> ev: it's the first match for "lima" on their site
<seb128> it's only one example, we got several bugs reported that happen on ubuntu-geonames but not on geonames.org
<ev> the existing database used by geoname-lookup.u.c uses a dump from last year (when it was created).  I can update that today and ask IS to merge the changes in.  I don't know if that will fix the problem though
<ev> it might be an issue with the way in which we query the database
<seb128> ev: if you could start by updated the database that would be great ;-)
<seb128> then we can try to figure what is wrong if there is still an issue
<ev> sure
<seb128> ev: thanks a lot!
<ev> no problem
<seb128> ev: and sorry to bother you about that, let me know if there is somebody else I should ping about ubuntu-geonames rather
<seb128> bug #740874 as well btw
<ubottu> Launchpad bug 740874 in Ubuntu Geonames ""Location" auto-complete menu doesn't know about San Francisco, USA" [Undecided,New] https://launchpad.net/bugs/740874
<ev> no, it's okay
<ev> I'll have a look
<Mez> Any release team here?
<Mez> (and active)
<Laney> Mez: #ubuntu-release is the hangout
<Mez> Laney: ah, didn't realise they had their own channel (though it makes sense)
<Laney> :-)
<ogra_> TheMuso, i mailed you the URL for the patches, did you get it ?
<Mez> o_O  Build logs say that the build was fine, but page says it failed to build
<cjwatson> URLs?
<Mez> https://launchpad.net/~mez/+archive/mez-mf/+buildjob/2428596
<elmo> Mez: look at the end of the build log
<elmo> or grep for http://wiki.debian.org/ImplicitPointerConversions
<Mez> elmo: Er... I didn't think ubuntu shipped for ia64?
<cjwatson> we sure as heck ship for amd64
<cjwatson> the problem is actually worse there, because it only happens sometimes
<cjwatson> (or worse in a sense, anyway)
<Mez> cjwatson: :( I've never seen it happen on that package... which is a shame...
<cjwatson> just fix the bug
<cjwatson> it's not that hard and it will make your package more robust
<Mez> cjwatson / elmo - maybe make it a little bit clearer - so that it mentions that it's a failed build.
<cjwatson> it does, it says "Failed to build" in red letters on the build page
<Mez> cjwatson: In the build log - it just says "these are errors" - not "failed to build because of this"
 * Mez shrugs
<cjwatson> it's hard to do better with the way gcc works
<cjwatson> most people get the habit of scrolling down immediately to the end of the build log, anyway
<cjwatson> if you think the text could be improved, file a bug on launchpad-buildd
<cjwatson> (neither elmo nor I work on that code)
<Mez> cjwatson: unfortunately, that error's actually in gtk... not in the package :(
<infinity> Mez: So fix GTK?
<cjwatson> Mez: no it isn't, it's in your package's *copy* of bits of GTK
<cjwatson> (as far as I can see)
<cjwatson> gtk+2.0 builds fine
<mr_pouit> ./query-browser/source/linux/gtksourceview/gtksourceview/gtksourceview.c
<cjwatson> in fact, gtksourceview.c is not part of GTK at all
<Mez> cjwatson: yes... that's not... It does seem however, that it's either a) not including the right file or b) had the definition in the header moved.
<cjwatson> Mez: not including the right file is a standard reason for this problem.
<Mez> cjwatson: is another one -GDK_DISABLE_DEPRECATED ? :P
<cjwatson> Mez: sure, anything that causes the prototype to go away.
 * Mez attempts to shove up a new copy
<Mez> :( Direct sync from Debian wont work either (until I push up changes to debian)
<infinity> Incentive to push changes back to Debian doesn't sound like something worth frowning over...
<Mez> infinity: long time no speak - but yeah - no - I don't mind pushing the changes to debian - but that adds time to it - meaning it might get to a point where I have to try and do an SRU rather than a bugfix before :D
<chrisccoulson> @pilot out
<chrisccoulson> oops ;)
<chrisccoulson> oh
<chrisccoulson> Current Friendly Patch Pilots: chrisc
<chrisccoulson> hmmm :/
<chrisccoulson> who is chrisc? ;)
<Pici> probably the person whose name is too long for the topic ;)
<pitti> SpamapS: ah, someone already added you to core-dev (I was just about to do it, as I saw the official mail from DMB); congratulations!
<cjwatson> Mirv: for bug 747090, are you using kvm by any chanc?
<ubottu> Launchpad bug 747090 in gfxboot-theme-ubuntu (Ubuntu Natty) "No translations in natty" [High,Confirmed] https://launchpad.net/bugs/747090
<cjwatson> *chance
<Mirv> cjwatson: yes I am... I can boot from USB in a moment instead. if that bug only hits kvm users and not "real" users, it's quite evil bug :S
<cjwatson> Mirv: if you wouldn't mind trying, I'd appreciate confirmation that it doesn't affect bare-metal boots.  I think I've narrowed it down to a kvm bug, and I've certainly confirmed that it affects kvm for me but not qemu -no-kvm
<cjwatson> (and I have a rationale, because I appreciate that that's an extraordinary claim ...)
<Mirv> cjwatson: confirming that everything works fine when booting an actual computer
<cjwatson> Mirv: excellent - writing a long rationale for reassigning to qemu-kvm now
<Kaleo> Riddell: have you observed that bug where Qt apps have bold fonts everywhere? https://bugs.launchpad.net/ubuntu-font-family/+bug/751048
<ubottu> Ubuntu bug 751048 in Ubuntu "QT applications render with bolder font" [Undecided,New]
<Kaleo> Riddell: it's quite recent, maybe 2 weeks
<Kaleo> Riddell: I suppose it's a dupe of https://bugs.launchpad.net/ubuntu/+source/qt4-x11/+bug/741862
<ubottu> Ubuntu bug 741862 in qt4-x11 (Ubuntu) "Default interface font is too bold in all Qt4 applications" [High,Confirmed]
<Riddell> Kaleo: I haven't seen that no
<Shawn727> Anyone need help?
<Shawn727> Im here to help
<tjaalton> who's in charge of libburn / libisoburn packages? they are rather old (0.8.0 / 0.5.6), there is 1.0.4 in wheezy
<tjaalton> interested in BD-* media support
<cjwatson> tjaalton: feature freeze, no?
<tjaalton> cjwatson: yes :)
<Shawn727> ?
<tjaalton> but there's been bug 685600 open for months
<ubottu> Launchpad bug 685600 in libburn (Ubuntu) "Several new bugfix versions of libburn were released since 0.8.0.pl00, please update Ubuntu packages" [Wishlist,New] https://launchpad.net/bugs/685600
<cjwatson> IIRC we were more or less in sync with Debian at feature freeze; of course, Debian was itself frozen at that point
<tjaalton> right
<tjaalton> 1.0.0 was released on jan 17th
<Laney> 1.0.4 was uploaded into Debian on March 13
<Laney> which is almost three weeks after FF started
<tjaalton> ah, so it was bumped from 0.8.0 directly
<soren> cjwatson: Are you on intel or AMD hardware (for that "gfxboot" bug)?
<cjwatson> soren: Intel
<soren> cjwatson: ok.
<cjwatson> I've posted /proc/cpuinfo to the bug
<jpds> slomo: bug #751343 - is interesting.
<ubottu> Launchpad bug 751343 in gst-plugins-ugly0.10 (Ubuntu) "package gstreamer0.10-plugins-ugly 0.10.17-1 failed to install/upgrade: trying to overwrite '/usr/share/locale/af/LC_MESSAGES/.mo', which is also in package gstreamer0.10-plugins-bad 0.10.21-1ubuntu10" [High,Triaged] https://launchpad.net/bugs/751343
<slomo> jpds: already fixed, sorry for the trouble
<SpamapS> pitti: ty! :)
<SpamapS> pitti: actually I already uploaded something to lucid-proposed. :)
<pitti> SpamapS: nice!
<SpamapS> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Natty Beta-1 released! | Archive: Feature/UI freeze | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for dapper ->  maverick | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs | Current Friendly Patch Pilots: chrisc, Spamap
<Laney> topic limit eh
* Laney changed the topic of #ubuntu-devel to: Natty Beta-1 released! | Archive: Feature/UI freeze | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for dapper ->  maverick | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs | Current Friendly Patch Pilots: SpamapS
<cjwatson> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Natty Beta-1 released! | Archive: Feature/UI freeze | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for dapper ->  maverick | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs | Current Friendly Patch Pilots: SpamapS, cjwat
* cjwatson changed the topic of #ubuntu-devel to: Archive: Feature/UI freeze | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for dapper ->  maverick | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs | Current Friendly Patch Pilots: SpamapS, cjwatson
<cjwatson> dholbach: I know you like it all fluffy and all, but can we make that just "Patch Pilots:"?  topic space is very limited
<hallyn> ok, this is disconcerting: i just wget'ed natty-alternate-amd64.iso, burned it, and it hangs on parted_server
<cjwatson> hallyn: /var/log/syslog /var/log/partman please
<cjwatson> hallyn: or a repro case
<cr3> hi folks, under what circumstance does a -proposed Packages.bz2 file contain a reference to a package which does not appear under archive.ubuntu.com/ubuntu/dists...
<dholbach> cjwatson, I'm not opposed at all - I think it was ogra's fault
<dholbach> ;-)
<Laney> we could change the middle bit to "Development of Ubuntu (not support [#ubuntu], not app development [#ubuntu-app-devel])"
<ogra_> hey, use aa fluffy font at least :P
<hallyn> cjwatson: repro case?  get a vostro laptop and try to install :)
<hallyn> lemme get a usb stick to copy those files over
<dholbach> tsimpson, do you think the bot could make it "Patch Pilots:" instead of "Current Friendly Patch Pilots:"?
<hallyn> i don't see any obvious errors though (just cat'ing it)
<cr3> specifically, linux-image-2.6.35-28-generic does not seem to appear in maverick-updates when running apt-get update + dist-upgrade
<cyphermox> hallyn, what kind of Vostro laptop?
<hallyn> cjwatson: I'll upload these to a bug.  What should a file bug against?
<hallyn> cyphermox: 1220
<hallyn> i'll file against debian-installer
<cjwatson> hallyn: debian-installer is fine, yes
<cjwatson> hallyn: "get a vostro laptop" is not much good to me for debugging :)
<hallyn> :)
<hallyn> cjwatson: bug 751449
<ubottu> Launchpad bug 751449 in debian-installer (Ubuntu) "natty install on vostro 1220 hangs at partman" [Undecided,New] https://launchpad.net/bugs/751449
<ogasawara> could I get an archive admin to accept the linux-meta and linux-backports-modules-2.6.38 packages for i386 and amd64 in the New queue?
<cr3> turns out the problem is that linux-image-generic is not contained in Packages.gz in the current maverick-proposed archive whereas a more recent linux-image package is available in the archive, might anyone know if there's a reason for that?
<cr3> nevermind folks, found the linux-image-generic package under maverick-security. my mistake, I looked under maverick-updates just in case
<cjwatson> cr3: it's in maverick-updates too
<cjwatson> cr3: packages are removed from -proposed shortly after they're promoted to -updates
<cr3> cjwatson: good to know, thanks!
<cr3> will a sru always land in -security or might it be possible that it only lands in -updates?
<tsimpson> dholbach: it was, but someone asked me to change it to friendly patch pilots
<cjwatson> cr3: SRUs don't land in -security; only security updates (a different process) land in -security
<brendand> cjwatson - why is linux-image-2.6.35-28-generic in -updates? isn't that the current SRU?
<brendand> cjwatson - at least according to the tracking page
<dholbach> tsimpson, maybe we can change it back? :-D
* tsimpson changed the topic of #ubuntu-devel to: Archive: Feature/UI freeze | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for dapper ->  maverick | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs | Patch Pilots: SpamapS, cjwatson
<tsimpson> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Archive: Feature/UI freeze | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for dapper ->  maverick | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs | Patch Pilots SpamapS, tsimpson, cjwatson
<tsimpson> @pilot out
<udevbot> An error has occurred and has been logged. Please contact this bot's administrator for more information.
<tsimpson> yay! :(
<dholbach> glad we have the bot's administrator here :)
<cjwatson> brendand: according to the tracking page, the update currently being validated is 2.6.35-28.50, and the previous version was 2.6.35-28.49.  Both of those built a linux-image-2.6.35-28-generic binary package
<tsimpson> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Archive: Feature/UI freeze | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for dapper ->  maverick | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs | Patch Pilots SpamapS, tsimpson, cjwatson | Patch Pilots:
<tsimpson> *sigh*
<cjwatson> brendand: if you use rmadison (in the devscripts package), you'll get a table with versions
* tsimpson changed the topic of #ubuntu-devel to: Archive: Feature/UI freeze | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for dapper ->  maverick | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs | Patch Pilots: SpamapS, tsimpson, cjwatson
<tsimpson> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Archive: Feature/UI freeze | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for dapper ->  maverick | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs | Patch Pilots: SpamapS, cjwatson
<tsimpson> ok, no more spam from me :)
 * dholbach hugs tsimpson
<brendand> cjwatson - it seems there is no linux-image-generic package in -proposed, which is meaning the dist-upgrade is not seeing anything
<cjwatson> brendand: there doesn't need to be - the linux-image-generic package in -updates is sufficient, since its dependencies don't need to change
<cjwatson> linux-image-generic just depends on linux-image-2.6.35-28-generic, and doesn't actually ship any significant files itself
<cjwatson> and all systems with -proposed in sources.list must also have -updates in sources.list
<cr3> brendand: aha! so the problem is that we only had maverick and maverick-proposed, no maverick-updates so we didn't get the latest linux-image-generic package
<cr3> I'm not sure how I feel about having to perform a whole upgrade in order to perform sru testing on each system
<cjwatson> such a configuration will certainly cause problems, yes
<cjwatson> you don't have to; you can install just the packages you're testing, if you like
<cr3> perhaps a compromise would be to add -updates but only dist-upgrade linux-image-generic rather than dist-upgrade without arguments
<cjwatson> 'install linux-image-generic', not 'dist-upgrade linux-image-generic' - dist-upgrade doesn't take arguments
<cjwatson> (although bear in mind that most users will have fully upgraded; ideally, our testing should match their configuration)
<hallyn> anyone know of an irc channel relevant to libpciaccess?
<brendand> cr3: so why did it work on the laptops?
<cr3> cjwatson: sru testing mostly consists of making sure the hardware is still supported, so that's mostly kernel related but not fully related
<cjwatson> maybe the laptops were already upgraded to some vintage of -updates
<brendand> cjwatson - they went through the same process as the servers
<brendand> cjwatson - something for us to worry about
<cr3> brendand: maybe linux-image-generic happened to be in the maverick-proposed Packages.gz file yesterday
<cjwatson> that's quite possible; the removal is semi-manual
<dylan-m> didrocks, are you about? :)
<didrocks> dylan-m: yeah
<dylan-m> Yay! I'm just wondering what's going on with bug #749428 :)
<ubottu> Launchpad bug 749428 in unity "When we press Enter to run the first search result, Unity should wait until searching is finished" [Medium,In progress] https://launchpad.net/bugs/749428
<dylan-m> You were wondering what I was babbling on about, and then all of a sudden it looks like you had it under control. Do you still need any clarification?
<dholbach> hey dylan-m
<dholbach> how are you doing?
<dylan-m> Hi dholbach! I'm doing pretty well. Need to stop writing patches for things, though; lots of other stuff to doâ¦ :b
<dholbach> haha - I can imagine :)
<highvoltage> howdy dylan-m and dholbach
<dholbach> hey highvoltage
<dylan-m> Hi highvoltage!
<cjwatson> Keybuk: reading bug 707479 - is there anything in https://code.launchpad.net/~clint-fewbar/ubuntu/natty/upstart/upstart-job-change-restart/+merge/52547 that you object to?  it's only changing the effect when called in a SysV kind of way rather than an Upstart kind of way, and the proposed behaviour seems more SysV-compatible to me
<ubottu> Launchpad bug 707479 in upstart (Ubuntu) "service <service> restart does not use an updated job configuration" [Medium,Triaged] https://launchpad.net/bugs/707479
<SpamapS> cjwatson: o/ thanks for taking another look at that btw. :)
<cjwatson> (I don't know if you've already discussed this with Clint on IRC, but since there's no record of a discussion I wanted to check)
<cjwatson> jhunt_: ^ FYI
<Keybuk> cjwatson: I haven't seen that patch
<Keybuk> but I think I may have told Clint that I thought doing that was the right fix
<Keybuk> (making "service" behave SysV-y)
<cjwatson> right, thanks - I just wanted to check that there wasn't contention about that part that I was misssing
<cjwatson> *missing
<cjwatson> since the original report in #707479 did mention service(8)
<Keybuk> no, I definitely think that's the right way to bridge the behaviours
<cjwatson> ok, excellent - thanks!
<Keybuk> right, but the original report was on upstream
<Keybuk> which doesn't contain service(8)
<cjwatson> ah, I missed that
<Keybuk> the Ubuntu task was left open, because it does
<cjwatson> it's never very clear in LP bug history
<Keybuk> Launchpad makes it too damned hard to see that subtlety
<cjwatson> jhunt_: can you merge the branch discussed above for your next Ubuntu upstart upload, then, if you also agree with it?
<jhunt_> cjwatson: ok - taking a look at it now...
<SpamapS> could somebody add me to ubuntu-sponsors so I can unsubscribe bug #712614 from it? thanks!
<ubottu> Launchpad bug 712614 in util-linux (Ubuntu) "getty can't execute a login program with arguments" [Undecided,Incomplete] https://launchpad.net/bugs/712614
<mvo> dpm: when is the next langpack update planned? there is a issue with file overwrites that is showing in the auto-upgrade-tester but that is fixed in langpack-o-maitc
<cjwatson> kees,TheMuso,nhandler: ^- request for ubuntu-sponsors addition from SpamapS above; you're all administrators
<Laney> shouldn't we just have ubuntu-dev as a member of ubuntu-sponsors?
<SpamapS> Laney: that would make a lot of sense. :)
<Laney> I think there were some counter-arguments, but don't remember what they are
<cjwatson> I think there was a desire to have ubuntu-sponsors be people who were actually active in sponsoring
<SpamapS> Was that pre-pilot? Seems like most devs are active in that on some level.
 * Laney doesn't share that desire: every dev /can/ sponsor, and most will want to at some point
<lool> mvo: WRT LP #733741, does python-apt also need a rebuild before the fix is visible?
<ubottu> Launchpad bug 733741 in Linaro Image Tools "python-apt returns architecture == host arch instead of "all"" [High,New] https://launchpad.net/bugs/733741
<juliank> lool: No.
<juliank> Although it still returns amd64 here.
<lool> mvo, juliank: You two have any clue where this might come from?
<lool> I could ask james_w whether he has a smaller test case
<Keybuk> kees, cjwatson, pitti, mdz: ok, so now I'm officially confused about when the Tech Board meeting is supposed to be
<kees> SpamapS: added!
<lool> james_w: I'm still seeing the APT multiarch regression with linaro-image-tools testsuite and latest APT; do you have a reduced testcase?
<juliank> lool: apt_pkg.Cache()["python-apt-common"].architecture should be all, right?
<kees> Keybuk: 1800UTC.  Which is 11am on the US west coast.
<SpamapS> kees: dekujume moc! :)
<Keybuk> kees: but it was 11am during the timezone screwage too?
<kees> Keybuk: when DST changed, it went from 10am to 11am for us.
<lool> juliank: Yup; I get amd64 here; I wonder whether it could relate to file:// URIs?
<Keybuk> kees: ah, and there is no intent to change it to be 6pm London time again?
 * lool needs to run to a phone call
<dylan-m> Hey, highvoltage, I think your change for the Edubuntu installer slideshow is mostly new strings, with just five existing translations actually changed (not counting removals). Is that correct?
<cjwatson> Laney: yeah, it's possible that this is an obsolete requirement
<kees> Keybuk: no, tb moved to UTC about 6 months ago because it's not sane to tie it to anything else.
<Keybuk> kees: well, if you and I agree on 11am, we have Quorum, so can just decide things by ourselves <g>
<kees> Keybuk: heh I'm not sure "2" is enough, but it is UTC, and we did set it to 1800. :)
<Keybuk> kees: 2 was always good enough in the old days ;-)
<kees> heh
<mvo> lool: its possible that a rebuild is needed, iirc is some of this inline code
<juliank> lool: mvo: Yes, with a rebuild we get All -- but only on versions, on packages it remains the native architecture.
<cjwatson> Keybuk: 2 was good enough when there were 4 board members :)
<pitti> kees, Keybuk: FWIW, any earlier hour is greatly appreciated
<pitti> so +1 for moving earlier
<lool> mvo juliank: Would you like me to upload a nochange rebuild?
<kees> pitti: let's discuss it with mdz and sabdfl; they had the tightest schedules.
<Keybuk> I was going to say how much I liked 11am because it's further away from breakfast than previous times ;-)
<mvo> lool: sure, thats fine, I can do it as well in a little bit
<Keybuk> 9.30am is probably the earliest time I can guarantee attending though
<mdz> kees, my understanding is that it's fixed to UTC
<kees> I would prefer to keep it at 11am so when it moves back an hour I can still show up for it.
<kees> mdz: yup.
<mdz> and I plan to be there at 1900 BST during the summer here
<hallyn> gah.  how do i unmark a bug as dup?
<hallyn> phew
<kees> hallyn: change it and delete the number
<Keybuk> pitti: this isn't a "I don't like getting up early" restriction btw - this is a "FreeNode won't let me connect from G-Bus WiFi" problem
<hallyn> kees: thx :)  i often fail to notice that little icon
<kees> hallyn: yeah, took me a while to see it too
<SpamapS> clint     2199  0.8 46.2 2932304 1866600 ?     Sl   Mar30  63:53 compiz
<SpamapS> youch
<SpamapS> clint     2199  0.8  3.7 650508 150088 ?       Sl   Mar30  63:56 compiz
<SpamapS> heh.. post -HUP
<juliank> mvo: Now we have a situation where two programs compiled against different apt versions have different results without an official API break. I don't really like that.
<juliank> mvo: We should try to remove inline code as much as possible in apt 0.8.14
<mdz> juliank, except where it kills performance of course ;-)
<juliank> mdz: Actually, performance should be nearly identical between function calls and inlined code, as most of the time in apt is spent reading files on start
<mdz> juliank, I notice performance in some other areas, at least on my Atom netbook
<Keybuk> juliank: err
<Keybuk> juliank: performance would be massively different between inlines and function calls
<Keybuk> relative time spent in individual activities might not be affected so much, if the majority is I/O
<Keybuk> but that's quite a different thing
<mvo> for the resolver it does matter, for readng list file stuff not so much
<Keybuk> and there are plenty of processors out there which *do* care about sheer number of operations and stack changes
<mdz> Keybuk, yes, I assumed that was what juliank meant
<juliank> Well, if we spent 1 second for initializing apt and then 100ms for processing data, it does not matter if we spent 200 ms instead.
<lool> mvo, juliank: Uploaded; thanks
<cjwatson> it's funny how ideas about performance stick around.  for ages I had a bit set that linking against additional libraries was bad on i386 because of register starvation; while actually this may be true for the *first* library, but once you've linked against libc it doesn't make a whole lot of difference :)
<juliank> And a function to return an architecture name does not need inlining, as far as I know, it's not used in solvong
<cjwatson> (unless you're openoffice or something and are linking against two zillion libraries)
<sabdfl> kees, pitti, Keybuk, mdz: i fear i'm adding less and less value and making the schedule more and more complicated
<Keybuk> juliank: it depends, if you do that 100ms ten times then it does matter
<juliank> cjwatson: Another interesting performance thing is that gcc -O3 optimizes array accesses so badly, that using functions compiled with -O2 is much faster
<Keybuk> optimisation such as inlining and replacement can turn that 1s back into 100ms or less
<Keybuk> juliank: -O3 is slower than -O2 is almost a universally known truth about gcc (but less true as gcc gets better)
<cjwatson> juliank: heh, interesting; I can't say I'm surprised about issues with -Ogentoo, mind you :-)
<mdz> juliank, I completely agree that we should be able to remove problematic inlining without significantly affecting performance, and we should do that. :-)
<Keybuk> cjwatson: I thought -Ogentoo was -O4
<cjwatson> (OK, -Othelesscluefulofgentoousers)
<Keybuk> because they were using -O4 when gcc only went up to 3 ;-)
<mdz> I just didn't want to ignore performance completely, because I think some of the inlines may make a difference
<cjwatson> Keybuk: I think that was -O6, but same deal
<juliank> Keybuk: Yes. But code should not be inlined just because it is short, only if it is performance critical. In APT, many inline functions are not performance-critical
<Keybuk> juliank: if they are not performance-critical, the compiler will probably ignore the "inline"
<cjwatson> inlining: profile profile profile
<cjwatson> (since excessive inlining can kill i-cache locality)
<Keybuk> juliank: the "inline" keyword isn't so much of a rule as a guideline to the compiler
<Keybuk> (at least I'm pretty sure that's true in C++ too, but I'm rusty and frankly the C++ standard scares me :p)
<juliank> Keybuk: In short: Code should not be in the header file, but in the .cc file; unless it is extremely important for performance
<mdz> juliank, +1
<juliank> cjwatson: Doesn't gcc 4.6 have a new option called -Ofast or something like this?
<mdz> juliank, and I'd add (with a nod to cjwatson) that means "we've measured it"
<lasha> guys anyone knows good system cleanup tool? please help I need to know how to cleanup trash :|
<SpamapS> lasha: #ubuntu would be a better place to ask
<juliank> lasha: This is a development channel, not a support channel
<lasha> hmm ok guys, I just had trouble getting answer there :)
<lasha> how can i help in development though, I know java
<highvoltage> dylan-m: the strings didn't really change, it was icons that somehow didn't get into the last merge. so now we just have placeholders for some images where it should be the proper icons
<highvoltage> dylan-m: but string changes should be quite minimal, if any, yes
<ogra_> lasha, https://wiki.ubuntu.com/ContributeToUbuntu
<ogra_> and https://wiki.ubuntu.com/UbuntuDevelopment
<dylan-m> highvoltage: Okay, thanks. Something fishy going on with my revision history, then; my diff says there were a bunch of changes in the new .pot file, but the (awesome as always) Spanish translation has just about everythingâ¦
<dylan-m> I think it will all sort itself out when it gets uploaded :)
<lasha> ok thank you ogra_
<highvoltage> dylan-m: ok, great.
<highvoltage> dylan-m: I'll test it as soon as it's in the archive, so if something isn't quite right there will be a little time to find it
<lasha> ogra_ #ubuntu-beginners-dev hehehe :P
<cjwatson> ogasawara: sorry for the delay.  done.
<ogasawara> cjwatson: awesome, thanks
<cjwatson> mvo: does https://code.launchpad.net/~evfool/update-manager/fix150677/+merge/55874 look OK to you?
<cjwatson> (actually, there seem to be a few outstanding u-m branches from evfool)
<cjwatson> kirkland: did you notice bug 700511?  it has a question directed at you
<ubottu> Launchpad bug 700511 in vgabios (Ubuntu) "[Regression] Widescreen resolutions are missing from vgabios, breaking widescreen in qemu" [Undecided,New] https://launchpad.net/bugs/700511
<kirkland> cjwatson: i hadn't notice, i'll look at it now
<kirkland> cjwatson: fwiw, hallyn is more or less maintaining that now
<kirkland> hallyn: let's take a look at https://bugs.launchpad.net/ubuntu/+source/vgabios/+bug/700511
<ubottu> Ubuntu bug 700511 in vgabios (Ubuntu) "[Regression] Widescreen resolutions are missing from vgabios, breaking widescreen in qemu" [Undecided,New]
<cjwatson> kirkland: *nod*
<cjwatson> hallyn: (speaking of which, sorry for today's horrible kvm bug report ;-) )
<hallyn> cjwatson: that is a bad one :)
<hallyn> cjwatson: unfortunately libvirt looks likely to keep me occupied today
<cjwatson> yeah, that's ok
<hallyn> broken in every release
<cjwatson> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Archive: Feature/UI freeze | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for dapper ->  maverick | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs | Patch Pilots: SpamapS
<cdbs> Hello all, it appears someone tried to snatch control of my IRC account
<cdbs> I can see some sent messages to this channel
<cdbs> Anyone has a backlog? Sorry in advance
<cdbs> sent messages means the attacker probably tried to send messages here in my name
<Pici> cdbs: huh?
<geser> http://irclogs.ubuntu.com/ has the logs of all logged Ubuntu channels
<geser> cdbs: didn't you protect your nick or did someone guess your password?
<cdbs> geser: Neither, it appears when I got disconnected and moved to cdbs_ someone connected with cdbs
<cdbs> geser: Even without the NickServ password NickServ allowed him to come up with my nick
<cdbs> and I can see myself banned from some non-Ubuntu channels
 * cdbs moves discussion to -ops
<geser> do you enforce identification with nickserv?
<cdbs> geser: I just set that now
<cdbs> wasn't set before
<cdbs> okay, enough offtopic discussion on a -devel channel
<SpamapS> pitti: remind me again, its ok for me to sponsor an upload to lucid-proposed and then review it for acceptance into lucid-proposed, right?
<slangasek> SpamapS: there's no firm policy against it, but I've always tried to be arms-length about sponsor vs. SRU accept (or RM / archive admin accept)
<slangasek> I guess it depends how much you trust that your eyeballs are sufficient :-)
 * SpamapS is constantly suspicious of his eyeballs
<Keybuk> are you saying there's something wrong with cowboying a package through NEW, and then straight into main? :-)
<Keybuk> (yee-haw)\
<SpamapS> slangasek: btw, I'd like to get back to the work of fixing Debian policy so we can start putting upstart jobs in debian packages. You sent me a checklist which I still have.. has the TODO changed any?
<pitti> SpamapS: as slangasek said, there's no firm rule; I used to do sponsoring and SRU accepting for the same patch as well, though
<pitti> (as both is pretty much "review that it's sane etc.")
<pitti> Keybuk: don't we all? all this bureaucracy ... :)
<slangasek> SpamapS: I don't have that todo list in front of me; the high level where-are-we is Debian bug #591791 against policy
<ubottu> Debian bug 591791 in debian-policy "extend init.d policy to permit upstart jobs and describe their use" [Wishlist,Open] http://bugs.debian.org/591791
<slangasek> I think I may have done something from that list since then, but I don't remember what :)
<slangasek> or maybe I just dreamt of doing something
<SpamapS> I dream of a day where upstart jobs and debian developers live in harmony. ;)
<SpamapS> slangasek: ty.. I'll take a look at the todo again and see if there's something I can get done in the early weeks of oneiric.
<slangasek> yay
 * cjwatson finds and kills another of the N reasons Wubi breaks for people
<cjwatson> only N-1 to go
<cjwatson> now if only I knew the value of N
<Keybuk> cjwatson: since we're in an expanding universe, the value of N increases at the speed of light
<Keybuk> so, kill faster
<cjwatson> doh
<mvo> cjwatson: indeed, I'm a bit behind there, I will go over the u-m branches now (or tomorow morning)
<cjwatson> mvo: great, thanks
<psusi> cjwatson: how about that new partman script hanging on my system problem now? ;)
<cjwatson> I'm afraid I have my own to-do ordering
<cjwatson> and all the other things on it are beta-critical too :-P
<psusi> hehe
 * psusi needs a shell debugger so he can step though that thing
<cjwatson> set -x
<psusi> hrm...  guess that's what I'llbe doing tonight...
<cjwatson> hallyn_afk: any chance of you doing SRU verification on bug 687501?
<ubottu> Launchpad bug 687501 in grub2 (Ubuntu Maverick) "when installer is multipath aware, grub fails to install" [High,Triaged] https://launchpad.net/bugs/687501
<cjwatson> (the lucid task)
<cjwatson> I suppose I should backport that to maverick too :-/
<hallyn_afk> cjwatson: i haven't got the hardware any more
<cjwatson> drat
<hallyn_afk> dannf: ^ any chance you'd hae time for that?
<cjwatson> I'll try to track down Peter
<dannf> hallyn_afk: i'll take a look
<hallyn_afk> thanks!
<cjwatson> looks like I did the maverick backport in a PPA but never uploaded it to -proposed
<cjwatson> I'll rectify that now
<dannf> cjwatson, hallyn: what exactly should i test - that upgrading to the proposed grub2 lets me install/reboot on an existing lucid/mpath system, or do i need to try something at installtime?
<cjwatson> I think ideally we want to make sure that it handles fresh install correctly
<cjwatson> it should be sufficient to put apt-setup/proposed=true on the kernel command line for a lucid netboot install
<dannf> cool
<dannf> yup - i can do that
<cjwatson> maverick-proposed version uploaded now too, waiting for approval
<hallyn> cjwatson: regarding bug 700551 - the patch in the patch in the patch doesn't apply :)  Is it safe to just add any of the modelines which it adds back into vbetables-gen.c, as far as you know?
<ubottu> Error: Launchpad bug 700551 could not be found
<hallyn> 700511 i guess
<hallyn> eh, will assume it is
<cjwatson> hallyn: not sure really, I was just being patch pilot
<cjwatson> hallyn: I guess so though
<hallyn> cjwatson: yup, building the package, will test.  thanks.
<hallyn> here's a q - is there a good reason why 'bzr uncommit' doesn't remove any tags pointing to the commit being undone?
<hallyn> oh, bc of looms or somesuch i suppose?
<cjwatson> the revision still exists in the repository, and can be accessed again
<cjwatson> in fact, you might still have another branch pointing to it
<cjwatson> uncommit just winds back the current branch
<ohsix> anyone have some pointers on debugging icedtea/appletviewer?
<ohsix> been having lots of trouble with it lately; the applet uses native code though
<SpamapS> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Archive: Feature/UI freeze | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for dapper ->  maverick | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs | Patch Pilots:
<SpamapS> oh noes.. no pilots! we're gonna crash!
<ari-tczew> SpamapS: who cares :)
<SpamapS> did we intentionally break runlevel 1 -> 2 transitions in the upstart conversion? Seems that many many upstart jobs 'stop on runlevel [!2345]' but do not start on runlevel [2345]
<seb128> slangasek, hey
<slangasek> seb128: hi there
<seb128> slangasek, how are you?
<slangasek> good! you? :-)
<seb128> I'm fine thanks
<slangasek> (what did I break? :-)
<seb128> slangasek, does https://bugs.launchpad.net/ubuntu/+source/glib2.0/+bug/751940 makes any sense to you?
<ubottu> Ubuntu bug 751940 in glib2.0 (Ubuntu) "Problems with cmake in Ubuntu Ubuntu >= 11.04 (Natty Narwhal)" [Undecided,New]
<slangasek> oh, cmake - yes, I broke that ;-)
<seb128> slangasek, should I reassing to cmake? is there a known bug?
<SpamapS> on purpose? :)
<slangasek> SpamapS: in the sense that cmake consumers make buggy assumptions which multiarch will not tolerate, yes :-)
<slangasek> seb128: whatever owns cmake/FindGTK2.cmake, yes
<SpamapS> cmake and buggy builds seem to go hand in hand
<slangasek> seb128: this ought to use pkg-config as the abstraction
<seb128> slangasek, cmake-data says dpkg
<slangasek> seb128: FindGTK2.cmake does appear to be part of cmake-data; I'll reassign with explanation
<seb128> slangasek, thanks!
<seb128> slangasek, bug #744910 btw might be yours as well
<seb128> slangasek, well "yours" as a consequence of multiarch update
<seb128> https://bugs.launchpad.net/ubuntu/+source/avahi/+bug/743438
<ubottu> Error: Launchpad(https://launchpad.net) bug 743438 not found
<seb128> bah
<seb128> bug #744910
<ubottu> Launchpad bug 744910 in avahi (Ubuntu) "avahi-discover crashed with error in __init__(): (2, 'No such file or directory') (dup-of: 743438)" [Undecided,New] https://launchpad.net/bugs/744910
<ubottu> Launchpad bug 743438 in avahi (Ubuntu) "avahi-discover crashed with error in __init__(): (2, 'No such file or directory')" [Undecided,New] https://launchpad.net/bugs/743438
<seb128> slangasek, I'm pointed the duplicate on purpose since it has details
<seb128> it has a patch as well which is wrong but shows where the issue is ;-)
<lool> slangasek: One of the apt issue went away, but most regressions are still here sadly
<lool> slangasek: I filed a new bug (LP #751961) to track them
<ubottu> Launchpad bug 751961 in Linaro Image Tools "Testsuite regressions in hwpack module (with multiarch APT?)" [Undecided,New] https://launchpad.net/bugs/751961
<Tetsuo55> pitti: hello, yofel told me to ask you about the retraces
<Tetsuo55> pitti: most of the time retraces for my bug reports are too late (some update has occured and the trace fails)
<Tetsuo55> pitti: isn't there anything we can do about this? it often takes a few days for the scan to occur so it will often fail this way
<pitti> Tetsuo55: yeah, unfortunately the retracers break very often, it's quite a lot of maintenance
<pitti> Tetsuo55: not much, I'm afraid
<Tetsuo55> they seem to be critical for even taking the bug at all seriously
<Tetsuo55> i have no idea how the retrace bots? work, but it would seem to me that if retraces are required to accept bug reports that canonical would invest more into making them faster and more stable?
<yofel> pitti: how much work would it be to make  at least apport-cli able to retrace a crash before filing it? At least giving the option to refresh the attached stacktrace if you install more debugging symbols
<yofel> or can you file bugs with apport-retrace?
<pitti> yofel: you can not report the crash through the ui, then run apport-retrace locally on the .crash file, and then submit the updated .crash file through ubuntu-bug
<pitti> it's not nicely integrated into the UI, but at least works
<pitti> note that with apport-retrace it's rather easy to break your installed packages
<pitti> it's mostly designed to work in chroots
<yofel> ah ok, thanks
<slangasek> seb128: waah, why does avahi have to use a non-portable database format (gdbm)
<slangasek> maybe I should just roll back the multiarch change to avahi... it was only uploaded to natty by accident anyway
<seb128> slangasek, I've no strong opinion either way but we should at least make sure it's reported upstream we will need that fixed next cycle
<seb128> slangasek, btw do you have a tag or something to track multiarch issues?
<slangasek> seb128: sure, I'm using 'multiarch'
<seb128> slangasek, ok, that one just won this tag then ;-)
<slangasek> thanks :)
<seb128> thank *you* ;-)
<slangasek> I think the quickest fix is to make python-avahi arch: any
<slangasek> and properly populate the .py.in at build time
<slangasek> so let's do that
<micahg> slangasek: do you want me to get multiarch to be an official distro tag?
<slangasek> micahg: that seems like a reasonable thing to do
<micahg> ok, will bring up at the bugsquad meeting next week
<slangasek> cheers :)
<TheMuso> ogra_: oh sorry forgot about that URL. Got the email, thanks. Will take a look at those this morning.
#ubuntu-devel 2011-04-06
<ohsix> hi, re: changelog for pam in natty, mentions kernel changes for file descriptor limits; is that for the patch that changes it to 4096 or was there something else interesting that happened in .38
<micahg> ohsix: did you see the latest kernel changelog?
<c2tarun> micahg: hi, if possible please look at a query I posted in #ubuntu-motu :/ i am stuck
<ohsix> micahg: yea, the one about the patch to change the number of fds; thats "the patch" i was referring to :]
<ohsix> hrm nevermind, reading the bug now
<ohsix> hi, another java question: NetX and the plugin moved to the IcedTea-Web project with a separate release cycle.
<ohsix> in the icedtea readme for openjdk-6, but it appears theres no package for it, there _is_ a package for an icedtea plugin, but it appears to be something else, and older
<ohsix> afk, but if someone can clarify the whole java situation it'd be much appreciated; trying to eventually report somtehing crashing but finding out the relationship of everything involved is proving difficult
<micahg> ohsix: the plugin is in a separate source called icedtea-web
<micahg> the binary is icedtea-plugin
* mthaddon changed the topic of #ubuntu-devel to: Launchpad down/read-only from 08:00-09:30 UTC for a code update | Archive: Feature/UI freeze | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for dapper ->  maverick | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs | Patc
<Tm_T> Patc (:
<micahg> mthaddon: you realize that's an hour early, right?
<didrocks> good morning
<mthaddon> micahg: an hour early compared to what?
<slangasek> compared to the stated time
<micahg> mthaddon: the notice is up 1hr before the downtime
<mthaddon> I don't think so - I'm pretty sure it was always scheduled for this time in UTC
<micahg> mthaddon: I was just noting current time is 07:04 UTC, just wanted to make sure since various people have had DST issues lately
<pitti> Good morning
<ohsix> micahg: ok
<ohsix> micahg: i just reproduced the problem i was having with icedtea/openjdk with the sun plugin, so i'm looking at ff now
<ohsix> it is something that changed between b1 and b2
<micahg> ohsix: help with bug reporting in #ubuntu-bugs please :)
<ohsix> i'm reporting them :D
<ohsix> oh heh, it does say icedtea-web in the changelog for icedtea-plugin, oof,
<micahg> ohsix: there were just new uploads of both
<ohsix> ok
<ohsix> micahg: can you explain why jamvm/cacao are there? since for most purposes they're drawn in with the browser plugin where its a bit tricky to switch between them
<micahg> ohsix: nope, I haven't dug into it that much yet
<ohsix> okie dokie, thanks again
<ohsix> micahg: maybe you can confirm something; http://www.runescape.com/game.ws use firefox's full screen mode; let it load, make sure the toolbar is set to auto hide
<ohsix> it crashes when the toolbar comes donw after it is fully loaded (shown the login screen) you can tell w/o logging in by the cursor having stopped blinking and not being able to click on it, the applet viewer crashes and nothing notifies the browser side plugin about it
<micahg> ohsix: not right now, maybe someone in #ubuntu+1 can verify
<ohsix> micahg: ok, thanks
<ohsix> oh yea, keep forgetting i'm  using natty D:
<ohsix> i had great luck pinning natty's ff4 to maverick before i switched entirely though :]
<dholbach> good morning
<sladen> ohsix: "RuneScape Applet" ... I get a "do you trust this content?" box
<ohsix> sladen: oh, yea it uses native code to do 3d, and needs authorization
<ohsix> it might just use software 3d if you don't but i haven't tried it
<ohsix> sladen: i may have to read your response in the morning, but if it doesn't crash immediately; have it bring down the toolbar a few times (also it rarely hides automatically since the focus change is to a native plugin and not client web content, to force the toolbar away focus in the address bar and hit escape)
<ohsix> but i will be looking, msg or hilight if you can
<talat> Hi i try to repacakged my python using apt-get and dpkg but python gives 3 error in unit test can you help me why cant i repackage my python ?
<talat> ?
<talat> isn't there any one knows packaging ?
<cjwatson> plenty, but your question is pretty vague
<cjwatson> a full build log posted to paste.ubuntu.com or similar would stand a better chance of getting somebody to look at it
<talat> cjwatson: ok now i paste :)
* mthaddon changed the topic of #ubuntu-devel to: Archive: Feature/UI freeze | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for dapper ->  maverick | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs | Patch Pilots:
<tjaalton> what is the preferred naming scheme for SRU's? I see all kinds of variants, incrementing -0uX, -0u1.Y, -0u1~hardyX, -0u0.8.04.X etc
<tjaalton> quite a mess imo :)
<pitti> tjaalton: the preferreed naming schema is to add 0.1 ubuntus
<pitti> tjaalton: appending it sometimes needs more tricks like appending 0.8.04 and 0.10.04 if the same versino exists in several releases
<tjaalton> pitti: ok thanks, so 7.3+2 -> 7.3+2ubuntu0.1 then (for x11-xserver-utils SRU)
<tjaalton> pitti: yeah, ok
<pitti> tjaalton: right
<simion314> hi, i need a link to some page that has information about how to get a comercial application on the ubuntu software center,thx
<bdrung> to whom can i talk about multiarch?
<mthaddon> simion314: trying to find out for you - will let you know when I get some info
<seb128> bdrung, you can just ask on the channel
<seb128> bdrung, but slangasek has been driving the work on it mostly so if you have specific questions maybe slangasek
<bdrung> seb128, slangasek: i just want to let the multiarch people know about bug #752101 and #752350
<ubottu> Launchpad bug 752101 in nvidia-common (Ubuntu) "nvidia-detector crashed with ValueError in __get_value_from_name(): invalid literal for int() with base 10: '173:i386'" [Undecided,New] https://launchpad.net/bugs/752101
<ubottu> Launchpad bug 752350 in synaptic (Ubuntu) "synaptic does not support multiarch" [Undecided,New] https://launchpad.net/bugs/752350
<bdrung> is someone working on multiarch in synaptic?
<bdrung> it currently renders synaptic useless
<seb128> mvo, ^
<seb128> tseliot, ^
<mvo> bdrung: not currently :/
<seb128> bdrung, you can tag multiarch bugs as "multiarch"
<bdrung> seb128: already done
<mvo> bdrung: I can have a look after lunch, basic support (to show audacious:386) should be striaghtforward
<bdrung> seb128: is it possible to subscribe to tagged bugs?
<bdrung> mvo: that would be a huge improvement
<seb128> bdrung, I don't think so
<SpamapS> cjwatson: is there a way I can take a look at the plymouth bits that will show the integration with upstart's dbus signals?
<cjwatson> in what way?
<cjwatson> perhaps change the plymouth-upstart-bridge job to run with --debug?
<SpamapS> cjwatson: well I'm trying to form a good vision fo where we are and where I'd like to see us go for server boot.
<SpamapS> s/fo/of/
<SpamapS> cjwatson: the most common request is "just show me what its doing"
<SpamapS> which I think it already does..
<SpamapS> but I'm not entirely sure how to show that. ;)
<cjwatson> plymouth-upstart-bridge gets all goal and state changes from upstart from the point it starts up, and does its best to render those into a reasonable approximation of traditional starting/stopping messages
<cjwatson> oh, and it gets told when jobs fail too
<SpamapS> cjwatson: and those will show up in plymouth-theme-ubuntu-text if --debug is passed?
<cjwatson> I think if you look at the on_failed and on_state_changed functions in src/upstart-bridge/plymouth-upstart-bridge.c, it should make it fairly clear
<cjwatson> SpamapS: oh, for a user to see them, they just need to not pass 'quiet'
<cjwatson> I thought you wanted more than that
<SpamapS> *ah*
<cjwatson> if you want a full dump of what the bridge is getting from upstart, you can edit /etc/init/plymouth-upstart-bridge.conf to add '--debug 2>/dev/.initramfs/plymouth-upstart.log' to the end of the exec line
<cjwatson> but that's for developers not users
<cjwatson> (roll on /run)
<SpamapS> cjwatson: ty.. thats just what I needed. :)
<cjwatson> one thing I suspect we need to do is to go through the description fields of upstart jobs and make them fit into this presentation (or possibly adjust the presentation code in the bridge)
<cjwatson> since that field was purely informational before this, there are some cosmetic inconsistencies
<ev> could someone please approve my mail to ubuntu-devel-announce?
<SpamapS> cjwatson: while I have your attention.. as a hypothetical, if we want this on all the time..  would it be possible and/or advisable to make the server not have 'quiet' passed by default?
<cjwatson> to fit well into the bridge, the description field of task jobs should be a sentence about what the task is doing, in sentence case, without a final full stop; and the description field of services should be a noun phrase naming the service, starting with a lower-case letter unless the service name is naturally title-case
<cjwatson> SpamapS: it should be possible
<cjwatson> the code gets fiddly due to too-many-requirements-syndrome, but that's my problem
<cjwatson> ev: done
<ev> thanks
<SpamapS> cjwatson: I see what you mean.. "Stopping: System V runlevel compatibility" .. doesn't make much sense but could be quite helpful.
<cjwatson> (there's no :)
<cjwatson> er, "no colon"
<cjwatson> that's an interesting case; there's currently no way to have per-instance descriptions, or to explicitly mark a job as always quiet
<cjwatson> I've added the basic facility, but it definitely needs a full review for the cosmetics
<cjwatson> seb128: FYI, you can now do orig.tar.xz uploads (bug 742408)
<ubottu> Launchpad bug 742408 in Launchpad itself "Support xz compression in source packages" [Low,Fix released] https://launchpad.net/bugs/742408
<seb128> cjwatson, oh nice, thanks a lot ;-)
<SpamapS> cjwatson: whats there now is actlually good, I didn't realize the "Starting AppArmor Profiles ..." stuff was actually that.
<SpamapS> most of my VMs don't have many services installed. :-P
<cjwatson> SpamapS: actually that one is emitted by a traditional init script, not by plymouth-upstart-bridge
<SpamapS> ah
<SpamapS> hrm.. so w/o quiet.. we get stuff all over tty1 ..
 * SpamapS really shouldn't be brain dumping to IRC at 3am
<cjwatson> seb128: (though note that I don't believe .xz source uploads are available in Debian yet - I know they're working on it)
<seb128> cjwatson, (no worry, GNOME said they would not switch to .xz before next cycle and they will keep .tar.bz2 for a while as a backup solution for those who don't support .xz)
<seb128> but nice to know that launchpoad handle .xz for when it will be needed ;-)
<SpamapS> cjwatson: looks like respawning could use special consideration too. I think smbd may get respawned a whole bunch of times right now because it needs an 'and net-device-up' in it start on.. we get about 6 "Starting SMB/CIFS File Server" lines..
<cjwatson> or maybe that's a case where the six lines are a useful note to us that we need to fix something - could look at that either way
<SpamapS> true.. the detail will be in syslog
<SpamapS> heh.. I imagine that is slowing down boot
<SpamapS> smbd thrashing about in the first 5 seconds
<SpamapS> cjwatson: is it a bug then, when init.d scripts call 'echo' directly?
<cjwatson> no, init.d scripts have to
<cjwatson> plymouth-upstart-bridge doesn't do anything with them, only with native upstart jobs
<tseliot> seb128: I'll fix nvidia-common. Thanks for the heads up
<cjwatson> oh, sorry, do you mean directly rather than using the LSB functions?
<SpamapS> I thought they would need to call a shell function that would send to plymouth or console so they didn't run all over the plymouth output
<seb128> tseliot, thanks
<SpamapS> cjwatson: yes
<cjwatson> SpamapS: on the whole Ubuntu init.d scripts should have been converted to LSB functions; but calling echo still goes via plymouth
<cjwatson> now that we don't use usplash any more, the main purpose of the LSB functions is just to do nicer formattin
<cjwatson> g
<SpamapS> http://paste.ubuntu.com/590174/
<SpamapS> This shows things not really looking so pretty..
<cjwatson> that's basically a line-buffering problem
<SpamapS> so.. plymouth bug?
<cjwatson> I'm not quite sure
<cjwatson> plymouth is a reasonable dumping ground for it, but I'd need to sit and think about it
<SpamapS> As I understand it, the point of plymouth is to be the traffic cop between stuff running in parallel and the console.
<SpamapS> (I mean the point of plymouth sans pretty graphics for the desktop)
<cjwatson> yes, but there's only so much it can do if the actual bytes sent to the console are out of order
<cjwatson> that's why I want to think about it
<SpamapS> Ok. :)
<cjwatson> it may be that lsb-base-logging.sh should be changed to use the plymouth client, which would give plymouth more structured input in this case
<cjwatson> plymouth is also what makes /var/log/boot.log exist, BTW
<SpamapS> Right, thats a bit of magic I was just counting on.. not thinking about at all. :)
<cjwatson> we never had boot logging working before, because it needed something that was basically plymouth-shaped
<SpamapS> cjwatson: so that you can decide when to think about this.. rather than it interrupting you at the moment, do you want me to open a bug report?
<cjwatson> yes please
<cjwatson> if you can include a recipe for setting up a vm to look like that, that would be good
<SpamapS> surely. should I open it against plymouth?
<cjwatson> actually, you might as well just open it against lsb-base
<cjwatson> I think that's likely where it belongs
<SpamapS> cool
<cjwatson> so the lsb source package
<SpamapS> cjwatson: bug #752393 opened
<ubottu> Launchpad bug 752393 in lsb (Ubuntu) "lsb init scripts show line buffering problems on bootup" [Undecided,New] https://launchpad.net/bugs/752393
<cjwatson> thanks
<SpamapS> oh no, as always, thank you. :)
<ev> mvo: heads up: I've added an item to OneiricPlanning for this idea http://paste.ubuntu.com/590182/ which I thought might interest you.
<TeTeT> I've submitted a debdiff for bug 692922 that seems to be faulty - it may crash compiz hard. any chance to hinder it to get into lucid-proposed?
<ubottu> Launchpad bug 692922 in compiz-fusion-plugins-main (Ubuntu) "[10.04] Disappearing icons for Java app" [Undecided,In progress] https://launchpad.net/bugs/692922
<mvo> thanks ev!
<seb128> TeTeT, hum, mvo said he uploaded it?
<mvo> TeTeT: that is uploaded, no?
<TeTeT> mvo: yes, fear so - I got a report from a tester a few minutes ago
<mvo> seb128: could just just reject it from the queue (or another archive admin)?
<seb128> mvo, why? is it incorrect?
<mvo> ev: thanks, the data snapshot is a good point, the release one as well
<seb128> doh
<mvo> seb128: apparently it can crash
<seb128> TeTeT, mvo: sorry I misread what TeTeT was saying
<mvo> seb128: yeah, me too
<mvo> I thought he looked for sponsoring, not reverse sponsoring
<seb128> TeTeT, mvo: rejected from the lucid queue
<ev> mvo: sure thing
<mvo> seb128: thanks!
<seb128> mvo, yw
<seb128> ev: hey, you got a ubuntu-geonames merge request from mterry ;-) just mentionning it in case you don't notice those, I know we tend to not get notified for desktop ones
<ev> seb128: indeed, it's on my todo list for today :)
<seb128> ev: great, thanks ;-)
<TeTeT> seb128: thanks a bunch!
<YokoZar> Is CDBS something we're trying to phase out long term?
<YokoZar> I've heard a lot of devs express great preference for debhelper
<cjwatson> YokoZar: it probably depends whom you ask
<cjwatson> YokoZar: there is a trend in that direction, certainly, but I wouldn't say there's consensus
<mvo> bdrung: basic support is now done (took more time to write the configure.in bits then the actual code :/
<YokoZar> cjwatson: I was considering putting in a debhelper feature request but the particular feature is already completely implemented in CDBS
<cjwatson> http://people.debian.org/~cjwatson/dhstats.png <- dh vs. cdbs trend in Debian
<cjwatson> (sorry, the legend is mangled, I should fight with gnuplot some more at some point)
<cjwatson> s/legend/X-axis labelling/
<soren> What is dh(1)?
<soren> Or rather, how is it different from "debhelper"?
<cjwatson> http://manpages.ubuntu.com/manpages/natty/en/man1/dh.1.html
<soren> Yes...
<YokoZar> From that graph I'd have to guess that it looks like cdbs packages are staying cdbs, but all the new ones are debhelper
<soren> Ok, then what is debhelper 7?
<soren> :)
<cjwatson> "debhelper 7" on that graph means that debian/compat says >= 7
<soren> Oh, ok, so there are packages that might count against both?
<cjwatson> yes
<soren> s/both/more than one/?
<soren> Oh, ok.
<cjwatson> YokoZar: I think on the whole that's probably true (and there's conversion of existing packages to dh too), although there are also some cdbs->dh and *->cdbs conversions
<cjwatson> gets hard to graph those
<cjwatson> actually, sorry, having checked my code, "debhelper 7" is actually packages whose build-dependencies imply at least debhelper (>= 7~)
<soren> Ok.
<cjwatson> the dh(1) line is any package whose debian/rules matches /^\s+dh\s+/m
<YokoZar> how on earth did I manage to make solitaire crash with a branding update...
<bdrung> mvo: thanks. where do i get the code from?
<mvo> bdrung: I just uploaded it to natty
<bdrung> mvo: you forgot to close bug #752350 in d/changelog
<ubottu> Launchpad bug 752350 in synaptic (Ubuntu) "synaptic does not support multiarch" [Undecided,New] https://launchpad.net/bugs/752350
<mvo> bdrung: ups, thanks
<juliank> Did nobody work on multi-arch support in aptitude?
<juliank> OK, it partially works with multi-arch, but it uses Name() instead of FullName() to display names, causing architecture information to be omitted
<bdrung> diwic: re bug #722375 - your patch fixes the crashes (a big improvement), but still produces ~ 10% load on my netbook.
<ubottu> Launchpad bug 722375 in wxwidgets2.8 (Ubuntu Natty) "High CPU usage of wxWidget apps caused by dbusmenu" [High,In progress] https://launchpad.net/bugs/722375
<diwic> bdrung, hmm, what was the cpu load before the patch?
<bdrung> i just launched audacity
<bdrung> diwic: 50% - 70%
<bdrung> diwic: and it hanged often before the crash
<bdrung> s/crash/patch/
<diwic> bdrung, if you use the other workarounds (menuproxy= etc), do you get rid of the 10% then? I'm just thinking it might be unrelated
<bdrung> diwic: you are right. that's unrelated. same workload with menuproxy workaround
<diwic> phone
<bdrung> diwic: then please upload your fix.
<diwic> bdrung, I don't have any upload rights
<bdrung> diwic: then give me a debdiff :)
<diwic> bdrung, ok, will do later today (just got three things in parallel)
<bdrung> k
<steveire> I'm running a live cd and trying to install iotop which is in universe. I tried sudo vi /etc/apt/sources.list but the file doesn't exist. What's going on?
<diwic> bdrung, for appmenu.patch, did you talk to upstream anything or did you just cherrypick their svn commit
<bdrung> diwic: i didn't talk to upstream. i just tested the patch that you posted
<diwic> bdrung, I was asking about the previous patch, appmenu.patch
<bdrung> diwic: dunno who wrote it and where it comes from.
<diwic> bdrung, I just ask you because you were the one uploading appmenu.patch.
<seb128> TeTeT, hey, seems I closed that IRC tab
<bdrung> diwic: mom, let's check that.
<seb128> TeTeT, vinagre ... depends of kees and the security team, we wanted to use reminna this cycle but they blocked it on security review issues
<seb128> not sure vinagre is any better but status quo is that we are blocked with it until that is sorted
<TeTeT> seb128: can we expect reminna to make it into 12.04, or way to early to tell?
<diwic> bdrung, debdiff attached to the bug
<bdrung> diwic: i pulled the patch from upstream vcs
<seb128> TeTeT, dunno, as said kees blocked it so it depends of whether upstream fixes the issue or not
<diwic> bdrung, just wondering if you just picked it or if a discussion with upstream was preceeding that pick. I think my fix should be upstreamed
<TeTeT> seb128: ok, thanks
<seb128> TeTeT, do you have issue with vinagre or request to use reminna?
<bdrung> diwic: can you upstream your fix and add a DEP-3 header to the app-menu2.patch?
<seb128> TeTeT, https://bugs.launchpad.net/ubuntu/+source/remmina/+bug/673908 for the record if you are interested in details
<ubottu> Ubuntu bug 673908 in remmina (Ubuntu) "[MIR] remmina" [Wishlist,Fix committed]
<TeTeT> seb128: nah, customer surprised me by telling me something new was coming and I had no idea ;)
<seb128> TeTeT, https://bugs.launchpad.net/ubuntu/+source/freerdp/+bug/673925
<ubottu> Ubuntu bug 673925 in freerdp (Ubuntu) "[MIR] freerdp" [Undecided,New]
<diwic> bdrung, I'm quite busy, do we have anyone who is our upstream contact?
<bdrung> dunno
<diwic> ok
<diwic> I'll see if I can find a ML then
<bdrung> diwic: the app-menu.patch was posted by Tim Kosse who seems to be an upstream developer
<bdrung> diwic: https://bugs.launchpad.net/ubuntu/+source/wxwidgets2.8/+bug/662077/comments/7
<ubottu> Ubuntu bug 662077 in wxwidgets2.8 (Ubuntu Natty) "WxWidgets apps don't have menus" [High,Fix released]
<diwic> bdrung, thanks
<bdrung> diwic: let me know once you have added the dep3 header
<diwic> bdrung, is it ok with forwarded: no for now?
<diwic> i e in the dep-3 header
<bdrung> yes
<diwic> bdrung, uploaded to bug
<seb128> slangasek, hey, I thin you broke unity application matching with the multiarch bamf update
<bdrung> diwic: uploaded, thanks
<diwic> \o/
<diwic> thanke
<diwic> s/e/s
<bdrung> diwic: or s/th/d/ ;)
<killown> do anyone know what's the .qml file responsible to set the laucher width? I could resize the icons using LauncherItem.qml, LauncherList.qml but I have not found anything about resize launcher width
<pitti> stgraber: hm, what's this "fake-udev" package that udev.preinst refers to?
<stgraber> pitti: https://bugs.launchpad.net/ubuntu/+source/udev/+bug/745011 (dpkg-divert diverts a file for all packages except the one in --package)
<ubottu> Ubuntu bug 745011 in udev (Ubuntu) ""info: unrecognized option '--convert-db'" on upgrade" [High,Fix released]
<pitti> stgraber: ah, I'm currently trying to recover from a really nasty upgrade failure due to that
<pitti> Preparing to replace udev 167-0ubuntu1 (using .../udev_167-0ubuntu2_amd64.deb) ...
<pitti> dpkg-divert: error: `diversion of /sbin/udevadm to /sbin/udevadm.upgrade by fake-udev' clashes with `diversion of /sbin/udevadm to /sbin/udevadm.upgrade by udev'
<stgraber> oh, how's that even possible ... did you have a udev upgrade crash in the past ?
<stgraber> that'd explain why you have a divert set before the upgrade to the new package
<pitti> stgraber: ah, it's just the retracer chroots
<pitti> I think seb128 just nuked the postinst instead of just removing set -e
<pitti> yes, that'd explain it
<stgraber> I'd just remove the divert manually, that should fix it
<pitti> right, that's what I did
<pitti> stgraber: thanks!
<pitti> sorry for the noise, got the idea a second after I pinged
<seb128> pitti, oh right, sorry about that
<pitti> seb128: np
<seb128> ok, I officially hate the multiarch changes landing so late in the cycle that's decided ;-)
<cjwatson> stgraber: is it possible to safely clean up the old diversions?
<slangasek> bdrung: 752101, 752350> yes, there are package management tools that don't work when multiarch is enabled, that's why I'm not pushing to enable it by default in natty
<slangasek> seb128: application matching - hrmm, where is this?
<seb128> slangasek, bamf
<slangasek> seb128: right, but how did it break?
<seb128> slangasek, I'm investigating, the gio part is not being used
<seb128> slangasek, /usr/lib/i386-linux-gnu/gio/modules has an empty cache there
<seb128> which would explain it
<seb128> trying to figure why it's empty now...
<slangasek> seb128: ah, giobamf is present but missing from the cache here as well.. maybe I messed up the trigger somehow
<seb128> slangasek, no, launching the cache update command by hand leads to the same result
<slangasek> hmm
<seb128> there is something it doesn't like in libgiobamf.so
<stgraber> cjwatson: postrm is supposed to revert the binary and remove the diversion in case something goes wrong. I can probably check for an old diversion before doing dpkg-divert and remove it if it exists though.
<seb128> slangasek, I've copied that file in /usr/lib/gio/modules and run the update cache line and the .cache list everything but it
<slangasek> seb128: is it reproducible with the previous upstream version of bamf?
<seb128> slangasek, it works with 0.2.80-0ubuntu1 and is broken with 0.2.80-0ubuntu2
<slangasek> hmm
<seb128> slangasek, no in fact I'm wrong
<seb128> it's not listed
<seb128> slangasek, I need to check on that, i seem to recollection that gio check the cache and fallback to read the directory if the file it needs is not cached
<slangasek> seb128: looking at gio-querymodules source, it tries to find the symbol g_io_module_query and only adds it to the cache if found; bamf doesn't provide this symbol; I'm reasonably certain nothing I did for multiarch broke this
<seb128> slangasek, right, the cache issue was a wrong track
<slangasek> ok
<seb128> slangasek, it was not in the cache either for 0.2.80-0ubuntu1 but that version works
<slangasek> seb128: ok - but the functionality regressed between -0ubuntu1 and -0ubuntu2?
<seb128> slangasek, yes
<seb128> slangasek, one way to test is cp /usr/share/applications/gedit.desktop .
<seb128> edit gedit.desktop, tweak the Name=
<seb128> double click on that .desktop from nautilus
<seb128> with 0.2.80-0ubuntu1 the launcher display the edited .desktop name
<seb128> with 0.2.80-0ubuntu2 it matches the system one
<seb128> i.e it doesn't track which one gio launched but go back to do fallback matching
<seb128> you need to restart bamfdaemon and unity between upgrades or downgrades to test
<seb128> slangasek, it's likely what create bug #751025 as well
<ubottu> Launchpad bug 751025 in bamf (Ubuntu) "Libreoffice is not marked as opened in the Unity Launcher" [Undecided,New] https://launchpad.net/bugs/751025
<slangasek> seb128: ok. I only moved the files as part of the FTBFS fix because it looked like an easy win; if it's not, let's roll back the multiarch changes for natty and see if that fixes
<seb128> slangasek, doing a mv /usr/lib/i386-linux-gnu/gio/modules/libgiobamf.so /usr/lib/gio/modules seems to fix it
<seb128> I don'g get why though
<seb128> don't
<slangasek> oh.  In that case, what about other modules in /usr/lib/<triplet>/gio/modules?  Is the process that's failing to find bamf failing to find them as well?
<seb128> slangasek, we have none in there right now so not sure, I would still like to understand why it breaks before moving it back
<slangasek> seb128: I have glib-networking installed to that directory, but I haven't used it
<slangasek> I'm not sure I know how to use it
<slangasek> seb128: what if you were to manually add the module to the cache in the multiarch dir?
<slangasek> (as a test)
<seb128> would that work since it doesn't define the symbol for lazy loading?
<slangasek> it's possible the patch for the compatibility fallback in glib assumes the module will be in the cache
<slangasek> I don't know, let me see if that symbol is needed at runtime or just at cache build time
<seb128> well a strace on bamfdaemon shows that it loads the .so correctly
<slangasek> hmm
<seb128> slangasek, ok, right, adding a cache listing it in the new dir fixes it
<seb128> slangasek, ie echo "libgiobamf.so:gio-desktop-app-info-launch-handler"
<seb128> slangasek, removing it bring back the bug
<seb128> slangasek, so it doesn't like things in the new dir which are not in the cache list
<slangasek> ok, I wonder why that is
<slangasek> it would be a glib bug rather than a bamf bug, I guess... which way would you like this fixed?
<seb128> seems a glib issue indeed
<seb128> slangasek, well ideally we would make it work in the new dir the same way it did in the old one
<tseliot> slangasek: does changing the "Section" field in debian/control cause the package to be NEWed? Just to be sure..
<seb128> slangasek, but I don't care much how we fix it in natty, I would prefer not by adding bamf to the cache list though since other components could run into the same issue
<slangasek> tseliot: no
<slangasek> seb128: ok; I can try to look at fixing glib later today then
<tseliot> slangasek: ok, thanks
<seb128> slangasek, thanks
<seb128> slangasek, I've assigned you bug #751025 for tracking
<ubottu> Launchpad bug 751025 in glib2.0 (Ubuntu) "Libreoffice is not marked as opened in the Unity Launcher" [High,New] https://launchpad.net/bugs/751025
<SpamapS> slangasek: can you think of any reason moving smbd to 'start on runlevel [2345] or net-device-up' would cause things to break horribly?
<SpamapS> slangasek: right now its 'start on local-filesystems' and this causes it to respawn profusely until lo exists...
<slangasek> SpamapS: 'start on net-device-up' will just make it respawn profusely until /usr/sbin exists instead (or else get itself into a wedged state where it doesn't respawn at all)?
<SpamapS> slangasek: right.. so if we marry it with local-filesystems then nfsroot has the same issue.. :P
<slangasek> SpamapS: only when /usr is on a distinct nfs share, I think?
<SpamapS> slangasek: what about just doing runlevel [2345]? Is smbd needed ever between local-filesystems and filesystem?
<ohsix> micahg: cacao/jamvm are apparently available to help bootstrap the compiler; i'm sure there are other reasons but thats the first compelling one i've found
<slangasek> SpamapS: I'm not sure; I would want to look at the genealogy of the upstart job in the package to see why it was set that way to begin with
<SpamapS> slangasek: it has always been that start on since you wrote it. :)
<SpamapS> timestamp: Thu 2010-02-18 12:51:45 +0000
<slangasek> SpamapS: ok - then I'm still not sure, and you should do whatever makes sense :)
<SpamapS> slangasek: I'm trying to think of a scenario where smbd should start before 'filesystem' ...
<slangasek> SpamapS: /usr on loopback-mounted cifs? :P
<SpamapS> slangasek: i think we call that *WINNING*
 * cjwatson nails wubi bugs to the floor and stomps on the pieces
<cjwatson> now I need to do something else for a while to keep my sanity
<pitti> mterry, doko: do you have some time to review bug 752530? as this is a very late FFE, it'd be good to get that in ASAP for more testing
<ubottu> Launchpad bug 752530 in overlay-scrollbar (Ubuntu Natty) "[MIR] overlay-scrolllbar" [High,New] https://launchpad.net/bugs/752530
<pitti> rickspencer3: ^ FYI
<rickspencer3> thanks pitti
<mterry> pitti, looking now
<mterry> pitti, sorry, I haven't looked at incoming MIRs for a bit, didn't expect any  :)
<rickspencer3> pitti, mterry could you guys please let me know asap if there are any problems there
<rickspencer3> I can get back to sabdfl asap in case it doesn't look suitable
<pitti> mterry: I only filed it a couple of hours ago, as before it wasn't ready yet :)
<dbarth_> pitti: there is a wiki page describing a set of tests you guys can do on the scrollbar
<dbarth_> pitti: it was used for the last call for testing that jibel organized
<pitti> dbarth_: probably not that important for the MIR, but interesting in general; is that part of what QA does in their regular tests?
<dbarth_> pitti: https://wiki.ubuntu.com/Ayatana/ScrollBars#Test guidelines
<mterry> rickspencer3, no .symbols file.  I usually consider that a blocker.  Shouldn't take long to fix, can that be done soon?
<dbarth_> pitti: ack
<mterry> kenvandine, can you add a .symbols file to overlay-scrollbar?
<kenvandine> mterry, sure
<fEnIo> hello
<kenvandine> mterry, done and uploaded
<mterry> kenvandine, awesome
<pitti> mterry, kenvandine: nice! seeding/promoting now
<chrisccoulson_> has anyone had this error when trying to push a bzr branch: http://paste.ubuntu.com/590350/
<pitti> chrisccoulson_: hm, try bzr reconcile?
<chrisccoulson_> pitti - hmmm, same problem :(
<Ampelbein> slangasek: hi, would it be possible for you to regenerate the http://people.canonical.com/~vorlon/broken-srcs-universe.txt list?
<slangasek> Ampelbein: sure, running now
<Ampelbein> slangasek: thank you!
<j1mc> hi all - i wanted to discuss a doc-related bug here, as i think it's pretty important: https://bugs.launchpad.net/ubuntu/+source/ubuntu-docs/+bug/748673
<ubottu> Ubuntu bug 748673 in ubuntu-docs (Ubuntu) "Natty & Yelp/Desktop help: strange mix of info refering to Gnome 3 & 2, but not to Unity" [Undecided,Confirmed]
<j1mc> basically, there are no real natty docs at this point, and i wanted to see about getting them in late, even post-release.
<slangasek> Ampelbein: refreshed - pretty good progress!
<j1mc> see bug: https://bugs.launchpad.net/bugs/600875 for background
<slangasek> Ampelbein: from what I see, over half the packages left to be rebuilt have no reverse-dependencies anyway; I don't have this in report form, but if you're keen, a prioritized list would be: libfsobasics (FTBFS), libfsoframework, nbtk (FTBFS), libtranslate, tntnet, synfig, libsylph, nufw, libgsm0710mux, libfsotransport, abiword
<ubottu> Ubuntu bug 600875 in unity "No documentation for using/configuring Unity" [Wishlist,Triaged]
<Ampelbein> slangasek: yeah, I've been looking at the list, too. The libfsobasics-ftbfs I don't know how to fix, vala is completely new to me.
<slangasek> Ampelbein: right, I don't know either
<Ampelbein> slangasek: I filed some RM bugs, too: bug 749470, 749804, 750926, 751014
<ubottu> Launchpad bug 751014 in libpano12 (Ubuntu) "Please remove libpano12 from natty" [Wishlist,Confirmed] https://launchpad.net/bugs/751014
<ubottu> Launchpad bug 750926 in libgda3 (Ubuntu) "Please remvoe libgda3 from natty" [Wishlist,Confirmed] https://launchpad.net/bugs/750926
<ubottu> Launchpad bug 749804 in hk-classes (Ubuntu) "Please remove hk-classes from natty" [Wishlist,Confirmed] https://launchpad.net/bugs/749804
<ubottu> Launchpad bug 749470 in libccc (Ubuntu) "Please remove libccc from natty" [Wishlist,Confirmed] https://launchpad.net/bugs/749470
<slangasek> Ampelbein: ah, great :)
<geser> I'm looking at some of the FTBFS from the recent archive rebuild and stumbled about several build errors on amd64 with the same error: "dpkg-deb: error: control directory has bad permissions 700 (must be >=0755 and <=0775)". Someone have an idea what caused this?
<fmut> Hello
<fmut> I'm looking for some help. I have a source code that I would like to convert into a package (ubuntu compatible). I followed some of the tutorials for package generation using debhelper apps but everything seems to assume that you already have the standard configure/make setting
<fmut> My question is the where is the best way to generate these configure/makefile configuration to be as standard as possible with the rest of the community
<slangasek> geser: just buggy control dir generation that dpkg now complains about?  Do you have a sample link?
<geser> slangasek: https://launchpadlibrarian.net/68375035/buildlog_ubuntu-natty-amd64.outguess_1%3A0.2-7_FAILEDTOBUILD.txt.gz
<fmut> any help will be greatly appretiated
<slangasek> fmut: if it's C or C++, to be as standard as possible, use autoconf+automake+libtool.  I don't know if there's a quickstart guide for autotools though
<fmut> yes, it is c
<bcurtiswx> fmut, in the youtube tutorials for packaging they use the package hello, correct?
<fmut> no, they used ed, the gnu editor
<geser> slangasek: if you need more pick one of the amd64 FTBFS after "mx" from http://people.ubuntuwire.org/~wgrant/rebuild-ftbfs-test/test-rebuild-20110329-natty.html and you might be lucky
<bcurtiswx> maybe the wiki tutorials has hello.. but you may want to apt-get source <packagename> and look at the config and make files to maybe get a visual representation.
<bcurtiswx> slangasek, is there a wiki on autotools at least?
<slangasek> geser: oh, so it's just started happening in later builds?
<slangasek> bcurtiswx: you are asking the wrong person, I learned autotools before wikis were invented
<slangasek> :-)
<geser> slangasek: looks like, the earlier ones I checked all failed with a different error
<bcurtiswx> slangasek, were dinosaurs around? no no j/k.  thx tho :)
<slangasek> geser: is there a different version of dpkg in use in the different failing builds?
<fmut> it seems that the tutorial are all outdated ..
<fmut> I'm also interested in learning a proper dirtory structure to organize my code ....
<fmut> *directory*
<slangasek> geser: hmm, 1.16.0~ubuntu6 is a dpkg build I uploaded and it hasn't failed for me here, so probably not
<slangasek> wgrant: do you know what's going on with, e.g., https://launchpadlibrarian.net/68375035/buildlog_ubuntu-natty-amd64.outguess_1%3A0.2-7_FAILEDTOBUILD.txt.gz in the test rebuilds?
<geser> slangasek: I looked at earlier builds and they all use the same dpkg-dev version
<stgraber> pitti, cjwatson: http://paste.ubuntu.com/590389/ <- looks good ? that should fix the case where there was an old diversion set on a system
<geser> slangasek: and only amd64 seems to be affected (https://launchpad.net/ubuntu/+archive/test-rebuild-20110329/+buildjob/2406466)
<slangasek> geser: does it look like it's a single builder affected, or multiple ones?
<geser> slangasek: was about to check it right now
<geser> slangasek: the build records mention all available amd64 PPA builders. And the last package with that error is currently "picocom" but I don't know if the problem fixed itself or if the later packages are still in queue on amd64
<slangasek> alrighty
<slangasek> I guess we can watch for new failures showing up with the same error
<plotino> ciao
<plotino> anybody knows how to get java working in firefix?
<plotino> firefox
<micahg> plotino: support is in #ubuntu or #ubuntu+1, but just install icedtea6-plugin or sun-java6-plugin
<plotino> sun-java6 is a propetary plugin?
<micahg> plotino: yes
<plotino> ok thanks
<cjwatson> geser,slangasek,wgrant: whoa, that sounds like a recurrence of https://wiki.ubuntu.com/IncidentReports/2011-02-25-Permissions-build-failures
<cjwatson> lamont: ^- alert, please?
<lamont> that's build 2406466?
<cjwatson> lamont: https://launchpadlibrarian.net/68375035/buildlog_ubuntu-natty-amd64.outguess_1%3A0.2-7_FAILEDTOBUILD.txt.gz
<lamont> <geser> slangasek: and only amd64 seems to be affected (https://launchpad.net/ubuntu/+archive/test-rebuild-20110329/+buildjob/2406466)
<lamont> more interested in that to ge tteh builder name
<cjwatson> ah yes
<cjwatson> that's the one
<geser> lamont: pick one of the amd64-only FTBFS between "mx" and "picocom" from http://people.ubuntuwire.org/~wgrant/rebuild-ftbfs-test/test-rebuild-20110329-natty.html and you have a high chance to find an affected build
<lamont> cjwatson: identified.  I've stuck the virtual builders on manual while I sort out the scope of it
<lamont> non-virtual is not affected
<cjwatson> phew.  thanks
<cjwatson> is it the same thing as before?
<lamont> there are about 3 different fixes for the mess before.  the virtual amd64 buildds are missing most or all of them atm
<lamont> any one of them would be sufficient
<lamont> cjwatson: so here's the scope....   to continue the saga of the original incident:  ultimately, the incident was resolved by adding a umask() call to sbuild on all of the non-virtual builders on 2/26, and sudo was downreved back to 1.6.9.  Subsequent to that, a compatible sudoers.d/buildd file was rolled out, and sudo went back to 1.7.2 as part of centralized management's requirements.  lp-buildd-76 did not include the cowboyed call to umask(), and
<lamont>  was rolled out to the amd64 boxes Monday via dist-upgrade, creating the situation on the virtual builders that they (1) had sudo 1.7.2, (2) did not have a compatible sudoers file, and (3) lacked the sbuild backstop. ==> FAIL.
<lamont> Also affected are any builds on non-permanent ppa builders that were re-installed anytime after early march. ==> MORE FAIL
<lamont> launchpad-buildd 77 is building now, with the umask() call in it for the final backstop.  As I roll that out to the virtual builders, I'll put
<lamont>  them back on auto.
<ohsix> hm, mango-lassi uses the same icon networkmanager uses for ethernet, that's a little confusing :D
<lamont> cjwatson: all but terranova are back.  we are still having words
<cjwatson> lamont: thanks
<ScottK> mtaylor: Please fix python-drizzle in Debian and Ubuntu.  kthnxbye.
<jelmer> barry: hi
<jelmer> barry: is there a UDD meeting?
<mtaylor> ScottK: yes. on it.
<ScottK> mtaylor: Great.
<infinity> lamont: Sounds messy...
<lamont> infinity: clusteramic
<lamont> infinity: sudo changed umask handling between 1.6.9 and 1.7.2..  and well, sbuild wasn't ready for that kind of crazy
<infinity> lamont: Yeah, I read the old incident report.
<lamont> most amusingly, the "fix it in sudoers by restoring old behavior" is a syntax error with 1.6.9
<lamont> anyway, afk for me for a while
<kees> ScottK: say, your bug/feature email... how should the testcase be run?
<ScottK> kees: I didn't actually run it (not my test case).  Let me find you the original message.
<kees> ScottK: yeah, I'm a little lost on the actual situation they're seeing.
<ScottK> kees: Here's the full message it came in: http://paste.ubuntu.com/590467/
<ScottK> Their online mail list archive seems to be out of date.
<kees> ScottK: ah-ha, okay. I waited too long. This reproduces for me: while ./testcase.pl ; do echo -n . ; done
<ScottK> kees: With this as a followup http://paste.ubuntu.com/590468/
<ScottK> (which motivated me to write the message)
<kees> ScottK: right. let me poke at this for a bit -- a change like this in the kernel would likely effect more than just amavisd.
<ScottK> Yep.
<kees> hmmm
<kees> ScottK: it's not perl. the kernel seems to be treating "shutdown()" differently :(
<ScottK> Lovely.
<kees> ScottK: I think it's a bug. I sent email with a C version of the PoC
<ScottK> kees: Cool.  Could you comment in the Ubuntu bug?
<kees> ScottK: yeah
<ScottK> Thanks.
<ScottK> kees: The other question I have is should we apply the Net::Server patch anyway?
<ScottK> My Perl is non-existent, so I've no idea.
<kees> ScottK: no, I think that's a hack specific to perl to work around the kernel bug. this will bite other daemons too, so we need to fix it in the kernel.
<ScottK> OK.  Thanks.
<kees> ScottK: I've converted the bug to a kernel bug and subscribed the kernel team. I assume it will get forwarded to upstream for a solution, since this is likely not an expected change.
<kees> if it IS an expected change for some reason (I doubt it, given that the listening socket disappears from netstat) then we can revisit patching Perl (and all kinds of other stuff)
<ScottK> Right.  Sounds good.
#ubuntu-devel 2011-04-07
<wgrant> lamont, cjwatson, slangasek: No further issues?
<lifeless> wgrant: buildd umask backstop was gone, and boom
<wgrant> lifeless: Well, yes, I saw that, but wondered if things were still fixed.
<lifeless> partly
<lifeless> I don't know if lamont has tracked all the buildds down yet
<lamont> lifeless: all should be fixed
<lamont> wgrant: ^^
<lamont> wgrant: having said that, recipe builds still have issues  - they also need to not assume that a sane-for-building umask is handed to them.
<lifeless> lamont: can you file a bug ?
<lamont> lifeless: I will do so,  and then I'll fix it.
<lifeless> \o/
<lamont> I may even fix it harder
<micahg> wgrant: would it be a lot of trouble to add the package sets to the FTBFS list for the latest archive rebuild?
<wgrant> micahg: The rebuild archive script is currently a fork of the primary archive one.. I need to merge them.
<micahg> wgrant: ah, ok
<blairkatu> Yo' I'm on the beta in unity. Does any one know how to change the workspace configuration
<blairkatu> And thanks in advanced.
<blairkatu> I'm pretty sure there is no way to do it with the UI
<smoser> jdstrand, around ?
<micahg> smoser: should be back in the morning, was off today
<smoser> thanks.
<lamont> there will be a brief disturbance in the i386 virtual builder pool
<ohsix> hm,  is there a reason oss4 still has a package, all i've ever heard is people thinking it'll solve their problems and giving them new ones
<TheMuso> ohsix: I didn't even know there was a package of it.
<ohsix> sec lemme check the origin
<ohsix> it's in universe/sound
<ohsix> oss4-base and some other packages with oss4 in the name
<ohsix> it's useful for the guy that knows why he's using it instead of just getting it dropped in his lap as some solution from some fan; but the former doesn't likely happen often
<didrocks> good morning
<ohsix> hm, what's the process for say; getting flat-volumes finally enabled in pulseaudio on ubuntu, it is disabled when sinks don't have dB information; but it breaks when the dB information is present but incorrect, the number of devices by now should fit in a small blacklist (they have been fixed as they show up)
<ohsix> micahg: i tried those new icedtea drops; didn't expect a change, and didn't get any :]
<diwic> ohsix, hmm, maybe it should be considered for oneiric, if we ship oneiric with what's now in git master, and hopefully a release
<dholbach> good morning
<diwic> morning dholbach
<ohsix> diwic: i'm gonna see about some of those cosmetic/trival patches getting applied upstream too
<dholbach> hey diwic
<diwic> ohsix, you mean those we carry in Ubuntu currently? That'd be great
<ohsix> yea, i just read them to verify something else and most look easily transplantable
<pitti> stgraber: looks fine to me
<ohsix> diwic: do you know of a bug i can use as an example when putting in a request that flat-volumes be changed
<diwic> ohsix, not in my head, search for flat volumes on launchpad
<ohsix> ok i will look at those, i was more interested in seeing the general process
<DreadKnight> ohsix: heya; how to connect to eth0 using nmcli again?
<ohsix> nmcli con list, nmcli con up id or uuid, if it's named "Auto eth0" nmcli con up id "Auto eth0" should work, iirc
<Laney> what's all this "la_backup" stuff all over my filesystem?
<DreadKnight> ohsix: thanks; not working; gotta reinstall I guess
<ohsix> DreadKnight: if it is temporary you can use dhclient
<DreadKnight> ohsix: oh that was it :D cheers again!
<ohsix> DreadKnight: if you dont also have nm-applet running there might not be any connections unless you set them up with keyfile, or in system-connections; as i was explaining it to the guy it was a special case
<ohsix> he had nm-applet running but no working mouse
<ohsix> overlay scrollbars are neat, a bit hard to fish for with a mouse sometimes though, is there a simple way to disable it?
<DreadKnight> ohsix: they're default now or what?
<ohsix> this is OT for here, my bad
<Daviey> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Archive: Feature/UI freeze | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for dapper ->  maverick | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs | Patch Pilots: Daviey
<m4n1sh> can a package sync be requested as of now?
<Laney> yes
<m4n1sh> Laney: after which freeze it cannot be synced?
<tumbleweed> m4n1sh: it can always be synced, but it's less likely to be the option you want, the closer we get to releases. After feature freeze, we only really want bug fixes, not new features
<m4n1sh> tumbleweed: it is not present as default installation
<m4n1sh> and we have tested it extensivly
<m4n1sh> from PPA
<tumbleweed> m4n1sh: you still need to request an FFe if you want to bring a version with new features in
<Laney> you can always request a sync, but when it gets really close to release (like after the RC) it might be an idea to ping the release team too
<tumbleweed> but if you show extensive testing, you'll probably get it
<m4n1sh> tumbleweed: its a new version
<m4n1sh> with some minor small features
<m4n1sh> UI enhancements
<m4n1sh> Laney: where can I find release team?
<tumbleweed> #ubuntu-release
<m4n1sh> thanks
<Daviey> hrw, Hi, How did you generate the debdiff for bug 749155?
<ubottu> Launchpad bug 749155 in ace (Ubuntu) "ace version 5.7.7-4 failed to build on i386 and armel" [Undecided,New] https://launchpad.net/bugs/749155
<hrw> Daviey: dch -i + debuild -S + debdiff
<hrw> Daviey: ah. I know issue - edited it probably to fix dpatch description ;(
<Daviey> ahh
<Daviey> hrw, v
<Daviey> http://pb.daviey.com/Qp3L/raw/
<hrw> Daviey: add empty line - should work
<hrw> sorry for that
<kklimonda> good morning o/
<hrw> hi kklimonda
<Daviey> hrw, no problem, thanks for clearing that
<hrw> Daviey: thx for merging it
<hrw> Daviey: this week I had a session with few bugs in packages which I never used or known what for they are.
<Daviey> heh.. good to see them getting fixed.
<hrw> Daviey: ace was one of simplest ones. but it had longest build time
<Daviey> hrw, The other thing i was going to say, it's a good idea to run 'update-maintainer' on the package if the version introduces a ubuntu delta.  (ubuntu in the version of debian/changelog)
<hrw> Daviey: thx - will remember for future
<hrw> Daviey: part of ubuntu-dev-tools?
<Daviey> hrw, super.. if you are interested, here is the reasoning: https://wiki.ubuntu.com/DebianMaintainerField
<ohsix> hmmm linux-tools depends on libdw now, i wonder if that means unwinds without frame pointers :D
<hrw> Daviey: I know problem from my work in few other distributions
<dholbach> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Archive: Feature/UI freeze | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for dapper ->  maverick | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs | Patch Pilots: dholbach, Daviey
 * dholbach hugs Daviey
<Daviey> hrw, ahh!
 * Daviey embraces the hug.
<hrw> Daviey: but still forget sometimes about issue
<Daviey> juliank, Are you ready for the bzr branch on bug 736507 to be uploaded?
<ubottu> Launchpad bug 736507 in aptdaemon (Ubuntu) "update-manager crashed with UnicodeDecodeError in _convert_struct(): 'ascii' codec can't decode byte 0xc3 in position 100: ordinal not in range(128)" [High,In progress] https://launchpad.net/bugs/736507
 * hrw builds gcl/armel
<mvo_> Daviey: its on my sponsoring list, should be fine
<juliank> Daviey: mvo already prepared the upload
<Daviey> hrw, We all do... which is why it was coded in to block us from building if it's not done :)
<Daviey> juliank, ah, super!
<juliank> mvo_: Didn't you upload it yet, and why are you logged in twice?
<mvo> juliank: unity was playing games with me
<mvo> juliank: its uploaded now, I did some quick tests with it
<juliank> mvo: OK.
<ohsix> can anyone point me at how one requests packaging? cairo-trace isn't in the repos and i thought it was :\
<ohsix> nm they're packaged
<dholbach> seb128, do you know what's going on with https://code.launchpad.net/~ubuntu-branches/ubuntu/natty/gtksourceview3/natty-201104070312/+merge/56681?
<dholbach> it looks like there are no visible changes between the two
<ohsix> seb128: hi, you've touched a lot of my bugs lately, thanks!
<seb128> dholbach, no, ask james_w, I've no clue why the autoimporter doesn't work as it should
<seb128> ohsix, you're welcome!
<dholbach> seb128, shall I go ahead and merge it to make the importer happy again?
<seb128> dholbach, he keeps opening weird bugs like this one
<seb128> dholbach, dunno we maintain that in a team vcs with only the debian dir
<dholbach> ok, I'll ask james_w
<seb128> dholbach, I've no clue why the importer gets confused and why there is a conflict
<seb128> something is just buggy and wrong
<dholbach> does anybody know what's up with pbuilder in natty? (might be a linux-any build-dep problem?)
<dholbach> I can't build usbmuxd from sid
<dholbach> (natty i386 pbuilder on natty i386 if that matters)
<dholbach> mvo, do you have an idea what to do about https://bugs.launchpad.net/ubuntu/+source/pbuilder/+bug/728494?
<ubottu> Ubuntu bug 728494 in Launchpad itself "pbuilder-satisfydepends breaks on comments before source package" [High,Triaged]
<dholbach> (a good example of it is trying to build usbmuxd from sid on natty)
<mvo> dholbach: I have a look in a minute
<cjwatson> kees: what's the point of vmlinuz being mode 0600?  as policy points out, anyone can just look up the version and get the image from the archive - it's not secret
<cjwatson> kees: and it broke live CD builds
<cjwatson> (easily fixed, but)
<juliank> mvo: The fix for https://bugs.launchpad.net/ubuntu/+source/apt/+bug/750694 is in debian-sid
<ubottu> Ubuntu bug 750694 in apt (Ubuntu) "Directories titled "Sources" cause apt-cdrom to fail" [Undecided,Fix committed]
<pitti> likewise the System.map?
<mvo> juliank: nice
<mvo> juliank: the fix for the multiarch issue from yesterday is in donkults branch now too
<mvo> juliank: I will upload a new ubuntu version with those fixes
<juliank> mvo: We could also upload them to Debian and merge
<mvo> juliank: yep. bug #404724 looks like a low hanging fruit, making it root.admin and 640 should do no harm
<ubottu> Launchpad bug 404724 in apt (Ubuntu) "unnecessarily restrictive permissions on /var/log/apt/term.log" [Undecided,Confirmed] https://launchpad.net/bugs/404724
<juliank> mvo: That would be one more Ubuntu-specific change (Debian has sudo, not admin) and not really bring any benefit.
<mvo> https://bugs.launchpad.net/ubuntu/+source/apt/+bug/704595 might be a interessting one too
<ubottu> Ubuntu bug 704595 in apt (Ubuntu) "Python-apt shows emply origins object" [Undecided,Confirmed]
<mvo> (its libapt though)
<juliank> mvo: That's a "I'm can't verify the signature, so I ignore attributes" case
<juliank> (IIRC)
<juliank> mvo: I'm going to eat something now (or at least I hope it's ready), should be back in a 20 minutes
<mvo> juliank: ok
<mvo> juliank: see you
<juliank> mvo: Back, and yes, that's really one of those cases where the release.gpg could not be verified due to missing keyrings. If verification fails, component, etc., are ignored
<mvo> I wonder what it takes to fix that its ignored
<juliank> mvo: I take a look at it
<mvo> thanks!
<juliank> mvo: GPG method fails, causing acquire to unlink the release files and load the package
<juliank> or more specifically, the file remains in partial/
<seb128> who is handling ubottu?
<seb128> can we get it on #ubuntu-desktop as well?
<vish> seb128: jpds ?
<seb128> jpds, ^
<dholbach> tsimpson, ^
<tsimpson> I guess one of the bots died
<chrisccoulson> i could use some help from someone on foundations for bug 663294 really :) (see from comment 17)
<ubottu> Launchpad bug 663294 in firefox (Ubuntu Natty) "Firefox built with gcc-4.5 is a non-starter on i386 with -pie" [Medium,Triaged] https://launchpad.net/bugs/663294
<tsimpson> seb128: ubot5 is there now
<dholbach> mvo, it could be that 728494 is a separate problem from building sid's usbmuxd in pbuilder under natty
<seb128> tsimpson, thanks a lot
<stgraber> pitti: ok, I'll commit that to the bzr branch and upload
<om26er> i get "No init found. Try passing init= bootarg" now system won't boot, this have happened the third time over the past month in Natty
<ohsix> om26er: your initramfs is damaged, or isn't getting created properly
<ohsix> this isn't a support channel though
<om26er> but its a bug which have not fixed for more than a month so that makes it a concern ;(
<om26er> and i didn't find any duplicate
<om26er> should I try to update-initramfs in chroot?
<ohsix> well, it hasn't been determined that its a bug yet
<ohsix> sure, you can try; but chances are whatever broke it in the first place will do it again
<om26er> ohsix, arand in #ubuntu+1 confims to have faced this issue with btrfs as well, so a bug ;)
<cjwatson> the btrfs problem is specific to btrfs
<ohsix> yes
<cjwatson> if you aren't using btrfs then you have a different problem
<om26er> my / is on btrfs cjwatson
<ohsix> btrfs isn't running out of bugs either
<cjwatson> then it's bug 732149
<ubottu> Launchpad bug 732149 in grub2 (Ubuntu) "[natty] btrfs "grub-probe: error: unknown filesystem"" [High,Triaged] https://launchpad.net/bugs/732149
<cjwatson> (a consequence of it, anyway)
<ohsix> hm
<ohsix> how does it get to not building the initramfs, or is it just cuz grub can't find its files on btrfs
<om26er> cjwatson, i saw the 732149 only when I had /boot on btrfs this time /boot is ext4 so I might havea  different problem ?
<cjwatson> ohsix: at least the cases I've seen aren't that the initramfs wasn't built, but that because grub-probe isn't able to understand btrfs properly it isn't emitting rootflags=subvol=@
<cjwatson> ohsix: and, yes, you could also have boot-time problems failing to find the file
<ohsix> so it can't reach its file
<ohsix> k thanks for the info
<cjwatson> in general it seems to be a transient problem
<cjwatson> which doesn't yet imply it's been fixed, but rather that the conditions that cause problems in grub's filesystem code seem to come and go
<cjwatson> I've tried to gather information from affected people but it's been too hard to debug remotely; I need to reproduce it in a vm and debug locally
<cjwatson> so it's gone into my queue of stuff like that
<cjwatson> it's about third or fourth in that queue, I think
<ohsix> can the grub test shell program thing use raw volumes? might be able to tease it from there
<cjwatson> my ADSL is too slow for it to be feasible for me to fetch a whole filesystem
<cjwatson> I have some likely candidates for ways to reproduce it
<ohsix> ah i figured creating your own
<cjwatson> once I have reproduced it, I am familiar with how to debug that kind of thing :)
<ohsix> is grub out of sync as far as the disk format is concerned or is it stable enough that not finding the files would be a grub problem
<cjwatson> I don't know the answer to that question
<ohsix> hm
<cjwatson> I expect I'll find that out
<cjwatson> I don't think it's worth speculating in advance
<ohsix> it shouldn't be too hard to check grub policy wrt it since it's still in flux, which is what i'm going to do
<ohsix> it maeks sense for it to lag in the bootloader given the state of development, and there was an on disk format not too long ago, too; might have landed in .38
<cjwatson> the boot loader code was (necessarily) reverse-engineered from some docs
<ohsix> drop an assertion bomb on the thing
<cjwatson> as I say, I know how to debug grub once I've reproduced it locally
<om26er> cjwatson, adding rootflags=subvol=@ to grub parameter worked :) thanks to arand
<cjwatson> good
<ohsix> arand was talking about snapshots too; but they were still speculating because theres not much info yet
<hallyn> hm.  has anyone tried to create a btrfs partition as part of the desktop installer process?
<ohsix> probably the people with the problems they're having now
<arand> I did mine using ubiquity yes, and it worked apart from these issues here..
<cjwatson> yes, and there are bug reports from some of those people
<hallyn> oh, haha, i see, that was already on topic
<hallyn> the partitioner went berzerk on me long before it even got to trying to install
<cjwatson> that would probably be a different problem
<hallyn> i'll file a new bug then, thanks
<cjwatson> have you filed a bug?
<cjwatson> ok
<ohsix> sure is an odd way to poke at it; when it can all fail and take your stuff with it, i'd be using losetup and a disk file or something D:
<cjwatson> we offer it in the installer in order that people can do system-level testing, which often isn't feasible with a loop mount
<Laney> Is something wrong with the new procps? http://paste.debian.net/113289/
<ohsix> i understand that, but its a buzzword to some people right now, they might not know the implications
<cjwatson> ohsix: can't help that
<ohsix> i suppose not, hopefully people complain loudly though
<cjwatson> we aren't going to get useful feedback if only experts ever use it
<ohsix> nod
<ohsix> when the time comes it'll be awesome for ubuiquitous snapshotting and backups
<Daviey> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Archive: Feature/UI freeze | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for dapper ->  maverick | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs | Patch Pilots: dholbach
<arand> ohsix: Using apt-btrfs-snapshot has a tendency to eat some disk space though... So it would have to be done in moderatioin..
<ohsix> oh neat, i was just talking about filesystem level stuff
<ohsix> i haven't looked as i wont be able to use it for some time anyways, but can't you set the percentage and number of snapshots to keep? then the distro can turn that into weekly, daily, monthly
<arand> ohsix: Yea I assume those features are planned, that one is very basic atm now though.
<jibel> YokoZar, hi, we are receiving many dups of bug 753449
<ubottu> Launchpad bug 753449 in branding-ubuntu (Ubuntu) "package branding-ubuntu 0.5 failed to install/upgrade: trying to overwrite '/usr/share/gnome-games/quadrapassel/pixmaps/quadrapassel.svg', which is also in package quadrapassel 1:2.32.1-0ubuntu3" [High,Triaged] https://launchpad.net/bugs/753449
<hrw> I just got hit by that one too - thx for info that it is known
<ohsix> arand: you can do it with lvm but its very expensive :\
<Laney> hmm, seems to only be broken in a chroot
<arand> ohsix: Yea, not really feasible for more than temporary snaps from what I've read on it.
<mvo> ev: thanks for your apt-clone work! I uploaded a new version with your fixes and also with a fix for the xubuntu upgrade-via-install case
<hrw> btw - when is freeze for any universe uploads (including NEW packages)?
<hallyn> cjwatson: I created bug 753510.  I'm going to wipe the drive and try again - if you want me to wait in case you want some more info off the machine, pls shout
<ubottu> Launchpad bug 753510 in ubiquity (Ubuntu) "Partition manager bombs trying to create btrfs" [Undecided,New] https://launchpad.net/bugs/753510
<cjwatson> hallyn: no /var/log/partman?
<cjwatson> we need that for partitioner bugs
<cjwatson> (for future reference, 'ubuntu-bug ubiquity' should work, if the machine is network-connected)
<cjwatson> (probably not going to be able to look today, though)
<ev> mvo: yay, thanks!
<hallyn> /var/log/partman looked useless, but i'll attach it
<cjwatson> hallyn: we need it to reproduce what you did
<hallyn> ok
<cjwatson> knowing where it stops is often useful too
<ohsix> arand: and the more complex filesystems get it actually gets worse
<ohsix> since its block level after a snap the log goes through the snapshot, which means everything ets diverted twice or more
<Riddell> mvo: ok if I upload update-manager for bug 746431 ?
<ubottu> Launchpad bug 746431 in update-manager (Ubuntu Natty) "[kubuntu] Allow to view differences in conf file changes" [High,Triaged] https://launchpad.net/bugs/746431
<mvo> Riddell: sure, pleae just make sure to use bzr-buildpackage as its using a pre-build hook
<mvo> Riddell: I can do the upload too if needed
<Riddell> mvo: bzr-buildpackage doing its thing
<mvo> great
<Riddell> mvo: what is parsewiki needed for?
<mvo> Riddell: just to make nice html from my text annoucement
<Riddell> mvo: what do I need to do to get past this? http://paste.kde.org/9127/
<mvo> Riddell: *cough* let me fix that, that is rahter silly
<MonkeyDust> folks, idea for future installers: some kind of software center during installation
<ohsix> you mean like software center? :D
<MonkeyDust> well, yes
<MonkeyDust> no?
<MonkeyDust> or choosing trusted PPA's during installation
<alfmatos> hi
<alfmatos> anyone from the network-manager team around?
<MonkeyDust> Ubuntu Tweak offers a selection of PPA's, too, graphically, why not use such option during installation
<birdthief> I'm on Natty and the touchpad no longer works
<ohsix> alfmatos: try your question on me
<birdthief> x and lsinput both find it.
<alfmatos> ohsix, just trying to wrap my head around how the packaging is actually done, because there is an upstream branch, a branch for each release, + a debian branch. How is the merging actually done (src+vcs-debian-folder) ? Is it manual?
<jdstrand> didrocks: hi! I don't seem to have an Ubuntu logo in the upper left of my screen anymore (eg, next to the global menu). Is this intended? known?
<didrocks> jdstrand: oh no, it's not, do you have the window buttons at the upper left or just the menu title?
<alfmatos> maybe fta can help? i see his name popping up all over the daily builds ppa's
<jdstrand> didrocks: the window buttons are in the window, not part of the global menu. eg, I am typing this in irssi in gnome-terminal. I have the window buttons in this terminal. I have no Ubuntu logo in the upper left of the screen, but it does say 'Terminal' in the upper left, over where the logo should be
<jdstrand> didrocks: if I go full screen for the terminal, they show up in the global menu
<didrocks> jdstrand: do you have one or two monitor?
<ohsix> alfmatos: ah, can't field that one, sorry
<didrocks> jdstrand: or is your setup is "mirror screen" or whatever with only one monitor?
<alfmatos> ohsix, np :)
<jdstrand> didrocks: I have two monitors, but mirrored at the same resolution because of bug #711954
<ubottu> Launchpad bug 711954 in linux (Ubuntu) "Cannot use external monitor at its native resolution" [Undecided,Confirmed] https://launchpad.net/bugs/711954
<didrocks> jdstrand: I think it's what is the trick
<didrocks> jdstrand: I'm in the middle of an unity release, I don't think we have a fix for that. Do you mind just updating and report it after the update?
<jdstrand> didrocks: well, it is 'mirrored'-- ie, the screen should be exactly the same on both
<didrocks> probably what traps it
<jdstrand> didrocks: sure, I can wait. I tried to find a bug on it, but couldn't. no worries
<didrocks> jdstrand: I think there is a similar one, not exactly the same, but similar, but anyway, just open one with the incoming release
 * jdstrand nods
<jdstrand> didrocks: thanks!
<didrocks> jdstrand: thanks to you :)
<jdstrand> :)
<alfmatos> fta, around?
<aruiz> is anyone having problems with matplotlib in natty?
<jdstrand> micahg: hey, in testing my fix for bug #750381, I tried youtube with gnash, but it doesn't work too well. istr you mentioning that gnash should work quite well-- is youtube known broken? (I don't see an open bug on it)
<ubottu> Launchpad bug 750381 in apparmor (Ubuntu) "gnash configs blocked by apparmor" [Low,In progress] https://launchpad.net/bugs/750381
<micahg> jdstrand: are you running 0.8.9?  when I tested it, it seemed to be pretty smooth
 * micahg wonders if it's a video driver issue
<jdstrand> micahg: 0.8.8-6ubuntu2
<jdstrand> micahg: oh no, youtube just tells me there was an error and it doesn't even try to play it
<alfmatos> any idea on where I can find some documentation on how to maintain separate src/upstream and Vcs-Bzr (debian dir bzr branch only) branches?
<micahg> jdstrand: please upgrade to 0.8.9, I uploaded it a couple days ago
<jdstrand> weird, I did an apt-get upgrade this morning...
<jdstrand> ah, binary new
 * jdstrand looks
<dholbach> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Archive: Feature/UI freeze | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for dapper ->  maverick | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs | Patch Pilots:
<birdthief> ohsix: I figured it out
<YokoZar> pitti: Can I poke you on https://launchpad.net/bugs/753449  please?  All the latest branding-ubuntu upload did was give it the correct name
<ubottu> Ubuntu bug 753449 in branding-ubuntu (Ubuntu) "package branding-ubuntu 0.5 failed to install/upgrade: trying to overwrite '/usr/share/gnome-games/quadrapassel/pixmaps/quadrapassel.svg', which is also in package quadrapassel 1:2.32.1-0ubuntu3" [High,Triaged]
 * YokoZar just noticed he uploaded a package with a changelog entry referring to differences in debian/changelog...
<psusi> /msg psusi hi there.  I'm throwing in my application for
<psusi>      universe-contributor and was hopign you might endorse me.  If you have
<psusi>      time to take a look, it's at
<psusi>      https://wiki.ubuntu.com/PhillipSusi/DeveloperApplication
<pitti> mdz: https://wiki.ubuntu.com/TechnicalBoardAgenda seems to be rather empty right now, do we have something urgent to discuss?
<pitti> mdz: currently asking myself whether I can weasel out of this today, and go to a friend's bday party
<cjwatson> oh argh, I forgot about that - I can't make today's meeting, sorry
<pitti> it's really late now in DST
<mdz> pitti, I may have to miss it too...
<mdz> there is some unanswered email on the mailing list
<mdz> oh, pitti answered it
<pitti> about the motu-council thing?
<mvo> Riddell: I fixed the test, will upload after diinner
<Riddell> thanks mvo
<mvo> Riddell: uploading now, it as a native python test proxy now it was rather silly to depned on a external one
 * mvo is really away for dinner now
<pitti> YokoZar: (on the phone, will look in a bit)
<jdstrand> micahg: fyi, gnash 0.8.9 bin deNEWed and works well :)
<micahg> jdstrand: awesome, thanks
<Laney> does it support the bbc iplayer? :-)
<YokoZar> pitti: Thank you muchly :)
<micahg> Laney: I know it doesn't support streamtheworld yet, I need to file an upstream bug for that
 * Laney tries
<Laney> no :-(
<jdstrand> didrocks: fyi, noticed libunity stuck in binary NEW (due to new libunity4), so I deNEWed it
<lamont> Setting up lmodern (2.004.1-3) ...
<lamont> /usr/sbin/update-language-def: line 779: printf: missing unicode digit for \u
<lamont> ^^ I wonder if that has a bug filed yet
<didrocks> jdstrand: oh thanks! :)
<micahg> lamont: yes, with a patch attached
<lamont> cool
<micahg> bug 751038
<ubottu> Launchpad bug 751038 in tex-common (Ubuntu) "/usr/sbin/update-language-def: line 779: printf: missing unicode digit for \u" [Low,Triaged] https://launchpad.net/bugs/751038
<alfmatos> question: is there a convention for a debian control dir in launchpad, either to hold it in debian/ or at the root of the branch?
<alfmatos> the difference I assume is either doing a nest or a nest-part debian debian, right?
<alfmatos> (in the recipes)
<micahg> alfmatos: recipes help in #launchpad
<alfmatos> ooh, ok
<alfmatos> ubuntu packaging in launchapd also?
<micahg> alfmatos: nope, ubuntu packaging in #ubuntu-packaging :)
<alfmatos> dooh =)
<cjwatson> I have a theory
<cjwatson> bugs get less comprehensible the further through the release cycle you get
<directhex> flibble wibble wurble!!!
<cjwatson> I seem to have had about five almost completely inscrutable ones in a row :-/
<micahg> I have a corollary, the complication of the bug is inversely proportional to the time available to fix it :)
<cjwatson> also, the complication of the bug is inversely proportional to the size of the patch needed to fix it
<kees> cjwatson: because it is a way to block script-kiddie root exploits. while it doesn't even remotely stop a dedicated attacker, it does actually stop simplistic attacks, and I feel that has real-world value. sorry about the breakage; thank you for working around it.
<cjwatson> kees: that's one regression caused by it, but I don't know if there will be others.  are you open to reverting until oneiric if we find more?
<kees> given that I've already seen vmlinuz-parsing-for-kernel-symbols tools in the wild, I'd prefer not to revert it, but if there is strong evidence that it will cause continued problems, I'm open to reverting it. I'd really like to try to leave it because then all of the ksym-obfuscation will hit people all in the natty cycle (instead of spreading it out).
<cjwatson> ok, we'll see how it goes
<kees> cool
<stgraber> SpamapS: ping
<stgraber> SpamapS: I'm looking at bug 752393. I installed the packages listed in the bug report but don't get the same output you do in /var/log/boot.log
<ubottu> Launchpad bug 752393 in lsb (Ubuntu) "lsb init scripts show line buffering problems on bootup" [Medium,Confirmed] https://launchpad.net/bugs/752393
<stgraber> SpamapS: anything I might be missing ?
<stgraber> SpamapS: my boot.log just shows fsck, apparmor, bind9, postgresql and apache2 (which I had installed) but not samba, squid or pretty much any of the ones you have in your log file
<pitti> YokoZar:
<pitti> if [ "$1" != "upgrade" ] || dpkg --compare-versions "$2" lt 0.4-0ubuntu1; then
<pitti> YokoZar: it won't actually re-divert when upgrading from 0.5 to 0.6 :)
<YokoZar> pitti: didn't you write that line? ;)
<pitti> YokoZar: not sure, it's your changelog
<pitti> YokoZar: but anyway, fixing/testing now
<YokoZar> pitti: I mean the maintainer scripts were rewritten by you previous version but the quadrapassel problem was unnoticed because the package still had gnometris filenames so the conflict never happened (and I imagine everyone who had the package had gnome-games installed)
<pitti> YokoZar: ok, fixed
 * pitti waves good night
<YokoZar> pitti: have a good time at party :)
<YokoZar> Thank you for cleaning up what was probably my mess too :p
<sense> Bug #753853 seems to have the potential to make many Natty machines unbootable after update. Shouldn't the latest udev update be pulled from the archive to prevent it from spreading?
<ubottu> Launchpad bug 753853 in udev (Ubuntu) "[natty] The disc drive for / is not ready yet or not present" [Undecided,New] https://launchpad.net/bugs/753853
<stgraber> sense: do you know if that's udev -ubuntu3 causing it or 167 in general ?
<sense> stgraber: I only now that it happened after the update for udev that landed today.
<sense> stgraber: and that there are at least two people in #ubuntu+1 with the same problem.
<stgraber> sense: -0ubuntu2 and -0ubuntu3 fix some divert issues so I'm not sure how that could be the cause (unles you're keeping an old divert for some reason)
<sense> stgraber: Hmmm, that is strange. But the processes only started crashing after today's update. Could it have been something else that landed today?
<stgraber> sense: can you check if /sbin/udevadm.upgrade exists on your system, if so, what's the content ? and also give the md5sum and (if text file) content of your /sbin/udevadm ?
<stgraber> sense: I want to make sure you're not using the diverted version for some reason
<sense> stgraber: I'll grab a live usb stick.
<sense> thanks for your help
<stgraber> version 167 landed on Monday (new upstream version), -0ubuntu2 landed on the same day (divert fixes) and then I uploaded another today to fix issues when someone has an half-upgraded udev package and upgrade to -0ubuntu2
<stgraber> It's not impossible that -0ubuntu2 or -0ubuntu3 might break udev but let's say if it's a feature issue, it's more likely that -0ubuntu1 did it
<sense> That would make more sense indeed.
<stgraber> ce6894e12ff09b07cad331d5ad91894a  /sbin/udevadm
<stgraber> /sbin/udevadm: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.15, stripped
<stgraber> -rwxr-xr-x 1 root root 123K 2011-04-07 08:43 /sbin/udevadm
<stgraber> sense: is what I have with the package installed on amd64
<sense> /sbin/udevadm.upgrade exists and its content is not readable by vi. /sbin/udevadm is a text file, copied it to http://pastebin.ubuntu.com/590908
<stgraber> ouch, seems like udev didn't upgrade properly in your case
<sense> ah
<sense> stgraber: wait, I think I now what could have caused this.
<directhex> gremlins.
<stgraber> sense: can you do: grep udev /var/lib/dpkg/diversions ?
<sense> stgraber: branding-ubuntu also got updated todya, but the new version fails during installation.
<stgraber> sense: and also make sure the package is in a clean state (ii)
<sense> that aborts the whole thing and for me it crashed aptd
<stgraber> sense: ouch, yeah, that'd be really bad for udev
<stgraber> as in, computer won't reboot
<stgraber> sense: can you run: "dpkg -l | grep udev" to confirm ?
<sense> I can't run commands on the system, using an openSUSE live USB-stick I had lying around to see the filesystem. Looking into the grep thing now.
<sense> stgraber: that grep command returns /sbin/udevadm /sbin/udevadm.upgrade and fake-udev
<stgraber> sense: chroot <target> dpkg -l | grep udev
<sense> stgraber: architecture mismatch
<stgraber> oh, not cool :)
<sense> wait
<sense> not
<sense> I did that properly!
<sense> No architecture mismatch, will try it.
<stgraber> stgraber@castiana:~$ cat /var/lib/dpkg/status | grep "Package: udev" -A1
<stgraber> Package: udev
<stgraber> Status: install ok installed
<stgraber> I'm guessing you don't have the "install ok installed" in your case ...
<sense> libudev0 and udev are both iU
<sense> not ii
<stgraber> ok, and the branding package is also iU ?
<sense> and libgudev-1.0-0 and lubudev-dev are iU too.
<sense> stgraber: The branding package is still ii, with 0.5 installed, but 0.6 is causing the problems during upgrade, which prevent it from being installed.
<sense> Just got confirmation from one of the other persons with the same problem that he also had branding-ubuntu making aptd crash during update.
<stgraber> sense: can you try: chroot <target> dpkg --configure -a ?
<stgraber> or apt-get -f install depending where it's stuck
<sense> stgraber: That is finishing the setting up process of libgudev-1.0-0, libgudev-1.0-dev and compiz-plugins-main.
<sense> stgraber: it also ran update-initramfs...
<sense> rebooting the system now to see if the problems are gone
<sense> stgraber: Issue solved! Thank you very much for your help!
<stgraber> no problem. I hope not too many people will get the same issue :(
<sense> stgraber: It really shouldn't happen that a package like branding-ubuntu can cause this to happen.
<SpamapS> wow... that was awful.. 2 hours repairing the system because ubuntuone-syncd ran rampant with memory during an upgrade interrupting 'update-initramfs' .. DOH
<SpamapS> stgraber: I didn't install postgres or bind9.. :-P
<SpamapS> stgraber: I did this on a clean natty vm
<stgraber> SpamapS: yeah, I chose some extra stuff installing the VM ;)
<stgraber> SpamapS: going to retry with absolutely nothing then install the same packages that you have and see if I can get the same boot.log
<SpamapS> stgraber: I used kirkland's quick seed...
<SpamapS> stgraber: http://blog.dustinkirkland.com/2011/03/ubuntu-server-quick-install-no.html ... good stuff :)
 * kirkland high fives SpamapS !
<SpamapS> kirkland: high speed VM building. :)
<kirkland> SpamapS: check out RoAkSoAx's work with cobbler and koan!!!
<SpamapS> I'm sure its magnificent
<RoAkSoAx> SpamapS: do it with cobbler :)
<SpamapS> RoAkSoAx: virt-manager's working great, thanks. :)
 * SpamapS has got to know when to say no to shiny things.. even tho cobbler is tempting
<RoAkSoAx> SpamapS: haha yeah I also use virt-manager a lot but right now installing from  ccobbler with  kirkland's NQA stuff is just magivcal
<RoAkSoAx> SpamapS: 1 command and a few minutes of wait
<bigcx2> hey all
<bigcx2> i'm trying to create a package that uses dpkg-divert
<bigcx2> to install a new configuration file
<bigcx2> and i want it to run non-interactively
<bigcx2> however, i always get the prompt asking if i want to use the package maintainer's version or keep the current version on the system
<bigcx2> is there any way to skip this in the maintainer scripts?
<broder> bigcx2: i don't know exactly what you're trying to do, but have you heard of config-package-dev?
<bigcx2> or does this have to be done with dpkg, apt-get options
<broder> (http://debathena.mit.edu/config-packages/)
<broder> it sounds like it does the sort of thing you're trying to do
<bigcx2> broder: thanks, looking :)
<broder> bigcx2: the important piece is that you install your file to a path with a suffix, and then c-p-d handles creating a symlink from the real path to your suffix'd path
<bigcx2> so it essentially uses dpkg-divert and symlinking using cdbs?
<bigcx2> i don't see anything in there about user prompting
<broder> bigcx2: you get that prompt if both the user and the package have changed the config file in question
<bigcx2> the user hasn't changed the conf file in my scenario
<bigcx2> basically my package pre-depends on a package that installs a conf file
<bigcx2> and then during preinst, i use dpkg-divert to move that file
<bigcx2> which works fine, but i get that prompt
<broder> you get the prompt for the file you moved?
<bigcx2> with dpkg-divert, yea
<bigcx2> i use dh_install to install the file
<bigcx2> hmm
<broder> bigcx2: hmm...i'm not sure exactly what's going on off the top of my head, and don't really have the time to debug, but i'd recommend trying config-package-dev anyway and seeing if your problem just goes away :)
<bigcx2> broder: lol, ok
<Ampelbein> slangasek: hi, I have sent an email to ubuntu-devel about the multiarch libraries in universe. basically it is down to 3 packages needing a fix (libfsobasics, emerald and nbtk), 6 are to be removed in my opinion, 4 are waiting on libfsobasics rebuild and 1 should be synced from debian.
<Ampelbein> slangasek: the 3 that need a fix are out of my knowledge, so I can't help further :-(
<slangasek> Ampelbein: wow, great work!
<seb128> kees, hey
<slangasek> Ampelbein: I don't know how to fix libfsobasics or nbtk either and I haven't looked at emerald... don't feel bad that you didn't fix them
<kees> seb128: hi!
<seb128> kees, how are you?
<seb128> kees, I was just reading the tb meeting logs
<kees> seb128: good! in a meeting at the moment, but can multitask :)
<seb128> kees, could you give specifics about your issues with the classic session?
<Ampelbein> slangasek: thanks.
<stgraber> SpamapS: I still can't reproduce the exact boot.log that you have, but I'm suspecting a race condition or something similar on my machine as I don't get the same content every reboot :)
<seb128> kees, the only changes we did over 10.10 was to replace the clock applet by its indicator equivalent by default and fix bugs
<kees> seb128: oh, I have only personally encountered one issue (that I think you just fixed). the menu bar in the top panel was stealing the menus from apps
<seb128> kees, so I find your concerns about it surprising
<kees> seb128: I've heard complaints about session-saving going away, but I think that's unrelated to unity integration
<seb128> kees, if anything we fixed a lot of bugs
<seb128> kees, right, that never worked correctly and leaded to lot of bugs where people get their session screwed
<stgraber> SpamapS: would it be possible for you to send me a "dpkg -l" of your system just to make sure I'm not missing something ?
<seb128> kees, i.e empty desktop on login because required component get wrongly stored in the session and other similar issues
<kees> seb128: well, my current concern is over the name. "Classic Gnome Desktop" is not what I get. I get "Classic Ubuntu Desktop". if it were "Classic Gnome", I wouldn't have the indicators, e.g. There _were_ gone earlier in Natty, but have since returned, which I think is a mislabelling of the session type.
<seb128> kees, since we don't have the ressources to fix the session saving we decided to turn if off to avoid misleading users to think it works
<kees> seb128: yeah, I never used session saving, and I had brought it up incorrectly as an example. I don't know much about it.
<slangasek> seb128: I think you and I have different definitions of "work correctly", fwiw; when I lose all of my open terminals, etc. when I logout (or experience an X or kernel crash), and nothing comes back at all for me, I don't consider that working correctly
<seb128> slangasek, session saving never worked correctly...
<seb128> slangasek, that's nothing new
<slangasek> seb128: I've been meaning to raise this point on ubuntu-desktop and see what can be done to retain this functionality for those of us who expect it
<slangasek> seb128: session saving used to work well enough that I didn't have to spend 20 minutes after a reboot putting my desktop back in order
<seb128> but rather than having it half working and screwing some users enough so they go no session or an empty desktop we just turned it off
<seb128> slangasek, it sort of work if you only have one session type, i.e GNOME
<seb128> slangasek, it really screw if you switch between GNOME2, gnome-shell or unity
<slangasek> seb128: I'm willing to put some effort into fixing this for my use case, if someone can point me in the right direction
<slangasek> seb128: right - I don't switch between these so that hasn't hit me yet :)
<seb128> slangasek, I think some people wanted to have a session at UDS
<seb128> but right now it screwed quite some users
<slangasek> At the upcoming UDS?  That won't solve the problems I'm experiencing
<seb128> right
<slangasek> now, I can hack gnome-session locally to reenable saving, but that won't help other users either
<seb128> do you have a better suggestion?
<mdeslaur> I don't think having a blacklist of applications the session saver shouldn't be saving is a hard thing to implement
<slangasek> seb128: no concrete suggestion yet... let's take this to the list where we can discuss it better.  For now, I just want to make it known that I'm available to hack on this :)
<seb128> mdeslaur, didrocks did like 5 iterations of patches, it's not designed to handle different sessions like GNOME and unity
<seb128> or GNOME2 and gnome-shell
<seb128> slangasek, ok thanks
<mdeslaur> seb128: oh, interesting...did those patches get uploaded, or were they private?
<mdeslaur> (I mean, in a ppa)
<seb128> mdeslaur, they landed in 10.10 and natty
<seb128> but we kept getting new bugs and broken cases
<seb128> we decided at the rally to stop wasting time on that
<mdeslaur> seb128: ok, cool thanks
<seb128> it was getting time consuming in debugging users and patching over what we estimated was worth it
<seb128> nobody raised concerns until now either
<seb128> but it's a bit late in the cycle now
<slangasek> seb128: but speaking of me sticking my fingers into the desktop, I have made no progress on this gio issue :(  One possibility is if some other code is calling g_io_modules_load_all_in_directory("/usr/lib/gio/modules") and missing the multiarch dir, but I haven't found where this code would be
<mdeslaur> seb128: that's usually how it works :)
<tjaalton> for me, getting terminals and browser windows in the right positions (and workspaces) is/was important
<seb128> slangasek, hum ok, what about just moving back the bamf .so back to the old dir for natty?
<seb128> getting things on the right workspace and position never worked fine or only on some applications
<seb128> you better do it the pitti way and write a script using devilspie or something to do that at login for you
<tjaalton> okay
<seb128> geometry and position storing is not really something the session has a status on
<slangasek> seb128: fwiw, I didn't raise this concern earlier because I wasn't running natty on my laptop until beta, and the discussion of this change happened only on ubuntu-desktop whose list description is "Desktop Team co-ordination and discussion" so I've never realized I should subscribe there to find out about changes like this... for my part, I would appreciate it if such changes were communicated to ubuntu-devel to get a wider audience, bu
<seb128> it relies on applications to handle it themself which most don't
<slangasek> ... meantime I'll subscribe to ubuntu-desktop :)
<tjaalton> don't know if it's firefox that tries to move the windows to where they were, but they all end up in the first workspace
<tjaalton> maybe it's just a firefox regression, or compiz, or both
<slangasek> seb128: yes, we can move bamf.so back to the old dir - I still would like to understand the cause of the bug however, since glib-networking also uses that directory
<seb128> slangasek, to be honest nobody in the desktop team consider it as something working or clearly available to user, like it was not on the logout dialog but hidden in a tab of a configuration capplet
<seb128> considered
<seb128> when we discussed it
<seb128> so we didn't think it was worth bringing on the devel list
<seb128> but seems we were wrong
<seb128> sorry about that
<slangasek> ah, but if you got bug reports, doesn't that mean people had found that toggle and were using it? :-D
<Sarvatt_> would be nice if we could at least pick the default session type in the installer since enabling automatic login forces unity
<seb128> right, most not of them not understanding what is was doing and getting very confused
<slangasek> but no worries - I'll just see what we can do to fix it for release
<seb128> there is also no way to get back to a clean session once you pressed the button
<seb128> which confused a lot of users as well
<seb128> like they did a snapshot of a session but clicking there and had it stored until someone on a bug report explained them how to reset it
<seb128> Sarvatt_, you can select it in gdmsetup or logout and pick a different session and log in again
<seb128> ups
<YokoZar> 3 cheers for seb128 on the gnome-panel change :)
<j1mc> hi all - i had a couple of basic questions about unity that i think are appropriate for here. i basically wanted to get the unity component names right.
<j1mc> - is there an official name for the 'ubuntu button' in the upper-left portion of the screen?
<j1mc> - is the launcher on the left-hand side called 'the launcher,' or is there a different name for it?
<chrisccoulson> j1mc, this might be appropriate for you - http://askubuntu.com/questions/10228/whats-the-right-terminology-for-unitys-ui-elements
<chrisccoulson> :)
<chrisccoulson> i think that answers your questions
<j1mc> - the menus in the top panel, are they collectively called 'application indicators?'
<j1mc> chrisccoulson: thanks - i'll have a look at them.
#ubuntu-devel 2011-04-08
<rojikku> uhhhmmmm....o.o i have "the dreaded checking battery state" error...where it freezes at checking battery state.. with the latest ubuntu 11.04 beta.. o.o it didnt do this with the 10.04...though my ATI drivers make the booting screen look cruddy for some reason...what should i try and do? >>
<rojikku> i managed to get into grub and into recovery mode..10.10 wouldnt boot in normal mode when i tried...
<j1mc> so... in unity, is the BFB officially called the Ubuntu Button or the Home Button?
<j1mc> this is for documentation purposes
<j1mc> i've read the post on askubuntu.com, but it is still not entirely clear.
<Keybuk> j1mc: I still want to know what you press when you don't *have* that button ;-)
<j1mc> Keybuk: i'm referring to the button in the upper left... isn't it always there?  i'm not talking about win/mac keyboad differences.
<broder> j1mc: based on the post from jcastro, i'd call it the "home button"
<j1mc> broder: thanks. :)
<jcastro> j1mc: home button
<jcastro> though people call it the ubuntu button anyway
<jcastro> and developers call it the BFB
<Keybuk> j1mc: ah, I thought you were referring to the keyboard button unity requires you have ;)
<jcastro> the keybuk button
<j1mc> heh
<j1mc> jcastro: thanks for clarifying.
<psusi> did the whole ubuntu on dell partnership thing kinda die?
<lifeless> not that I've heard
<j1mc> godbyk: /quit
<j1mc> heh
<psusi> hrm... hrm... because according to http://en.community.dell.com/support-forums/software-os/w/linux/consumer-linux.aspx it looks like they still don't have 10.04 support, and I thought a few months back I heard they had stopped selling new computers with ubuntu preinstalled... I know last year when I got my netbook it was damn hard to find
<ScottK> There's not much you can get from them.  That's for sure.  Netbooks and a couple of low end laptops seem like about it.
<cody-somerville> It highly depends on what region you're in.
<ScottK> OK.  Well being in the US, there
<ScottK> ... there's generally been more availability than elsewhere.
<cody-somerville> Also http://en.community.dell.com/support-forums/software-os/w/linux/consumer-linux.aspx looks like it is just out of date. It hasn't been updated since November 2009.
<maco> ScottK: person who was asking /quit
<ScottK> Oh.
<maco> there was a post a few day ago going "hey look they have stuff listed again"
<ScottK> Didn't notice.  Thanks.
<ScottK> Two weeks ago when I was buying a laptop there wasn't any.
<ScottK> Now I see two.  One netbook and one low end laptop.
<jcastro> ScottK: the systray thing isn't a technical limitation of unity though, that is a design decision, we could easily just turn that on
<jcastro> ScottK: that's my way of saying we're going to get mpt'ed wether the panel supports it or not. :)
<ScottK> ;-)
<jcastro> so it's not really "can't", it's "won't"
<ScottK> Right.
<ScottK> Although as long as won't is the position, then it's a fair point for arguing against it by default.
<ohsix> argh, broken clipboard; and broken recently
<poolie> hi, do i have to take any action to get my bzr sru approved from https://launchpad.net/ubuntu/maverick/+queue?queue_state=1&queue_text=bzr into maverick-proposed?
<poolie> or just wait?
<micahg> poolie: is it tied to an SRU bug?
 * micahg isn't sure if the standing exceptions require it
<poolie> it is
<poolie> bug 707075
<ubottu> Launchpad bug 707075 in bzr (Ubuntu Maverick) "[sru] lp-propose fails with a 404 error" [High,In progress] https://launchpad.net/bugs/707075
<SpamapS> poolie: Its on my todo for tonight or tomorrow to review that
<micahg> ah, SpamapS to the rescue :)
<poolie> thanks!
<poolie> just wondered if i had omitted to do anything
<micahg> poolie: so, you probably want to set to fix committed and unassign after you upload
<poolie> don't hesitate to ask me or jelmer if you have any questions or see any problems
<poolie> good idea
<micahg> poolie: err, actually you can leave it assigned since you uploaded :)
<poolie> why unassign?
<poolie> ah ok
<ohsix> where do i go to get eyes on a bug like 622639
<ohsix> ultimately the missing samples mean theres never a battery life estimate on the applet menu
<ohsix> hm, the status for upower in 629258 is not right, who is supposed to provide the estimation if the data is missing for the battery? currently the things talking to upower dont', but they use the other statistics; that piece of missing data keeps the default battery applet from showing any time remaining, or a percentage
<ohsix> it just says "estimating ..." forever, my bug was a dup; but this is the root of it, who is working on this? or who would be
<ohsix> the root of it is sometimes power_supply/BATn/current_now is sometimes 0 and theres no estimator like there used to be (effectively, when it was using hal)
<ohsix> it would be nice if someone would promote it again as a papercut, cuz apparently it leads to no battery life estimation (and no fallback to percentage in the applet ui) on a lot of dell/hp/compaq & other vendor laptops/batteries
<ohsix> kees: ping
<didrocks> good morning
<ohsix> kees: nevermind, only needed input on something and i figured it out
<pitti> Good morning
<didrocks> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Archive: Feature/UI freeze | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for dapper ->  maverick | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs | Patch Pilots: didrocks
<Jon--> I want to help out the community a little bit with something I've done. conky is out of date and has several bugs in it across all Ubuntu PPAs. I've compiled from source conky 1.8.1 using checkinstall so I have a .deb, I have created a user PPA on Launchpad. I'm brand new to this now, how do I package this deb into a PPA and generate the .changes file? Sorry for being so n00b. :O  I just want to help people trying to i
<Jon--> nstall this package...
<ohsix> hi, is there a tool that uses apt, accepts a package (say a virtual) and will tell you the size of it and all its dependencies?
<dholbach> good morning
<mvo> ohsix: its easiest to use python-apt for this
<mvo> ohsix: like "import apt; apt.Cache()["mypkg"].mark_install(); print cache.required_space
<ohsix> mvo: can apt be told to reinstall everything, then you could dry run something like apt-get install ubuntu-desktop, and it'd try and reinstall it and all the deps; thus telling you the size
<mvo> ohsix: you need give it different dpkg-status file as the base for the dependency calculation too
<brendand> is there a meta-package that will install the correct kernel (pae or non-pae) depending on my system?
<mvo> ohsix: the easiest way is to point it to a empty dpkg-status file (it is python-apt). what is the use-case you have in mind here? i.e. what problem do you want to solve?
<brendand> i know when i installed maverick it chose pae automatically somehow
<ohsix> mvo: no problem, just curiosity, i wanna see what a virtual and all its dependencies costs as far as size goes
<mvo> brendand: base-installer makes this decision (its part of debian-installer)
<mvo> ohsix: use apt.apt_pkg.config.set("dir::state::status", "/path/to/empty/file") before creating the apt.Cache() then you should get it
<ohsix> can i tell apt the same thing? empty dpkg-status (or rather dpkg with -o DPkg::)
<brendand> mvo - does it store what choice it made somewhere?
<brendand> mvo - actually my use-case is that i want to install the right one in the late command of the preseed
<brendand> mvo - so i need to know if it should be pae or not
<ohsix> mvo: also is there something i can get to get dpkg/apt/whatever to display all possible configuration that could be set? they're a bit hard (and a lot not mentioned) in the handbook documentation
<mvo> brendand: you could check the release-upgrader (update-manager). it uses base-installer to make the decision, in lp:update-manager DistUpgrade/get_kernel_list.sh
<brendand> mvo - might using dpkg --get-selections | grep linux-generic | awk '{print $1}' be safe?
<mvo> ohsix: all possible configurations in the sense of all possible "OR" targets?
<ohsix> mvo: like the DPkg:: and Apt:: options that are set in apt.conf(.d)
<mvo> ohsix: apt-config dump and /usr/share/doc/apt/examples/configuration-index
<ohsix> ah excellent, thanks
<ohsix> yeaaa that's the one i couldn't remember (apt-config dump)
<ohsix> mvo: After this operation, 1,991 MB of additional disk space will be used.
<ohsix> that worked great, thanks for the tips
<mvo> yw
<pitti> directhex, Laney, RAOF: how bad would it really be to drop the webbrowser widget from mono to fix bug 740815? with firefox' new release cycle this will just keep breaking underneath us anyway, and keeping it would cause a rather unacceptable continuous porting work overhead
<ubottu> Launchpad bug 740815 in xulrunner-1.9.2 (Ubuntu) "[FFe] Updates to enable us to drop xulrunner from main" [High,In progress] https://launchpad.net/bugs/740815
<pitti> I know that it wouldn't break anything in the archive, but wondering about third-party software
<pitti> but I guess that's a compromise we need to make, until the webkit integration is ready
<pitti> (yes, sorry, panic level rising)
<ohsix> hm
<ohsix> wouldn't the mono people  be generating patches for that if they were going to stick with it? i don't know how it's integrated now so that might be nieve
<RAOF> pitti: I don't have a good idea about how prevalent that is in third-party software :(
<pitti> ohsix: they are working on webkit integration, yes
<ohsix> RAOF: google code search?
<RAOF> ohsix: Not a bad idea :)
<ohsix> pitti: i mean while they do that, for new versions
<hrw> morning
<pitti> ohsix: same problem for them -- with the new release schedule this will become a huge pain for them as well
<pitti> and it's mainly the "gluezilla" package which needs porting; it's not directly tied to mono
<ohsix> yea :P but i mean, wont work they have to do, pain or not; be usable in the meantime, or are they just going to drop it entirely until the webkit portion is available?
<ohsix> i see
<RAOF> The webkit portion is mostly available, I think, although I haven't followed it closely.
<directhex> pitti, i think that's a reasonable thing to do for this cycle. it's likely too late to fix before release with your/andreia's webkit work
<directhex> pitti, it'd be nice to SRU it later though?
<pitti> directhex: to reenable it? yes, sounds ok, as this would merely reintroduce a package, thus low regression potential
<pitti> RAOF: would you have time to work on this? i. e. disable the webbrowser binary and gluezilla build-dep?
<RAOF> pitti: I guess so.  When's beta2 freeze?
 * RAOF probably won't do it today, given that it's 6:30pm
<pitti> RAOF: I guess around Monday
<RAOF> Ok.  I can do some work tomorrow, I guess.
<pitti> RAOF: it'd also be ok to drop it after beta-2, I think
<RAOF> Oh, in that case, yeah, totally.
<pitti> RAOF: can I assign the task to you then?
<RAOF> Yes, please do so.
<pitti> thanks
<ogra_> can someone bump the build status of https://launchpad.net/ubuntu/+source/unity/3.8.4-0ubuntu1/+buildjob/2433301
<ogra_> (it breaks image builds for armel atm)
<diwic> ogra_, hi there...do you think we have come to a reasonable conclusion for all parties with PA UCM patches?
<ogra_> diwic, only using the first four and the config files ?
<diwic> ogra_, yeah
<ogra_> if it works i'm happy
<ogra_> will have to try it, sadly my day is full of meetings so it will take some time
<diwic> ogra_, will you help to test it (or make sure that someone tests it)?
<ogra_> i'll also ask the team, but first we need armel packages
<diwic> ogra_, just take TheMuso's source package and build it the way you usually build armel packages
<ogra_> yep, indeed
<doko> chrisccoulson: ping
<chrisccoulson> hi doko
<Riddell> sladen: going to upload the font today to fix bug 744812 ?
<ubottu> Launchpad bug 744812 in Ubuntu Font Family "FontConfig/Qt stack choke on Ubuntu Medium font meta-data (No medium in Inkscape and too bold in Qt apps)" [Undecided,Confirmed] https://launchpad.net/bugs/744812
<didrocks> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Archive: Feature/UI freeze | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for dapper ->  maverick | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs | Patch Pilots:
<jdstrand> didrocks: hey, sorry to bother you. what is the name of the 'ubuntu icon' in the upper left? It doesn't show up still and I'm looking for bugs on it
<didrocks> jdstrand: it's the bfb
<didrocks> jdstrand: are you mirroring your screen?
<jdstrand> didrocks: yes, mirrored
<tjaalton> are there installation images that can just be copied to a usb drive with dd? ("hybrid", i'm told)
<didrocks> jdstrand: it's known and fix committed :)
<bdrung> didrocks: "The branch looks code" :D
<jdstrand> didrocks: \o/
<didrocks> bdrung: yeah, there was some code in the branch, awesome, isn't it! :)
<cjwatson> tjaalton: not yet, sorry, I really meant to do that for natty but didn't quite get round to it, and it's too risky now :-/
<didrocks> bdrung: well, I have to make one typo at every mail :-)
<cjwatson> needs backporting some bits and pieces to lucid for the CD image build machine
<cjwatson> (for jigdo hybrid support)
<tjaalton> cjwatson: ok, good to know it's on the radar
<bdrung> diwic: can you give me a debdiff for bug #733424 (with dep-3 header in the patch)?
<ubottu> Launchpad bug 733424 in pulseaudio (Ubuntu) "pulseaudio crashed with SIGSEGV in module_jack_sink_LTX_pa__init()" [Medium,Fix committed] https://launchpad.net/bugs/733424
<diwic> bdrung, it is already in the bzr tree and waiting for upload by TheMuso
<bdrung> ah, ok
<bdrung> diwic: so i can unsubscribe the sponsors team?
<diwic> bdrung, yes
<psusi> hrm... a fuse mount doesn't actually have an underlying block device, so it isn't possible to umount by device is it?  so shouldn't ntfs-3g provide a umount.ntfs to handle this properly?
<kenvandine> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Archive: Feature/UI freeze | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for dapper ->  maverick | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs | Patch Pilots: kenvandine
 * dholbach hugs kenvandine
<ohsix> ah-ha, sun-java6 finally shows up
 * kenvandine hugs dholbach
<ev> mvo: would you mind making lp:apt-clone team-accessible? I have a one liner fix for a crasher that a merge proposal seems a bit too heavy for.
<mvo> ev: sure, hold on a sec
<mvo> ev: I set it to core-dev for now
<ev> coolness
<ev> sorted, thanks
<ohsix> can't sun's java package be setup to use pulseaudio for output, using the classpath driver? (openjdk already does it)
<stgraber> speakman: ping
<stgraber> oops, auto-complete fail :(
<stgraber> SpamapS: ping
<pgraner> didrocks, ping see https://bugs.launchpad.net/unity/+bug/744325/comments/30  what would you like me to do?
<ubottu> Ubuntu bug 744325 in unity (Ubuntu Natty) "Unity Launcher stops autohiding and is not responsive" [High,Fix released]
<didrocks> pgraner: someone already opened another bug on QT apps and intellihide, it's a separate issue than the one reeported there
<pgraner> didrocks, ahhh didn't realize mumble was a qt app, then all is good
<didrocks> pgraner: hope we can fix it though, they are doing weird dnd stuff ;)
<pgraner> didrocks, ack, its quite annoying
<pitti> dpm: FYI, I requested a full natty langpack export now, so I'll build/upload new natty langpacks on Sunday evening
<pitti> cjwatson ^ FYI
<bidream> hello all
<bidream> i would like to know what is the best way to read a config file from a c code
<speakman> stgraber: :)
<bidream> Chipzz i know, i am developping for ubuntu ;)
<Chipzz> bidream: irrelevant
<dpm> pitti, ah, thanks. But I thought you had already done that a few days ago. (btw, it's good that you've done it now, I've just noticed banshee has changed the domain from banshee-1 to banshee and I fixed it in LP - the next langpacks should have the .mo file under the correct domain)
<bidream> stspeakman strgraber  , thanks for the hint, it is the most usual one ?
<doko> chrisccoulson, pitti: http://people.canonical.com/~doko/tmp/binutils_2.21.0.20110327-2ubuntu2~ppa1_i386.deb
<doko> test case doesn't fail with this one, please retry a firefox build
<pitti> ooh, thanks doko
<chrisccoulson> doko - awesome, i will kick that off in a second
<chrisccoulson> i will be so glad to get this one fixed :)
<bidream> ho , as i am here know , i think i have suggestion for peoples preparing the livecd version, it should be good to enable to rebuild grub from the livecd menu as it is possible from the failsafe meanu of ubuntu
<RoAkSoAx> howdy. I was wondering if MIR's need FFe?
<RoAkSoAx> doko: ideas ^^??
<ev> mvo: what was your intent with actiongroup in apt_clone.py:358? To use it as a context manager?
<ev> mvo: also, would you be comfortable with me adding running pyflakes to make test (for non-test code only)?
<ev> so we avoid typo bugs
<mvo> ev: sure, thats fine
<ev> cool
<mvo> ev: and maybe coverage to see how much is missing
<ev> coverage.py makes me smile
<mvo> ev: the actiongroup is pretty much a context manager, as long as its alive apt will not do its internal "is_garbage" calculation, this speeds the code up quite a bit
<mvo> I should ahve added a comment
<ev> well you assign it to a variable that never gets used, which is slightly confusing
<ev> if you wouldn't mind just removing the LHS and letting garbage collection do its thing
<RoAkSoAx> cjwatson: howdy! Do MIR's need FFe?
<cjwatson> RoAkSoAx: that depends on whether they're features.
<RoAkSoAx> cjwatson: if it's a small python module that hasn't been updated since maverick?
<RoAkSoAx> cjwatson: or should I just file FFe to be safe?
<cjwatson> I don't know, don't have time to think about it right now, sorry
<RoAkSoAx> cjwatson: ok, no prob. Thanks!
<sladen> jdstrand: Big Friendly Button.  But {distro,launcher,ubuntu}-{icon,logo} will probably get recognised
 * jdstrand nods
<jdstrand> sladen: fyi, I looked for an open bug on my problem, but couldn't find one. I'm told the fix is committed somewhere
<doko> chrisccoulson: any feedback?
<chrisccoulson> doko - sorry, I got sidetracked after I had to update my chroot
<chrisccoulson> it's building now though
<chrisccoulson> it takes a while ;)
<sladen> jdstrand: that is the bug?
<jdstrand> sladen: I'm sorry, you seemed to pick up on backscroll wrt to bfb, so I thought you saw the rest. my bug is that bfb does not display here on up to date natty. I do mirror (ie, with the same resolution) my screen with an external monitor. I have not (yet) tested it without the external monitor
<seb128> jdstrand, it's a known bug with mirror
<seb128> jdstrand, njpatel fixed it today
<seb128> jdstrand, it will land in natty on monday
<jdstrand> right, I was told the fix was committed. I could not find the bug number (I wanted to make sure it wasn't a different bug)
<seb128> jdstrand, http://bazaar.launchpad.net/~unity-team/unity/fixes-2011-04-11/revision/1090
<jdstrand> heh
<jdstrand> no wonder: "panel superposition"
<jdstrand> that was not my search term
<jdstrand> seb128: thanks! :)
<seb128> jdstrand, you're welcome
<seb128> jdstrand, well we discussed it on IRC this morning with neil
<seb128> so yeah the description doesn't match exactly but it's the same bug
<jdstrand> cool, thanks
<jdstrand> not criticizing or anything-- just kinda hard to find :)
<jdstrand> keep in mind, I didn't know what 'bfb' was until today, so grain of salt and all that ;)
<seb128> jdstrand, yeah no worry ;-)
<lamont> so resizing a window should really resize it still, right?
<stgraber> ScottK: what's the most up to date working daily-live for Kubuntu ?
<Riddell> stgraber: beta 1
<stgraber> Riddell: ok, I guess I'll have to give 4GB of RAM to that VM so I can update it a bit :)
<kenvandine> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Archive: Feature/UI freeze | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for dapper ->  maverick | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs | Patch Pilots:
<nigelb> dbarth: You might want to join us in #ubuntu-classroom-backstage
<lamont> so now it's not  just windows that decides that putting a window at the top of the screen means I want it full screen??  sigh
<pitti> hm, here you actually have to try to push it beyond the top; I can attach it to the top edge just fine
<SpamapS> stgraber: pong. sorry, you still wanted a 'dpkg -l' right?
<SpamapS> stgraber: I uploaded dpkg-l.txt to bug 752393 .. note that the output has changed slightly (not sure why), but its still running lines from plymouth and lsb init scripts together
<ubottu> Launchpad bug 752393 in lsb (Ubuntu) "lsb init scripts show line buffering problems on bootup" [Medium,Confirmed] https://launchpad.net/bugs/752393
<stgraber> SpamapS: thanks, I'll diff that with what I have here
<chrisccoulson> doko / pitti - the binutils change looks good so far
<chrisccoulson> the resulting binary looks correct, i just need to test it out
<chrisccoulson> ^^kees ;)
<chrisccoulson> yay, pie build of firefox is working \o/
<chrisccoulson> time to drink lots of beer now
<cjwatson> excellent, well done you and doko
<micahg> thanks chrisccoulson and doko \o/
<stgraber> ScottK: ping
<stgraber> ScottK: oh, ignore that, Colin's comment answers my question (bug 628906)
<ubottu> Launchpad bug 628906 in ubiquity (Ubuntu) "ubiquity-kde manual partition very painful" [Medium,Triaged] https://launchpad.net/bugs/628906
<kees> chrisccoulson: \o/ that rocks!
<kees> chrisccoulson: thank you so much for tracking this down! :):)
<chrisccoulson> kees - no problem. i'm just glad it's sorted now. this one gave me a couple of sleepless nights this week ;)
<kees> chrisccoulson: I know nothing about (thread) TLS (I only understand crypto TLS), so I might pick your brain at UDS to better understand what was going on in that.
<chrisccoulson> kees - sure, no problem. i didn't know that much about it before this week either. it's been an interesting week ;)
<kees> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Archive: Feature/UI freeze | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for dapper ->  maverick | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs | Patch Pilots: kees
<kees> jhunt_: hi! are you around by chance?
<jhunt_> kees: hi - just about :)
<kees> jhunt_: hi, I was just looking at some merges for upstart and found that you'd already merged it into your pending branch, so I'm all good now.
<kees> jhunt_: specifically https://code.launchpad.net/~clint-fewbar/ubuntu/natty/upstart/upstart-job-change-restart/+merge/52547
<kees> slangasek: can you shine any light on this merge? I'm not sure where/what it's for exactly. https://code.launchpad.net/~jcrigby/ubuntu/natty/u-boot-linaro/proposed-2011.03.2/+merge/54277
<slangasek> kees: hmm let me check with the submitter
<jhunt_> kees: yes, sorry! you are right - that is in my latest 0.9 + natty branches.
<jhunt_> kees: err... just the natty branch even :)
<kees> jhunt_: cool, no worries. I just wanted to get it off the sponsorship radar. :)
<mdeslaur> kees: hey mr patch pilot, here's one for you: https://bugs.launchpad.net/ubuntu/maverick/+source/nautilus/+bug/662194
<ubottu> Error: Could not parse data returned by Ubuntu: list.index(x): x not in list (https://launchpad.net/bugs/662194)
<mdeslaur> kees: not sure why it doesn't appear in the qa sponsors list anymore
<kees> mdeslaur: cool; I'll poke at it.
<mdeslaur> kees: natty is done...it's now just an sru for lucid and maverick
<kees> mdeslaur: 662194 doesn't have an SRU justification or a testcase. looks simple enough, though.
<kees> mdeslaur: I can prepare the uploads to -proposed, are you able to write a justification and testcase?
<mdeslaur> kees: my mom keeps hitting that bug...it drives me _nuts_
<mdeslaur> kees: sure, I'll add it to the bug, give me a few minutes
<kees> mdeslaur: also there are no debdiffs for maverick and natty :P (I think this is why the sponsor group wasn't subbed yet)
<kees> I'll work up the debdiffs
<mdeslaur> kees: there's a merge request, look at the top of the bug
<mdeslaur> kees: click on the "diff" links
<kees> oh hey look, branches
<mdeslaur> kees: I've added a blurb to the bug, you just have to subscribe ubuntu-sru when you're done uploading
<mdeslaur> kees: thanks
<kees> mdeslaur: you got it; thanks! I'm getting the branches merged and the code built now.
<kees> mdeslaur: hah. upstream closed it as "obsolete" since they're all 3.0 shiny now :P
<mdeslaur> kees: yeah, they've been doing that for all gnome 2 bugs for a while now
<kees> looooovely
<seb128> james_w, hi
<james_w> hi seb128
<seb128> james_w, how are you?
<james_w> seb128, good thanks, how about you?
<seb128> james_w, I'm a bit tired but fine thanks ;-)
<seb128> james_w, when you have some time could you send an email to an ubuntu list explaining wth are those sponsoring request you keep feeling for import vcs diverting for reasons nobody understand?
<james_w> seb128, I can
<james_w> seb128, I don't do it though, a script does
<seb128> james_w, I still don't know why that happen and I know other people got confused
<james_w> and it is buggy, which is probably why you can't understand them
<seb128> well they queue on the sponsoring list
<seb128> so patch pilot have to deal with those and quite some are getting confused
<seb128> I guess the others one just ignore them :p
<seb128> but still it's confusing and annoying
<seb128> those are things we don't do anything for, we just do normal uploads, it's disturbing
<seb128> james_w, thanks! ;-)
<seb128> ok, that's wrong
<seb128> kees, I just noticed you did a non change upload to fix one of those import issues, is that required?
<stgraber> cjwatson: do you have a few minutes to explain me how the whole plymouth boot.log thing is supposed to work ? (assuming you know :))
<stgraber> cjwatson: my understanding is that plymouthd is usually running, plymouth-upstart-bridge sends the upstart events to plymouthd and the upstart plymouth-log upstart task dumps that to disk when it's mounted
<stgraber> cjwatson: so on my test system I started plymouthd + plymouth-upstart-bridge in debug mode. When stopping/started jobs I see them in the log but nothing ever reaches boot.log, though lsof shows that plymouthd has it open ...
<kees> seb128: well, I'm not sure -- I thought it would be since otherwise the bzr tree and the archive would be out of sync (i.e. the archive didn't have the typo fix that was in the old bzr tree)
<seb128> kees, ok, see what I was just saying to james_w, I don't even understand why those happen to start
<kees> seb128: as in, it was a no-change to the source, but the changelog and patch metadata had changes
<kees> seb128: yeah, I did'nt realize it was an automated thing until I read that
<kees> seb128: but it seemed so trivial, I just did it to get it out of the sponsorship queue
<seb128> kees, well I was just raising it because the sponsoring queue has a few of those and it's not new
<seb128> like dholbach asked yesterday why they are here
<kees> seb128: cool, yeah, this is the first i'd seen it.
<seb128> so I've been basically ignoring them since I don't understand the issue but I would like an explanation ;-)
<micahg> seb128: most likely someone used UDD then someone else sponsored a patch from bug which may or may not be the same
<seb128> not likely
<seb128> like gtksourceview3 there was not a sponsoring request but an upload by somebody who has upload rights
<seb128> isn't the autoimported supposed to deal fine with upload being different from commits anyway?
<micahg> it used to overwrite them if there were no tag, now it creates one of these branches
<dobey> kees: hi there :) can you sponsor a banshee upload for me? i just proposed the branch merge
<kees> dobey: hi! sure, what url? I'm currently looking at 2 other uploads at the moment, so I'll check back with you in a moment...
<dobey> kees: https://code.launchpad.net/~dobey/ubuntu/natty/banshee/fix-and-amz/+merge/57016 thanks!
<CardinalFang> kees, Hi.  dobey is 1 meter <- that way from me, and I also need someone to look at a source-package proposal, but for desktopcouch.
<CardinalFang> https://code.edge.launchpad.net/~cmiller/ubuntu/natty/desktopcouch/1.0.7-0u1/+merge/57014
 * CardinalFang hates to pile on.
<kees> CardinalFang: excellent, I will queue that after dobey's merge. :) thanks!
<kees> piling on was what the patch pilot is here for :)
<kees> s/was/is/
<CardinalFang> kees, you win beers from me.  Thank you.
<kees> \o/
<kees> dobey: will I suddenly be flamed for being the person to upload that amz url change?
<Laney> er
<Laney> I just uploaded banshee
<Laney> said I was doing it on #-desktop
<kees> Laney: with or without merge 57016?
<dobey> without
<kees> okay
<Laney> without, I wasn't asked to merge it
<dobey> well i didn't see you were merging banshee
<Laney> no worries
<dobey> i'll update my branch
<kees> thanks
<Laney> is the u1 fix upstream?
<dobey> it is submitted, but not reviewed, i guess i could just commit it there though
<kees> dobey: ? it's not functional? so that upload would break since u1 doesn't support it yet?
<Laney> we are planning on cherry-picking aggressively from stable-2.0
<dobey> kees: what do you mean?
<Laney> so if you get it there then it'll flow from debian
<kees> dobey: I must be confused. :)
<dobey> Laney: well we need it now, since it fixes a pretty annoying bug
<kees> +- return "http://integrated-services.banshee.fm/amz/redirect.do/" + Country + "/" + action;
<kees> 54	++ return "https://one.ubuntu.com/music/store/amz/" + Country + "/" + action;
<kees> that change requires that https://one.ubuntu.com/music/store/amz/" + Country + "/" + action is live, yes?
<kees> but you just said it's not live?
<Laney> jus' sayin, in the interests of delta minimsiation
<Laney> but ymmv, et cetera
<dobey> kees: it is live. we have a couple fixes to deploy on the server on tuesday but if you search for music it will work
<kees> dobey: ah-ha! okay. thanks!
<dobey> kees: the other patch is upstream but not reviewed yet
 * kees nods
<dobey> Laney: yeah, i'm all for that too. but the patch can just be removed when it's pulled from upstream later, too
<Laney> yep
<Laney> all I'm saying is that in general I'm more than happy to pull patches from stable-2.0 for you
<dobey> Laney: sure. thanks. i think it's more important for us to have music show up in banshee right now, than to have it committed upstream.
<dobey> ugh. the banshee 2.0.0 isn't merged into the bzr branch yet
<vish> jdstrand: just plain âcompizâ should do a compiz restart the replace is implied, Amaranth mentions that âcompiz âreplaceâ is NotTheRightWayâ¢ :)
<jdstrand> vish: interesting. and fast response
 * jdstrand goes to change
<jdstrand> vish: done. thanks :)
<vish> np.. :)
<kees> CardinalFang: do you have the orig/dsc/etc for the new upstream release?
<CardinalFang> kees, sure.
<CardinalFang> kees, orig: http://launchpad.net/desktopcouch/trunk/1.0.7/+download/desktopcouch-1.0.7.tar.gz
<dobey> kees: are you -0700 or -0800?
<kees> dobey: I'm US pacific. I never remember my offset due to DST :)
<slangasek> -0700 currently
 * kees thanks slangasek
<slangasek> we're 8 hours behind England
<dobey> kees: ah ok. thanks
<slangasek> which is currently one hour ahead of UTC :)
<CardinalFang> kees,   http://sandbox.chad.org/desktopcouch_1.0.7-0ubuntu1_packaging.tar   Beware, this unpacks in PWD.
<kees> CardinalFang: cool; thanks. the orig I think will get me sorted for an upload. orig + branch works :)
<CardinalFang> kees, I'm a slave to the wonders of bzr bd now.  :(
<slangasek> oh, but then you have pristine-tar metadata surely? :)
<kees> CardinalFang: I don't trust it yet :)
<kees> CardinalFang: dunzors
<kees> dobey: how would you like me to handle your banshee merge?
<CardinalFang> kees, Internet high-five.  Thank you, sir.
<kees> np :)
<dobey> kees: i'm waiting for the bzr branch to update still, with the 2.0.0 upload, so i can update my branch
<kees> dobey: okay, I'll check back later; going to task switch now :)
<dobey> kees: ok, thanks much
<kees> np
<kees> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Archive: Feature/UI freeze | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for dapper ->  maverick | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs | Patch Pilots:
<dobey> kees: bzr still seems not updated for banshee and time to get dinner here. if it's still not updated when i get back, i guess i'll just make a debdiff instead. cheers
<kees> dobey: okay, cool
<Laney> you can probably import-dsc to the bzr branch
#ubuntu-devel 2011-04-09
<Amaranth> vish: compiz --replace should be ok too, afaik that's the only default option we pass if you don't do any manually
<cjwatson> stgraber: plymouth batches up everything it sees on the console and copies it to boot.log.  In your case, it sounds like plymouth-upstart-bridge isn't writing them to the console for some reason?
<cjwatson> stgraber: it might depend on when p-u-b (hey, good acronym, I never thought of that ...) gets started; it can't start until dbus is up
<cjwatson> stgraber: might be worth passing --verbose as a kernel parameter and looking at upstart output, though if you're doing that it might be easiest to use a serial console so that you can capture the output
<SpamapS> Ugggh.. -rw-r--r-- 1 root root 0 2011-04-07 10:01 /usr/lib/pymodules/python2.7/bzrlib/__init__.py
<slangasek> ugh?
<directhex> slangasek: 0 bytes?
<SpamapS> my natty updates yesterday crashed in the middle of update-initramfs .. (ubuntuone-syncdaemon was eating RAM like the fat guy on the meaning of life)...
<slangasek> there are various reasons for a 0 byte __init__.py file to be used
<SpamapS> bzr won't work.. network manager applet is borked..
<SpamapS> things are screwed. :-P
<SpamapS> [ ] this close to reinstall. :(
<slangasek> though I don't recall /usr/lib/pymodules being a standard path
<slangasek> and I don't have that path at all here, hmm
<SpamapS> slangasek: thats supposed to be a symlink
<slangasek> is it?
<SpamapS> yes, all the other ones in those dirs are symlinks
<SpamapS> hmmm.. is python-support not cleaning up after itself?
<SpamapS> it claims to own /usr/lib/pymodules
<SpamapS> when I removed /usr/lib/pymodules/python2.7/bzrlib ... bzr started working again.
<SpamapS> So..
<SpamapS> there may be a problem when people switch modules to dh_python2 from python-support
<slangasek> it might be related to your crash, in fact
<SpamapS> Seems the dirs are left behind in /usr/lib/pymodules ..
<SpamapS> but won't be updated
<slangasek> because I didn't have /usr/lib/pymodules/python2.7/bzrlib here, which is why I was wondering what you were talking about :)
<SpamapS> slangasek: well anything that uses python-support will dump symlinks and .pyc files in there..
<SpamapS> slangasek: I have > 100 dirs in there
<slangasek> sure - but for me, bzrlib did *not* leave files behind when switching
<slangasek> most of those others are, I suspect, from packages still using python-support
<SpamapS> dh_python2 *does* remove pycentral bits..
<SpamapS> slangasek: yeah again.. probably related to my broken upgrade
<SpamapS> the prerm does make an attempt to take care of this.. haven't looked at the pre-dh_python2 prerm ..
<psusi> cjwatson, this is so goofy.  that partman hang from those new scripts seems to be because umount is failing to unmount my windows partition.  umount fails because it looks like there is a bug in umount where it is passing the device name to the kernel umount() instead of translating it to the mount point.  It seems there are two causes of this: 1) ntfs-3g canonicalizes the /dev/mapper/ name to /dev/dm-n, and trying to umount the /dev/dm-
<psusi> n name fails as well it seems because umount is interpreting the - in some odd way as not part of the device name
<psusi> so this looks like 3 bugs for the price of one... guess I need to file a new bug on ntfs-3g and one on mount
 * psusi hugs qemu-kvm
<ScottK> SpamapS: python-support rebuilds it's symlink farm after package updates, so an interrupted upgrade could explain what you saw (design 'limitation' in python-support)
<dobey> kees: hey, still around?
<dobey> kees: https://code.launchpad.net/~dobey/ubuntu/natty/banshee/fix-and-amz/+merge/57041 is against 2.0.0 if you could sponsor it real quick when you see this. thanks again. i gotta go now though. cheers.
<mantiena> Hello all
<tjaalton> slangasek: oops, sorry about libx11 :/
<chrisccoulson> doko_ - thanks for the binutils upload
<doko_> chrisccoulson: np
<abhinav-> what data is indexed by mandb ?
<StevenK> Manual pages
<abhinav-> StevenK: so it stores the whole man page or a certain portion of it ?
<StevenK> abhinav-: It indexes it for searching.
<StevenK> The manual page itself is already stored on the filesystem.
<cjwatson> abhinav-: there's a description of what it indexes in lexgrog(1)
<cjwatson> (the WHATIS PARSING section)
<cjwatson> abhinav-: why?
<abhinav-> cjwatson: thanks. I have applied for a GSoC project for NetBSD. The task is to create a full text search tool for searching manual pages :)
<cjwatson> abhinav-: I didn't know NetBSD used man-db
<abhinav-> cjwatson: no it doesn't. they have asked to look for existing tools which index man pages, and explain why I should do it from scratch
<cjwatson> abhinav-: I've thought about doing such a thing in man-db, but so far I've concluded it may not be worth the time investment, since on my system 'man -K' can do a brute-force search of all manual pages in under a minute
<cjwatson> (it's implemented fairly efficiently)
<cjwatson> well, efficiently as brute-force searches go
<abhinav-> cjwatson: but it will search only the name section ?
<cjwatson> -k searches the name section, -K searches the whole text
<abhinav-> oh
<cjwatson> if anyone wants to do a full-text index in man-db, it should probably be based on an existing widely deployed engine, probably xapian
<cjwatson> and probably ought to put effort into things like matching rendered text rather than the groff input
<abhinav-> yes xapian is a good choice.  they are more inclined to using sqlite's FTS module.
<cjwatson> man-db is GPLv3, though, so I expect NetBSD won't want it ;-)
<abhinav-> yes :)
<cjwatson> (and I don't want to relicense)
<abhinav-> yes, I will just mention it as part of my case study :)
<cjwatson> but, yeah, consider how much effort it's worth, given the relatively small amount of data compared to the power of even reasonably modern systems
<cjwatson> man-db's 'man -K' gains a lot even just from doing its own decompression and searching rather than execing external programs for that
<cjwatson> I'm interested in whatever you come up with, though
<abhinav-> oh yes, that's a good insight. I did try indexing in sqlite database, and  tried some search queries, results weren't very encouraging
<abhinav-> cjwatson: thanks :)
<j1mc> hi all - it seems like unity ui changes are still landing. is that correct?
<debfx> ScottK: could you please approve bug #755661
<ubottu> Launchpad bug 755661 in lucid-backports "Please backport dh-autoreconf" [Undecided,New] https://launchpad.net/bugs/755661
<directhex> yay dh-autoreconf
 * ScottK looks
<ScottK> debfx: Done.
<debfx> thanks
<AnAnt> Hello, I am working on a derivative distro, is it possible to change the default session from Unity to Gnome classic ?
<directhex> in a deriv? sure.
<ion> yes
<AnAnt> directhex: how ?
<AnAnt> through a config file ? a gconf setting ?
<directhex> AnAnt, presumably through a session file, pointed at by gdm
<AnAnt> ?
<slangasek> tjaalton: it's ok, it's clearly my fault for not getting the change committed to the branch :)
<AnAnt> directhex: could you explain further ?
<directhex> reasonably sure just dropping a "default.desktop" symlink in /usr/share/xsessions is enough. but it's WAY out of my usual area of expertise.
<AnAnt> thanks
#ubuntu-devel 2011-04-10
<slangasek> lucas_: so I know your relationship with ruby packaging runs hot and cold... :) do you have any interest in fixing bug #749099, or know someone who might?  libcairo-ruby fails to build because it bypasses pkg-config and tries to parse .pc files directly
<ubottu> Launchpad bug 749099 in libcairo-ruby (Ubuntu) "libcairo-ruby version 1.8.1-1build1 failed to build on i386" [Medium,Triaged] https://launchpad.net/bugs/749099
<infinity> slangasek: Ick.
<slangasek> infinity: is that the sound of you volunteering to fix it? :)
<infinity> slangasek: It's the sound of me vomiting a little at people who feel the need to re-invent pkg-config.
<ScottK> If you're going to be around Ruby much, you'll be needed a large barf bag.
<slangasek> infinity: I should share the list of all the things I've had to fix in build systems for multiarch :)
<slangasek> php still wins, hands down
<slangasek> but you probably could already have guessed that :)
<ScottK> yeah.  that was a given.
<infinity> slangasek: With our history with it, I can't imagine it surprised you, at least
<slangasek> no, but I realized I'd repressed just how bad its autoconf usage was
<infinity> Heh.
<ScottK> cjwatson: It looks to me like something ate your dh-autoreconf backport https://launchpad.net/ubuntu/+source/dh-autoreconf/+publishinghistory
<ScottK> re Bug #755661
<ubottu> Launchpad bug 755661 in lucid-backports "Please backport dh-autoreconf" [Wishlist,Fix released] https://launchpad.net/bugs/755661
<ScottK> (I don't see it in New either)
<psusi> say, umm... don't we have an auto generated list of packages that ftbs?  so why file bug reports on them as well?
<slangasek> because a list of packages that ftbfs doesn't let you claim/assign the issues, triage them, or file them against different packages that are the ultimate source of the breakage
<cjwatson> ScottK: no, I just forgot to flush it
<ScottK> cjwatson: That's a relief.
<cjwatson> ScottK: apologies for the duplicate NEW mails, lag-induced errors
<ScottK> No problem.  Thanks for taking care of it.
<cjwatson> accepted now
<ScottK> Great.  I'll take care of binary New once it hits.
<cjwatson> thanks
<psusi> I have always explicitly specified -r or -h, but if you don't specify, shutdown seems to drop to runlevel s.  Is this normal?  the man page does not say what happens if you don't use any switches
 * psusi is getting the feeling this is normal and this bug report should be converted into a request to improve the man page
<abhinav-> cjwatson: Hi, one more question. Is "man -K" available only on Ubuntu ? I tried it on Opensuse , it wasn't available , although opensuse is also using man-db.
<ohsix> doesn't that just call apropos, or vice versa
<abhinav-> man -k calls apropos, in Ubuntu man -K does a full text search over man pages :)
<hyperair> ooh nice. i never kenw that.
<ohsix> you can grep the debdiff on the package page to see if it's added as a patch; that'll literally answer your question, but i don't personally know
<ohsix> i see --global-apropos on lots of online manual listings
<abhinav-> what does --global-apropos do ?
<hyperair> maybe they all use ubuntu ;-)
<hyperair> abhinav-: it's the longname for -K
<abhinav-> oh
<hyperair> it's in man man
<ohsix> hyperair: looks like it could be :D
<hyperair> heheh
<abhinav-> :)
<ohsix> hyperair: quick look at man page i know is modified for ubuntu doesn't have those modifications though
<hyperair> mm what about debian?
<hyperair> debian has -K as well.
<ohsix> debian is awesome; they could be getting the man pages from there as well
<lucas_> slangasek: [libcairo-ruby] I'll take a look
<SpamapS> hrm.. autofs is frustrating.. no way to inform it that it should retry all failed mounts
<ohsix> SpamapS: what are you using it for?
<SpamapS> personally, nothing
<slangasek> lucas_: ok :)
<SpamapS> but trying to pinpoint when to start it during the boot
<ohsix> its a bit of a speciality for a desktop thing when there's udisks
<SpamapS> ohsix: basically in a server with static interfaces, 'started networking' is the exact right place to start autofs. On machines w/ dhcp or transient network connections.. this results in an autofs that takes 60 seconds to notice that it can mount an NFS share that it couldn't before. :-P
<ohsix> i see
<SpamapS> The kernel caches negative mount attempts and provides no way to flush that cache. :-P
<SpamapS> just times them out
<ohsix> theres a fuse filesystem that can do the same, but run arbitrary commands too
<SpamapS> well regardless of that.. the current start on is totally broken.. 'and mounting TYPE=nfs' .. not sure what zul was thinking there. :-P
<ohsix> lots of stuff is broken/weird with nfs :D
<SpamapS> well autofs has lots of uses w/o nfs.
<ohsix> right
<SpamapS> and mounting is only emitted by mountall.. so not sure how it relates to autofs
<ohsix> just saying theres a lot of weirdness to accept with nfs; how autofs interacts with it is just another one
<SpamapS> meh.. autofs doesn't care what its mounting really.
<ohsix> well mounting nfs manually is weird too; so i don't see how it'd drop out of the equation
<SpamapS> Yeah it just depends on how you want to use nfs
<lifeless> SpamapS: thats an oxymoron, no ?
<SpamapS> true.. nobody *wants* to use NFS
<SpamapS> lifeless: so, are you convinced yet that Cassandra is t3h suck? Or do I need to put Solandra/Lucandra on my oneiric-alpha-1 todo?
<StevenK__> SpamapS: Bah, I use NFS here.
<Guest27069> Services, bite my shiny metal ...
<lifeless> SpamapS: I got good feedback from mdennis
<lifeless> SpamapS: I thought I forwarded his 'can I'd love to come to UDS' mail to you/
<lifeless> s/can/and/
<SpamapS> lifeless: You may have. I'm just watching each patch release totally destroy at least a few peoples' installs and thinking they really don't understand what a stable release is yet.
<lifeless> SpamapS: ouch
<lifeless> SpamapS: that part I have no experience with yet
<lifeless> SpamapS: have you played with lp:oopsrespository ?
<lifeless> SpamapS: thats what I need solandra for
<lifeless> s/need/think it might be nicer than solr
<SpamapS> 0.7.1 and 0.7.2 were particularly ugly.. 0.7.3 gives you the tools to clean up the mess of those releases.. but then 0.7.4 broke anybody who went from < 0.7.3 to 0.7.4 ...
<lifeless> SpamapS: though, TBH, if its still got the insane xml file for config
<SpamapS> I haven't looked at all
<lifeless> SpamapS: thats a bit uncool
<SpamapS> It does seem like the best option for a hyper-scalable text search engine.
<SpamapS> I have to wonder if there is something similar for Hbase
<SpamapS> hmm.. I'm trying to upload a new version of autofs5 but dput is erroring out with "550 Changes file must be signed with a valid GPG signature: Verification failed 3 times: ["(7, 9, u'No public key')", "(7, 9, u'No public key')", "(7, 9, u'No public key')"] : Permission denied.
<geser> SpamapS: you used the right gpg key (the one LP knows about)?
<SpamapS> geser: indeed, F4BCB38E
<SpamapS> have used it to upload before
<SpamapS> wondering if my recent python problems might be the culprit
<SpamapS> no.. something else.. dupload has the same problem
<geser> if gpg --verify works on the .changes files, then I've no idea and try in #launchpad
<geser> it's not dput generating the error message but the ftp server on LP
<geser> alternatively you can also try to upload via sftp
<SpamapS> yeah I was thinking maybe dput was mangling the file
<SpamapS> hrm looks like it worked the first time despite the error
<lifeless> so we check the signature during the ftp session now
<lifeless> which is pretty cool
<lifeless> Unless others are having the same issue
<slangasek> unless you started checking within the past 2 hours, I'm not
<lifeless> nope
<lifeless> a week or so now
<lifeless> we were hoping it would stop the mysterious 'I uploaded and no error and no email back' situation
<lifeless> bigjools blogged aboot it
<tjaalton> slangasek: actually, 1.4.2 was the first time there _was_ an ubuntu branch, it had been a local one until then.. I just should've checked the archive too before uploading
<slangasek> tjaalton: oh, in that case yes, I blame you! ;)
<tjaalton> darn :)
<tjaalton> can't keep my mouth shut
<slangasek> ;)
<tjaalton> there's still xserver 1.10.1rc2 and mesa 7.10.2 the team would like to upload before the freeze, libx11 was just a warmup :)
<cjwatson> abhinav-: it's not Ubuntu-specific; I implemented it in man-db upstream.  openSUSE are probably just a few versions behind and need somebody to prod them to come up to date.
<cjwatson> abhinav-: The other GPLed man implementation, which used to be in Fedora (though Fedora switched to man-db recently) actually had -K first, although the implementation wasn't as good so it was several times slower to run.
<abhinav-> cjwatson: oh ok. thanks. I was googling to learn more about man-db. I suppose man-db handles internationalization properly as opposed to the old man implementation ?
<cjwatson> yes
<cjwatson> when distros have switched to it, I think that's been the main reason for them
<abhinav-> cjwatson: yes, I saw mailing list discussions, all of them had trouble with internationalization
<cjwatson> yes, firstly it still uses catgets so it has no way to handle program translations in an encoding-safe way, and secondly it hasn't had enough work done on all the stuff you need to do to handle different encodings of manual pages themselves
<cjwatson> I fixed all of that stuff in man-db years ago, so it's more than reached the point where distros might as well just switch if they're having problems
 * cjwatson wonders if Gentoo will ever get around to actually doing that, having apparently decided to do so
<abhinav-> :)
<abhinav-> the only point I can mention in my proposal for not using man-db is that it is under gpl :)
<cjwatson> yes, I believe in free software actually staying that way. :)
<abhinav-> that actually gives me the opportunity to get this project :-D .
<click170> I'm maintaining the TicGit-ng program, a fork of the original now unmaintained TicGit, but I've run into a problem. Both the deprecated TicGit gem and the TicGit-ng gem use the same bin file(s), so when installing the latter without the former, you get told that you need to install TicGit in order to use that bin file
<click170> How do I resolve the problem on Ubuntu where trying to call a bin file with TicGit-ng installed results in a notice telling you to install the TicGit gem?
<lifeless> sounds like your script isn't installed properly
<lifeless> and you are triggering command-not-found behaviour
<click170> Well, if I install the TicGit-ng gem on Debian, it works without problems. Do I need to do something more to satisfy a requisite for Ubuntu?
<click170> Am I in the wrong channel? Should I be in the rubygems channel instead?
<lifeless> I don't know :)
<lifeless> what does 'which <your command name>' report
<click170> 'which ticgitweb' has no results, but the file exists in '/var/lib/gems/1.8/bin/ticgitweb'.  This is a fresh install with git-core ruby and rubygems installed, and then TicGit-ng installed via gems.
<lifeless> so, is /var/lib/gems/1.8/bin on your path?
<click170> Apparently not. Sounds like a bug in Rubygems...
<click170> lifeless: Thanks.  I've gone to answers.launchpad.net to ask for more information there and to find out if this is a bug in rubygems or not.
<seiflotfy> any1 here using natty on an intel chipset
<seiflotfy> core i5
<seiflotfy> i cant  use my external monitor
<seiflotfy> it keeps flickering
<c2tarun> seiflotfy: what is your laptops model?
<bradm> I'm having huge problems with my laptop due to bug 727620, its random if it'll boot or not
<ubottu> Launchpad bug 727620 in xserver-xorg-driver-ati "[Radeon HD 5650 and 5470] Driver crash during recovery boot and in normal boot (Regression from 2.6.38-3 to -4)" [High,Confirmed] https://launchpad.net/bugs/727620
<pitti> chrisccoulson: binutils> awesome, as it's in the archive now, do you think we can land this by tomorrow freeze?
<chrisccoulson> pitti - yeah, can do. i've got some other globalmenu-extension bug fixes to land with firefox too though (most are fix committed already, but there is one which i haven't finished investigating yet)
<chrisccoulson> i want to be sure i've not introduced any crashers before i upload though (so i'm running it today)
<chrisccoulson> when is the cut-off tomorrow?
<pitti> chrisccoulson: we freeze at 0900 UTC
<chrisccoulson> pitti - oh, i guess i'll have to get it all fixed tonight ;)
<pitti> chrisccoulson: Sundays are overrated :)
<chrisccoulson> heh :)
<chrisccoulson> jo works on sunday`s, which means i have my daughter here to help me
<pitti> chrisccoulson: but in exchange you can slack tomorrow
<chrisccoulson> and she likes using my laptop ;)
<chrisccoulson> she has figured out that when she bashes the keypad, things happen on the screen
<chrisccoulson> **keyboard
<pitti> now this just needs a tad of coordination :)
<chrisccoulson> lol
<chrisccoulson> she's even tried drawing her own image in the screen with a felt tipped pen
<chrisccoulson> i'm not sure she has figured out yet how things are normally rendered on to the screen ;)
<pitti> chrisccoulson: oh, do you get that off the screen again?
<chrisccoulson> pitti - she hasn't actually got as far as drawing on the screen yet. i stop her before she manages to do it
<chrisccoulson> but she's got pretty close!
<chrisccoulson> she's already drawn on the sofa ;)
<chrisccoulson> but the cats do more damage to our sofa than her anyway ;)
<Laney> anyone available to process the gio-sharp sync? want to rebuild banshee against it before the freeze
<pitti> Laney: just doing
<pitti> I did all outstanding syncs
<Laney> cheers pitti
<ricotz> pitti, hi
<ricotz> docky needs to be built when gio-sharp is ready
<pitti> ricotz: doesn't it have a versioned build-dep?
<ricotz> docky copies the unstable lib to its private directory
<ricotz> gio-sharp is considered unstable
<pitti> then we'll need a -build1 upload, sorry
<ricotz> ok
<ricotz> no worries
<Laney> i should have s/accepted/published/ in my comment
<Laney> sorry
<ricotz> pitti, but of course thank you for accepting it
<lifeless> doko: hi
<micahg> should I add tasks for the rdepends to bug 745544
<ubottu> Launchpad bug 745544 in gcc-4.3 (Ubuntu) "removal of GCC-4.3 packages in natty" [Undecided,Incomplete] https://launchpad.net/bugs/745544
<ScottK> micahg: Sounds reasonable.
<SpamapS> hrm.. twice now my box has panicced because building drizzle ate up all the RAM...
<lifeless> SpamapS: what -j param are you passing?
<lifeless> SpamapS: and -panic- wtf
<SpamapS> lifeless: I know.. I'm getting an "OOM and no processes left to kill"
<ScottK> I've hear lamont is particularly fond of -j 24 on armel.
<SpamapS> lifeless: I'm not sure what -j it passes..
<ScottK> hear/heard
<SpamapS> I'm pretty much at "defaults"
<lifeless> SpamapS: package or upstream build
<SpamapS> lifeless: package
<lifeless> whats your deb concurrency option set to
<SpamapS> lifeless: I've never done anything to change it, so probably 1
 * SpamapS is almost religious about using defaults unless he fully understands the setting being changed. :-P
<SpamapS> plus w/ a dual core honestly using -j2 just means sacrificing being able to use the box. :-P
<lifeless> SpamapS: heh
<lifeless> SpamapS: my test build box is a (2 year old) i7
<lifeless> SpamapS: 8 cores 4eva
<SpamapS> I have one box
<SpamapS> a laptop
<SpamapS> everything else is "in the cloud" :)
<SpamapS> Ok so I think this is related to the chroot upstart support
<SpamapS> its happening when installing dbus
<lifeless> -win-
<lifeless> SpamapS: how old is your laptop that its only 2 core?
<SpamapS> macbook pro 15 5,1
<SpamapS>     1 root      20   0  962m 941m 1336 R  100 23.9   0:18.53 init
<SpamapS> DOOHHH!!!
<SpamapS> oh boy and its unstoppable
<SpamapS>     1 root      20   0  962m 941m 1336 R  100 23.9   0:18.53 init
<SpamapS> oops
<SpamapS> 2.5G now
<SpamapS> sync
<SpamapS> haha my 'sync' came out in irc
<SpamapS> box was a bit unresponsive by then.. :-P
<SpamapS> ahh.. so dbus is special in that it sends SIGUSR1 to init...
<DnaX> I've requested a FeatureFreeze Exception for Gweled package: bug #756877
<ubottu> Launchpad bug 756877 in gweled (Ubuntu) "Debian sync request for Gweled 0.9.1" [Undecided,New] https://launchpad.net/bugs/756877
<DnaX> can anyone in the release team look this?
<stgraber> cjwatson: sorry for the late response ;) I can confirm a race condition in plymouth-upstart-bridge. Out of 5 boots in my VM I only got one boot.log containing the upstart boot messages.
<stgraber> it's testing with a desktop VM on my laptop, so it takes less than 5 seconds to boot the whole desktop. I'm guessing it's less visible on a "normal" system :)
<stgraber> I'll see if I can "easily" fix that so I can then easily test bug 752393
<ubottu> Launchpad bug 752393 in lsb (Ubuntu) "lsb init scripts show line buffering problems on bootup" [Medium,Confirmed] https://launchpad.net/bugs/752393
<stgraber> as I don't really want to reboot 5 times everytime I want to test something ;)
<stgraber> I could also find a slower machine (as in, non-SSD and with less than 8GB of RAM), that should workaround it ;)
<cjwatson> stgraber: could just be that dbus starts so shortly before gdm that there's no time for p-u-b to do anything
<cjwatson> it's possible for both gdm and p-u-b to start immediately after dbus, after all
<cjwatson> p-u-b is more useful on server systems
<cjwatson> but you could also just shove 'pre-start exec sleep 10' in /etc/init/gdm.conf, or something like that
<stgraber> cjwatson: well, my choice of using ubuntu desktop was to make the boot process slower ;) which kind of worked but only 1 out of 5 times ... server was booting even faster so that I'd never get a boot.log containing upstart entries :(
<stgraber> I'm not sure the sleep 10 would work because on Friday I tried removing plymouth-stop.conf entirely, which means keeping a running plymouth after boot. But still didn't get anything in boot.log. I'm guessing the issue is really that p-u-b is starting "too late" and everything is already done
<cjwatson> stgraber: roll on http://alban.apinc.org/blog/2011/02/16/introducing-multicast-unix-sockets/ or similar, and then we'd be able to talk to upstart without needing to wait for dbus-daemon to start
<stgraber> that'd be nice indeed
#ubuntu-devel 2012-04-02
<infinity> Laney: You around?
<infinity> Laney: Do you know, off-hand, if revving fpc from 2.4.x to 2.6 will require any sort of revdep rebuild transition?
<infinity> Laney: I'm seriously considering the version bump to get the armhf port included.
<infinity> Laney: And you're my resident "guy who keeps track of weird languages and compilers". :P
<vibhav> good morning
<broder> is there an AA around i could get to binNEW the mosh backports?
<pitti> Good morning
<rickspencer3> good morning pitti
<rickspencer3> no unstable job, no archive problems?
<rickspencer3> nice
<pitti> hey rickspencer3
<pitti> I don't intend to introduce any :)
<rickspencer3> pitti, does that mean you are using precise -proposed for everything now?
<pitti> rickspencer3: not for everything, too much overhead; but we can use it for all the bits which are prone to introduce problems
<rickspencer3> awesome
<micahg> pitti: oh, -proposed is available again?
<pitti> micahg: bug 930217 :)
<ubottu> Launchpad bug 930217 in Launchpad itself "Make proposed pocket useful for staging uploads" [Low,Fix released] https://launchpad.net/bugs/930217
<micahg> ooh, great
<pitti> it got set to "fix released" over the weekend
<pitti> so apparetnly rolled out now
<RAOF> We're not thinking of rolling a full unstableâtesting like promotion system, I take it?
<pitti> rickspencer3: need to ask jibel to restart the upgrade tests; they haven't run for 4 days now, and we have two major fixes rolled out now
<pitti> RAOF: eventually, but we don't have that yet
<pitti> RAOF: just with immediate migration, not with 10 days of waiting or so
<rickspencer3> thanks pitti
<RAOF> That sounds like a fairly large amount of work.
<pitti> RAOF: we currently move stuff to precise from -proposed as soon as it built everywhere and doesn't introduce  uninstallability
<pitti> RAOF: it's nontrivial, but not huge really -- britney in Debian does that all the time, and we use it to produce http://people.canonical.com/~ubuntu-archive/testing/precise-proposed_probs.html, etc.
<RAOF> Having a staging area will be awesome.
<pikkachu> not sure if this is the right channel but I've noted really wrong translations in oneiric (not as opposed to other versions)
<pikkachu> rosetta is nice but it can't do the entire job
<pikkachu> gettext is not so good and we often need to refer to the source code for translating stuff correctly
<pikkachu> filenames in LP's po files are not big help...
<pikkachu> what effort is being done to fix this situation?
<pikkachu> because untranslated strings seem much better than absolutely wrong translations
<dholbach> good morning
<janimo`> pitti, thumbs up for the systemd investigation!
<geser> "Sometimes I have the impression that Martin Pitt is doing everything in Ubuntu." (https://plus.google.com/115547683951727699051/posts/MuB3MkCnieK)
<ajmitch> that's not too far off the truth
<tumbleweed> except the bit about hte last bastion crumbling
<pitti> jibel: do you know why the jenkins upgrade jobs haven't run for four days?
<pitti> so http://www.ubuntu.com/ still has the goggles
<pitti> so is it real after all!?!
<hrw> hi
<hrw> does someone uses apt-cacher-ng?
<pitti> well, I guess it's still April 1 on some distant islands in the pacific
<jibel> pitti, they are running, but results are not published. I think that's the follow up of the maintenance of last week but I don't have access to the public jenkins
<Laney> infinity: no idea I'm afraid (even I'm not crazy enough to touch pascal :P). I suggest asking the Debian maintainer
<geser> hrw: yes, I use it for my pbuilder and my packaging chroot
<hrw> geser: I use a-c-ng on precise machines and 'W: Failed to fetch bzip2:/var/lib/apt/lists/partial/de.archive.ubuntu.com_ubuntu_dists_precise_universe_binary-i386_Packages  Hash Sum mismatch' started to be daily norm ;(
<tumbleweed> hrw: I've seen that with some upstream mirrors. Deleting dists from the cache and restarting it helps :/
<hrw> tumbleweed: will try other mirror then cause removal+restart did not help
<Laney> is the file actually correct on the mirror?
<Laney> forcing a check has always fixed it for me
<Laney> but the fact that it happens at all (every 2-3 weeks here) is annoying, granted
<geser> hrw: I use archive.u.c to no to have to wait on the mirror pulse and updated yesterday my precise box without problems
<hrw> ok, changed from de to pl mirror and it works
<hrw> 516MB update is fetching ow
<pitti> jibel: ah, thanks; so I'll just wait for that to come back online before I bother you again
<henrix> pitti: hi! i was checking the kernel pkgs status, and there are a few still to be copied into -proposed
<pitti> jibel: I'm just curious to see whether the LibO and at-spi stuff have worked :)
<henrix> pitti: is there any problem with them, or they're just on the queue?
<pitti> henrix: just on the queue; I don't look at them every day, and I seem to be the only one who does..
<henrix> pitti: ah, ok :)
 * pitti does now
<henrix> pitti: great, thanks
<Riddell> @pilot in
* udevbot changed the topic of #ubuntu-devel to: 12.04 Beta 2 Released! Precise: UI and feature freeze | Dev' of Ubuntu (not support or app devel) | build failures -> http://bit.ly/xmGdCW | #ubuntu for support and general discussion for hardy -> oneiric | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: Riddell
<pitti> Riddell: happy flying
<Riddell> whee
<vibhav> Who are patch pilots?
<pitti> henrix: there will be some packages again which will land in main instead of universe; I'll clean up after them once your bot complains
<pitti> henrix: i. e. that's a normal part of the workflow for lucid (unfortunately..)
<Riddell> vibhav: hi
<henrix> pitti: ok, no prob. do you receive the bot notifications? or do you want me to ping you back?
<pitti> henrix: I do get the notifications
<vibhav> hi Riddell
<henrix> pitti: ok, cool.
<henrix> pitti: thanks
<jibel> pitti, lucid universe failed http://paste.ubuntu.com/911209/
<jibel> pitti, lucid server, desktop and main pass
<pitti> jibel: does oneiric pass again, with the LibO fix?
<jibel> pitti, oneiric desktop failed with bug 969707
<ubottu> Launchpad bug 969707 in libreoffice (Ubuntu Precise) "package python-uno 1:3.4.4-0ubuntu1 failed to install/upgrade: sub-processo novo script pre-installation retornou estado de saÃ­da de erro 1" [Critical,Confirmed] https://launchpad.net/bugs/969707
<pitti> argh, that
<pitti> jibel: ok, I just discussed that with Sweetshark
<jibel> same for oneiric main
<jibel> and same for universe
<pitti> jibel: erk, seems the at-spi fix didn't work; thanks for the log
<pitti> ah, python-pyatspi has a versioned dependency on at-spi, so Provides: isn't enough
<pitti> TheMuso: ^ FYI
<jamespage> larsduesing, around?
<pitti> jibel: reopened bug 966845
<ubottu> Launchpad bug 966845 in pyatspi (Ubuntu Precise) "lucid->precise upgrade wants to remove ubuntu-desktop" [High,Triaged] https://launchpad.net/bugs/966845
<TheMuso> dholbach: Who is patch piloting on Wednesday April 11? I need to arrange a swap as I am on holiday the week after.
<seb128> TheMuso, the calendar is public, https://www.google.com/calendar/embed?src=6k1e5rq45m1bdqq0n1ge3oqaok@group.calendar.google.com&ctz=Europe/Berlin&gsessionid=OK
<dholbach> TheMuso, you can just move the shift to another day if you like
<henrix> pitti: sorry for bothering again, but i still can't see the new packages on -proposed. is that normal to take that long?
<pitti> henrix: indeed, it's a bit weird -- the SRU page did not yet update either
<pitti> it normally takes half an hour
<henrix> pitti: yeah, that's what i though. any ideas about what's going on?
<pitti> henrix: not off-hand, need to check
<henrix> pitti: thanks
<cjwatson> We missed a couple of publisher runs, possibly due to LP maintenance.
<cjwatson> 2012-04-02 08:57:33 DEBUG   Removing lock file: /var/lock/launchpad-publisher.lock
<cjwatson> 2012-04-02 10:33:04 DEBUG   Cronscript control file not found at file:cronscripts.ini
<cjwatson> But it's running now.
<larsduesing> pitti - may I ask you a really dumb question?
<bdrung> smoser: i rewrote distro-info in C. it is way faster than shell.
<pitti> larsduesing: at lunch, just ask :)
<larsduesing> pitti: sorry.. problem was on my side, cleared seconds ago
<larsduesing> :)
<janimo`> bdrung, pitti dholbach do you know off the tops of your heads a 3.0 (quilt)/dh package that does per-architecture application of a patch?
<AnAnt> janimo`: if you find out, please tell me
<AnAnt> janimo`: just wondering, what's your package ?
<janimo`> AnAnt, mongodb
<henrix> pitti: the bot just complained about wrong component :)
<bdrung> janimo`: sorry, i can't remember one that uses per-arch or per-distro patches
<maxsv23> Ã¥Ã±Ã²Ã¼ ÃªÃ²Ã® Ã¯Ã® Ã°Ã³Ã±Ã±ÃªÃ¨
<Riddell> pitti: can you tell debfx how your qt 4.8.1 tests went?
<dholbach> janimo`, no, unfortunately not
<janimo`> dholbach, bdrung thanks anyway
<pitti> janimo`: no, I don't know one off-hand, I'm afraid
<bdrung> janimo`: in many cases it is useful to have a patch that supports all architectures. per-arch patches are unlikely to get accepted by upstreams.
<janimo`> bdrung, I know, but sometimes for too invasive patches which upstream does not take in this form it still make sense to have a fix for arm or other targets
<pitti> Riddell, debfx: I haven't done exhaustive testing, but unity-2d starts just fine with qt 4.8.1, and basic functionality (indicators, launcher, dash, hud) is working fine
<cjwatson> surely #ifdef isn't too hard
<janimo`> cjwatson, doable in most cases
<janimo`> I could not do it  last time I needed this (in ghc)
<janimo`> most arm patches of course use ifdefs but for the few exceptions I was curious if per-arch is possible
<dross> is there a channel where I can ask ubuntu wiki questions about posting a "FreeNX is dead, here's a list of alternatives" on the FreeNX page?
<dross> I don't want to piss people off :3 but FreeNX has been inactive since 08'
<debfx> pitti: thanks for testing
<AnAnt> bdrung: swt-gtk is an example of an upstream that provides two source tarballs, one for 32-bit arch, another for 64-bit arch
<AnAnt> btw, I have sync'ed/merged TeXLive pre-2012 package from Debian for Precise on my PPA: ppa:aelmahmoudy/tl2009 , please note that a couple of packages (cm-super & texlive-base) were sync'ed rather than merged, probably I would merge texlive-base on next Debian upload.
<smoser> bdrung, really? wow. cool.
<bdrung> smoser: ubuntu-distro-info passes all test. i am cleaning up the code and then work on debian-distro-info
<smoser> i woudl guess you could do a run in 20% of the sh.
<bdrung> smoser: 25x times faster without startup time and 3.8x times faster with startup time.
<smoser> what is "without startup time" ?
<bdrung> smoser: a for loop in C calling main multiple times
<bdrung> i guess that fork takes too long
<smoser> yeah. fork is heavy.
<smoser> by guess of 5x was based on the fact that /bin/true is 6x faster than the shell version
<smoser> :)
<bdrung> smoser: 1000x times u-d-t in C: 0.037s (without fork) and 0.4 s (with fork)
<bdrung> smoser: the fork takes longer that running u-d-i
<smoser> bdrung, right. thats the case for loads of utilities.
<smoser> fork is very heavy
<smoser> although extremely performant on linux compared to other unixes
<smoser> the 'date' fork in the shell version accounts for 30% of its execution time.
<smoser> anyone know of a way to get a list of supported locales ?
<smoser> er... i guess more explicitly i'm looking for a list of all 'language-pack-XX'
<bdrung> smoser: the binary is 3x bigger
<smoser> bdrung, i'm perfectly fine with you replacing shell with c.  I wont have my feelings hurt if you replace it.  I suspect that in any real world usage, the current version is not likely to bottleneck anything.  (unlikely that tab completion is going to be affected by a reduction in run time from 1/100th of a second to 1/1000th)
<bdrung> smoser: i don't wanted to make your work wasted, but i had some free time and was curious about the possible speed improvement.
<smoser> pitti, i suspect maybe you know about a list of supported language packs ^
<smoser> bdrung, yeah. i get itches like that too :)
<cjwatson> directhex: were you intending to backport https://github.com/mono/mono-tools/commit/59e0b16bff03d0df812d62a6ac71ce373d6d5cc4 to the package in precise, or do you want me to do it?
<smoser> bdrung, really, i'm perfectly ok if you want to use the C version. i would suggest not bothering for 12.04 though.
<cjwatson> directhex: (failed in the test rebuild)
<pitti> smoser: apt-cache search language-pack | grep ^language-pack ?
<bdrung> smoser: you could sell the shell version as learning experience. ;) distro-info was written in python, haskell, shell, and C with interesting results.
<directhex> cjwatson, curse automake upstream with the fire of 10,000 suns (i believe grub was also hit by this idiocy)
<smoser> pitti, yeah, ubt i wondered if there was a cleaner way. i shouldhave said that: apt-cache search ^language-pack-[a-z][a-z]$ | sed 's, .*,,; s,language-pack-,,'
<directhex> cjwatson, i think the sid package has that backported change
<cjwatson> directhex: I fixed it in grub2 a little while back, yes
<smoser> i just wondered if there was some list that i could definitively reference.
<directhex> cjwatson, sync from sid should be all you need. http://packages.debian.org/changelogs/pool/main/m/mono-tools/mono-tools_2.10-2/changelog
<cjwatson> directhex: ah yes, good point.  will sync
<cjwatson> looked for bug reports but not uploads, duh
<directhex> cjohnston, if you hit more 1.11.2 issues in mono packages, fix likely contains a fix
<directhex> er, cjwatson
<cjwatson> directhex: sure, thanks
<directhex> *sid* contains a fix. can't type today
<directhex> computers are hard
<Laney> mmm fix
<cjwatson> smoser: if this is for a seed, why not just use germinate's globbing capability?
<smoser> cjwatson, not for a seed.
<smoser> cjwatson, for https://code.launchpad.net/~utlemming/cloud-init/cloud-init.locale/+merge/100257
<cjwatson> can't you use python-apt?
<cjwatson> >>> import apt
<cjwatson> >>> cache = apt.Cache()
<cjwatson> >>> len([pkg for pkg in cache if pkg.name.startswith('language-pack-')])
<cjwatson> 826
<cjwatson> obv. something a bit more sophisticated :)
<diwic> bkerensa, you pinged me the other day. I'm around now, but not for that much longer today.
<utlemming> cjwatson, smoser: I'm missing the back drop here, but I assume the issue is the list of valid locales?
<smoser> cjwatson, yeah, that might be preferable.
<smoser> utlemming, well, i was just not interested in hard coding if i didn't have to.
<utlemming> smoser: fair enough...I put the list of locales for two reasons 1) simplisitity and; 2) since another merge proposal which used a dynamic discover method was nixed
<utlemming> smoser: I'm not opposed to a dynamic discovery method and would actually like to have that bit of code dynamic. But in looking at it, you have to us a regex because you have kde and gnome language packs.
<smoser> utlemming, well, use python-apt. but i'm not beng on that. i added some comments there.
<alexbligh> I'm seeing a fantastically weird problem on a Lucid install in a particular virtualised environment where eth0 and eth0:1 (same interface) both have static IPs in /etc/network/interfaces, eth0 is numbered immediately on boot, but eth0:1 takes **OVER TWO MINUTES** to get its IP address. Any idea where in upstart or whatever I should even start looking to find what's causing this?
<bdrung> smoser: oldstable breaks my algorithm
<stgraber> alexbligh: (that's just from memory, things may be slightly different in 10.04) I suspect that eth0 being a physical interface it gets setup as soon as we get the kernel udev event (so very early)
<stgraber> alexbligh: but eth0:0 being a label on eth0, it only gets configured when we hit the fallback /etc/init/networking.conf, so once we start calling the sysvinit stuff
<stgraber> alexbligh: which means that if you have any upstart job/ifupdown script/... that takes a long time to start, it'll delay the setup of eth0:0
<alexbligh> stgraber, it's an ordering problem. We have stuff which should run after the interfaces have been configured (which is what is causing us the problem). Specifically, rc2.d seems to be being run before all the interfaces are configured.
<alexbligh> stgraber, that appears to be because rc-sysinit.conf is "start on filesystem and net-device-up IFACE=lo"
<stgraber> alexbligh: yeah, we fixed that in 11.10
<stgraber> alexbligh: /etc/init/rc-sysinit.conf:start on (filesystem and static-network-up) or failsafe-boot
<alexbligh> stgraber, oh really?
<micahg> janimo`: I think firefox is doing per arch patches at the moment
<stgraber> alexbligh: and static-network-up is emitted once all static entries in /etc/network/interfaces have been configured
<alexbligh> stgraber, is that safe to backport to Lucid?
<stgraber> alexbligh: so you shouldn't have that problem with 11.10 or 12.04 (though I'm not too sure about our behaviour with labels, would have to check)
<alexbligh> stgraber, i.e. is it just the one line change in rc-sysinit.conf or do I have to emit the event too?
<stgraber> alexbligh: no, it's unfortunately not safe to backport to Lucid and that's why we didn't
<alexbligh> stgraber, unfortunately we are stuck with Lucid for the time being (until precise is out).
<janimo`> micahg, thanks. I was hoping a 'sane' package can be used as an example, I don't think firefox uses 3.0 and dh
<janimo`> but then again, 'sane' packages do not need per-arch patches :)
<alexbligh> stgraber, is a safe hack to put an interface up script for eth0 which does 'ifup eth0:1'?
<stgraber> alexbligh: you'd have to backport a few upstart jobs, some ifupdown hooks and maybe even some udev hooks, I spent a few days considering doing that when working on other issues (bonding and bridging mostly) but the risk of regression was considered too high
<stgraber> alexbligh: "up ifup eth0:1 || true" would be better. It's an hack but should be safe, yes
<alexbligh> Or actually I can take them up from the thing running from sysvinit, can't I (doh).
<alexbligh> stgraber, thanks, that's really helpful.
<stgraber> alexbligh: you're welcome. Would be great if you could test your setup with 12.04 beta2 (in a VM or something) to make sure your issue was indeed taken care of
<stgraber> alexbligh: if it didn't then file a bug against "ifupdown" so we can take a look before 12.04 is released
<alexbligh> stgraber, we need to do precise testing at some point. Annoyingly our next version release date is just before precise, so we are stuck with Lucid + Oneiric backport kernel :-/
<pitti> sconklin: hey Steve
<sconklin> Hi pitti
<pitti> sconklin: did you notice that I had a question for you on bug 955111 ?
<ubottu> Launchpad bug 955111 in apport (Ubuntu) "Apport including error messages in tags" [Low,Incomplete] https://launchpad.net/bugs/955111
<sconklin> no, thank you. I'l plowing through email still
<sconklin> looking
<leex> hi, I just read about capsicum and was wondering whether capsicum support will come to ubuntu, if it is on your todo/wishlist.
<sconklin> pitti, well, this is interesting, look at what I got - I mistyped lsb-release the first time http://pastebin.ubuntu.com/911614/
<pitti> sconklin: can you check whether this goes to stdout or stderr?
<sconklin> I get is if I type anything into the shell
<sconklin> stand by
<pitti> yes, anything that calls python
<pitti> it's an error message that python itself prints
<pitti> and I suspect it's going to stdout
<pitti> sconklin: the first one was from command-not-found, FYI
<sconklin> pitti: stderr
<pitti> sconklin: i. e. you don't see them with lsb_release -si 2>/dev/null ?
<cjwatson> you'll probably just need to upgrade those local libraries
<sconklin> I do not see them with stdout directed to null. I do see them in a file I piped from stderr. Two test cases, same result
<sconklin> cjwatson: I have an app with a fixed version edpendency, that's why I installed those locally
<cjwatson> not a good idea to have them in place for all applications though ...?
<sconklin> agreed
<sconklin> I should shell up an env for the app
<pitti> sconklin: hm, I checked both calls to lsb_release, and in both it just grabs stdout; very weird
<pitti> sconklin: anyway, I'll try to reproduce this by adding some gibberish to lsb_release
<sconklin> pitti: but remember it happens for anything I pass to the shell, it doesn't even have to be lsb_release
<pitti> sconklin: thanks for checking
<pitti> sconklin: ah, found it; it's in our ubuntu package hook only, that's why I didn't find it in trunk
<sconklin> pitti, cjwatson: and I just pulled the LD_LIBRARY_PATH change out of my bashrc and put it in a script that invokes the app. That removed the error.
<pitti> and fixed in bzr
<pitti> with that, good night everyone!
<sconklin> Thanks!
<apw> ia32-libs ia32-libs-multiarch:i386 <-- is this something i am expecting to be REMOVED
<Sweetshark> pitti: so the issue is, the extension is still assumed to be register, so we kill it and reinstall the extension. _rene_ then says unopkg then thinks the extension is already there so it noops. which is why he wants to run sync_extensions before installing to make unopkg notice it has to reregister.
<mpt> ev, you've fixed bug 737791
<ubottu> Launchpad bug 737791 in apport (Ubuntu) "need to be able to "Report Bug, then Reopen"" [Undecided,New] https://launchpad.net/bugs/737791
<ev> nice
<ev> closing
<cyphermox> hallyn: re libnl3; did you make any progress?
<cyphermox> hallyn:  I have an updated patch, though it doesn't include the changes to generated files (http://people.ubuntu.com/~mathieu-tl/libnl3-updated.patch). Adding the other changes should be as easy as doing a diff of configure and src/Makefile.in, daemon/Makefile.in  after configure
<hallyn> cyphermox: no, i'm afraid there are plenty of higher prio bugs first :(  Note that waht upstream wants to see is a patch that allows the choice of libnl-1 or libnl-3.  Then they'd be willing to take it.  how hard would that be to do?
<hallyn> cyphermox: so the patch above should fix the -I path to include /usr/include/libnl3?
<cyphermox> hallyn: yes, if there aren't other instances where a netlink/msg.h file is needed and doesn't have LIBNL_CFLAGS
<hallyn> cyphermox: thanks
<cyphermox> hallyn: fixing it to choose the version is pretty simple, yes, just needs a bit more code since there are some different calls between NL1 and NL3
<hallyn> cyphermox: i assume the configure.ac bit will be the ugliest :)  I do intend to give it a try arounds uds time.  if no kind soul beats me to it :)
<cyphermox> what's the purpose for the update, just preparing for precise+1?
<cyphermox> otherwise we can sit together at some point at UDS around a beer and I'll be happy explain the details
<hallyn> cyphermox: right, well, just to get the patch upstream so we don't have to carry delta and worry about regressions.  sitting down at uds sounds great  :)
<cyphermox> cool
<Bluefoxicy> What's with all the non-deterministic status indicators?
<Bluefoxicy> Back when Ubuntu started, it would blurt all kinds of boot indicators to the screen
<Bluefoxicy> Removing all that was a mistake, but I was assured quite firmly that this was inconsequential because, "unlike Windows," the status indicator for boot was a deterministic progress meter.
<Bluefoxicy> Now there's no such thing, the download progress meters for i.e. Update Manager are non-deterministic things that bounce back and forth, and everything leaves me wondering how fast and how far
<Bluefoxicy> Is Ubuntu hanging on boot?  It seems to be taking longer today... maybe I'm just bored, I dunno.
<Bluefoxicy> Is my ISP being slow, or is this just the normal 2 minute download?
<Bluefoxicy> etc
<Bluefoxicy> You may as well not give any indication that anything's going on at all:  if the application hangs, the status bar will gleefully bounce back and forth while nothing happens
<Riddell> @pilot out
* udevbot changed the topic of #ubuntu-devel to: 12.04 Beta 2 Released! Precise: UI and feature freeze | Dev' of Ubuntu (not support or app devel) | build failures -> http://bit.ly/xmGdCW | #ubuntu for support and general discussion for hardy -> oneiric | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<smoser> mvo, i'd really appreciate you  looking at https://bugs.launchpad.net/ubuntu/+source/squid-deb-proxy/+bug/971820
<ubottu> Launchpad bug 971820 in squid-deb-proxy (Ubuntu) "squid-deb-proxy needs special handling of Release, Packages, Source" [Undecided,New]
<mvo> smoser: sure!
<smoser> mvo, do you understand the problem there?
<mvo> yes
<smoser> the issue is that those files get cached and cached stale, and there is nothing that you can do (from the other side of the mirror) to resolve it.
<smoser> s/mirror/proxy/
<mvo> smoser:  http://bazaar.launchpad.net/~racb/squid-deb-proxy/apt_refresh/revision/16 <- that is pretty much what you need, right?
<smoser> yeah, i think so. i'm of course going to defer to your better knowledge of apt
<smoser> mvo, i swear there is a setting tha tyou can tell squid...
<smoser> to check the headers every time
<smoser> (and maybe this is it)
<smoser> but rather than downloading the whole thing every time, check the headers.
<jcastro> mvo: while you're in there and want to sort https://bugs.launchpad.net/ubuntu/+source/squid-deb-proxy/+bug/952364 that would be great too. :)
<ubottu> Launchpad bug 952364 in squid-deb-proxy (Ubuntu) "Default to not caching a deb instead of 403'ing." [Undecided,New]
<mvo> smoser: for squid question, I always ask lifeless :) he knows all about it
<smoser> exactly.
<mvo> jcastro: right, that would be a great feature too, I don't know if squid can be configured to do that, but I can dig around a bit
<smoser> mvo, if you just deny, i think that files dont get cached.
<smoser> its weird.
<smoser> orchestra used to deny the packages.gz and such.
<smoser> they still came through
<rbasak> smoser: yes, that's exactly what my squid.conf lines do in http://bazaar.launchpad.net/~racb/squid-deb-proxy/apt_refresh/revision/16 - they will only download the files if they're newer, otherwise will use the cache. But they will check every time.
<smoser> rbasak, thank you.
<smoser> mvo, jcastro fwiw, orchestra used to do this:
<smoser>  http://paste.ubuntu.com/911976/
<smoser> and iiuic that basically does what castro wanted.
<smoser> of course, you stil spend bandwidth as a proxy for those things that you weren't going to cache.
<jcastro> right, but it beats having the thing being totally unreachable, like it is now\
<rbasak> I'm not aware of a single situation where using squid with http://bazaar.launchpad.net/~racb/squid-deb-proxy/apt_refresh/revision/16 can fail when going direct will work.
<mvo> smoser, rbasak: its uploaded now with the changes in rev16, thanks!
<rbasak> thanks mvo!
<smoser> gracias.
<mvo> jcastro: so the only reason unrestricted access is not enabled by default currently is to allow this to be dropped into a already restricted network without opening up generic http access via this squid-deb-proxy, I guess it could be argued that this is something that a admin should restirct himself/herself and that convinence is better. or we add another debconf question, but that is not very discoverable either :/
<jcastro> I think not having an unrestricted proxy is reasonable; ideally the proxy saying "fine, go download from this random repository, I will neither help you nor hinder you" sounds like a good middle ground to me
<rbasak> jcastro: the security issue isn't whether it caches your deb or not (pretty minor, just a DoS of the cache), but whether you can get the deb or not (pretty major - could subvert an existing security policy controlling general access). I favour a debconf option.
<mvo> jcastro: right, my thinking (but bear in mind that I'm not a sysadmin :) was that the proxy host has usually different network restrictions than the regular clients, so opening up the proxy sounds potentially dangerous to me
<jcastro> mvo: we should just ask elmo what to do. :) Or perhaps grab a -security guy at UDS or something, whatever works for me.
<mvo> jcastro: yeah, someone more experienced than me on this and I will happly implement whatever they suggest, for now I'm totally fine with a debconf prompt
<mvo> jcastro: note that I want this to be as simple as possible really
<rbasak> If we want full access through the proxy, why not just use the main squid package?
<stgraber> pitti: ping (TB -> #ubuntu-meeting)
<stgraber> kees: ^
<kees> ah!
<seb128> slangasek, hey
<slangasek> seb128: hey there
<seb128> slangasek, how responsive is freetype upstream to issues they would create for i.e gtk? ;-)
<slangasek> seb128: they should be responsive... but there's no test suite to catch regressions, so you can expect any fix for an issue you're seeing to be bundled with another regression or two somewhere else :P
<seb128> slangasek, underlining is broken in some cases in gtk (reported by mvo today), I tracked it down to freetype
<slangasek> is this with the 2.4.8+security fixes?
<seb128> slangasek, i.e ld preloading the oneiric version fixes it up, .9 doesn't fix it
<slangasek> ok
<seb128> slangasek, it's between oneiric 2.4.2 and precise
<slangasek> upstream git should be reasonably bisectable, I guess
<seb128> slangasek, there is quite some commit between those versions, would have been nice to not skip 6 versions :p
<seb128> slangasek, anyway I will try to figure when it started and come back ;-)
<slangasek> 4,6,7 were all uploaded to Debian, I don't recall if they made it into precise
<seb128> slangasek, ok, found the commit, it's http://git.savannah.gnu.org/cgit/freetype/freetype2.git/commit/?id=b0962ac34e66052ccfee7996e5468f30d4bd5a72
<slangasek> hmm
<slangasek> ok, that's the second regression I've seen from that committer in the past year
<seb128> slangasek, not sure how to process next, it could be that freetype is right and that something else needs fixing :-(
<slangasek> s/committer/author/
<slangasek> yes, that's always the concern :/
<seb128> slangasek, but applying that patch to 2.4.5 creates the bug, or reverting it in newer version fixes the bug
<seb128> slangasek, the testcase from mvo is https://bugs.launchpad.net/ubuntu/+source/software-center/+bug/955030/+attachment/2988350/+files/lala.py
<ubottu> Launchpad bug 955030 in software-center (Ubuntu) ""Show N technical items" doesnt look clickable" [High,Triaged]
<slangasek> seb128: ah, no, that's the *same* commit that was earlier reported as a regression: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=636776
<ubottu> Debian bug 636776 in libfreetype6 "libfreetype6: Line height squeezed in GNU Emacs" [Normal,Open]
<slangasek> in fact, that's the exact commit why oneiric stuck with 2.4.4
<seb128> slangasek, that breaks the underlining in that gtk example
 * slangasek nods
<seb128> slangasek, can we revert that commit in precise? ;-)
<slangasek> seb128: sure - you want to do it, or do you want me to?
<slangasek> seb128: can you also take that test case to upstream?  freetype-devel@nongnu.org
<seb128> slangasek, it's time to bed for me but I can do it tomorrow if you want
<slangasek> that'd be fine
<seb128> slangasek, ok, I can do that as well tomorrow
<seb128> slangasek, ok, I will do the commit revert and email the upstream list tomorrow, thanks!
<slangasek> seb128: thanks for tracking this down... maybe we can talk upstream into implementing a proper test suite :P
<seb128> let's see, I would be happy enough if they come with an upstream fix for the regression to start ;-)
<stgraber> cjwatson: can you approve my e-mail to ubuntu-devel-announce?
<cjwatson> stgraber: done
<stgraber> cjwatson: thanks
<bdrung> smoser: http://anonscm.debian.org/gitweb/?p=collab-maint/distro-info.git;a=commitdiff;h=c4f8e5dc44b6dec640c3222becc9d11d21a84078
<bdrung> smoser: i moved your shell scripts into the script/ subdirectory.
<bryceh> slangasek, would you mind perusing bug #971767?  I'm wondering if it might be due to something lower down than X, but I'm not sure where to look.
<ubottu> Launchpad bug 971767 in xorg-server (Ubuntu) "Xorg crashed with SIGSEGV in __GI___libc_malloc()" [High,Triaged] https://launchpad.net/bugs/971767
<slangasek> sure, lookin'
<bryceh> slangasek, we're seeing a spate of vaguely similar-ish bugs against xserver, that seem to involve weird memory corruption, double-free'd pointers, and so on, but for ones we have good traces the code where the crash occurs looks fine.  But makes me thing something just is not right in the stack.
<bryceh> (e.g. bug 943880 which seems relatively common)
<ubottu> Launchpad bug 943880 in xorg-server (Ubuntu) "Xorg crashed with SIGABRT in __libc_message() from XIDestroyDeviceProperty" [High,Confirmed] https://launchpad.net/bugs/943880
<slangasek> bryceh: well, you have a binary blob video driver that has access to the stack, right?  That would be my first guess...
<slangasek> bryceh: will X run under valgrind?
<bryceh> slangasek, it will
<bryceh> slangasek, in fact cnd was just doing that for debugging the latter bug
 * slangasek nods
<slangasek> so it's exceedingly unlikely that malloc itself is broken here
 * cnd hopes so
<slangasek> I think you have heap corruption, and valgrind's the best tool for finding that
<bryceh> slangasek, ok, thanks
<YokoZar> I should have guessed ScottK would be the curmudgeon to reject my beautiful package ;)
<bryceh> slangasek, ok, so it's not an obvious bug you already know of in say libc
<slangasek> nope
<cnd> slangasek, due to a miscommunication in our team, the latest utouch-frame was uploaded this past friday with a switch to dh 9 and multiarch
<cnd> should we revert the change, or let it slide, or?
<infinity> How many rdeps does it have, and have they all been tested?
<infinity> cnd: ^
<slangasek> cnd: ^^ what infinity asked
<slangasek> we need to follow through to make sure the revdeps don't regress
<cnd> utouch-grail, utouch-geis, unity, libgrip, evince, eog
<slangasek> I actually don't see the last four as deps
<cnd> unity still works, that takes care of grail and geis
<slangasek> utouch-grail, utouch-geis, mtview
<slangasek> those are what we have to care about from a build perspective
<cnd> slangasek, is it just building that we are worried about?
<cnd> or runtime too?
<infinity> If everything still works, both at buildtime and runtime, reverting would be gratuitously perverse.  But please do make sure.
<slangasek> for multiarch, it's just a build issue
<infinity> (But yeah, for C libs, runtime should always Just Work)
<cnd> ok, well we'll watch the precise archive rebuilds
<infinity> Unless you've done something horribly hackishly wrong.
<cnd> and fix up anything that breaks
<cnd> but I would expect things to just work
<slangasek> cnd: the archive rebuild already started before Friday - please do your own rebuild tests of these packages
<cnd> oh, ok
<cnd> will do
<cjwatson> just feed 'em all through sbuild
<cjwatson> or I can do that here if you don't have it set up
<cnd> cjwatson, I was going to use bzr bd --builder=pdebuild for most
<cnd> pdebuild for mtview, which isn't in bzr
<cjwatson> well, sbuild mimics the official builders most accurately, but as you like
<cnd> cjwatson, I assume that's good enough?
<cjwatson> if you're using pbuilder, though, I'd recommend asking it to build the .dsc files actually in the archive
<cnd> ok
<infinity> We really need to see about making upgrading pbuilder to just be a tiny translation shim on top of sbuild.
<infinity> s/making //
<infinity> If we had a One True Way to build packages, I might almost become convinced to revisit making lp-buildd use the distro sbuild a bit sooner.
<cjwatson> cnd: utouch-grail, utouch-geis, and mtview all build in current precise, with utouch-frame 2.2.3-0ubuntu1.  Do you want the logs?
<cnd> cjwatson, thanks :)
<cnd> don't need the logs
<cnd> slangasek, infinity: looks like we're ok
<cnd> sorry for the trouble :(
<cjwatson> that's from .dsc not from bzr
<cnd> yeah
<infinity> cnd: Alright.  Good enough for me.  Though, don't take this as a "better to ask forgiveness than permission" thing. :P
<cnd> infinity, yeah, this was a combo of miscommunication and bad assumptions
<cjwatson> infinity: Do you know if nihal's a sad panda?  https://launchpad.net/ubuntu/+archive/test-rebuild-20120328/+build/3331721 and a slew of other
<cjwatson> s
<cjwatson> I've given some of them back but left some for debugging
<infinity> cjwatson: Damnit.  This has happened before, on more than one machine.  I'm now wondering if there's a moon-phase-related bzip bug on ARM...
<infinity> cjwatson: (Basically, it's whining that the already unzipped tar.bz2 is not a valid tar...)
<infinity> cjwatson: The quick fix is to get a LOSA to rm -f ~buildd/filecache-default/*
<cjwatson> yeah, it's familiar, I had webops monkeyfix it a couple of times myself too
<infinity> cjwatson: But it probably needs looking into. :/
<penguin42> infinity: Would it not be good to capture the bad uncompressed file to see what's up with it?
<cjwatson> does it do any checksum validation on the network transfer?
<infinity> penguin42: That may also be valuable, yes.
<infinity> cjwatson: Sure, but the corruption is post-transfer, I think.
<cjwatson> OK, I didn't know
<infinity> cjwatson: unpack-chroot unzips, then re-enters and untars.  The unzipped version is kept in the cache for subsequent runs.
<cjwatson> incidentally that caching behaviour could use improvement ...
<infinity> cjwatson: The corruption, from a distance, appears to be between unzip and untar (ie: bzip2 doing something naughty)
<infinity> cjwatson: Oh, the caching and unpacking both are a mess.  I blame Kinnison.
<cjwatson> anyway, I need to crash, if somebody else wants to track down a webops, be my guest :)
<infinity> cjwatson: But I probably can't blame THIS bug on Kinnison. :P
<hloeung> you called?
<cjwatson> main build failures on the test rebuild down to 23, counting the stuff already uploaded that I know about but that the index hasn't picked up yet
<cjwatson> from 40-something earlier today
#ubuntu-devel 2012-04-03
<infinity> hloeung: Apparently, nihal needs filecache-default scrubbed.
<infinity> hloeung: However...
<infinity> hloeung: Before you do that, a copy of it might be nie.
<infinity> nice, too.
<hloeung> infinity: just filecache-default? or the build-*'s as well?
<infinity> hloeung: Are there more than one build-*?
<hloeung> infinity: yes, there's 3 actually
<infinity> Oh.
<infinity> Fun.
<infinity> hloeung: In that case, yeah.  Stop lp-buildd, clear out the whole mess.  But I'd like a backup of filecache-default, if you could?
<hloeung> infinity: yep, taring up filecache-default
<infinity> hloeung: On lillypilly or chinstrap, or somewhere I can get to it readily.
 * infinity wonders if anyone in the Bay Area wants to bring him a power cord for his laptop, since he stupidly forgot his at home.
<infinity> Don't all speak up at once.
<smoser> is there a reason that language-pack-en-base Recommends firefox-locale-en ?
<smoser> its really only an annoyance, but installing a language pack on a server then pulls in firefox packages
<smoser> (well, not really firefox packages, but firefox-locale-xx)
<infinity> You could install with --no-install-recommends
<JanC> you mean you didn't configure that as the default?  ;)
<infinity> But the relationships for langpacks have always been a bit sketchy, because it's hard to adequately represent what we want to happen there.
<cjwatson> Partly it's because IIRC that used to be in language-pack-en but was split out.
<infinity> Mozilla locales have always been separate.  Unless you meant the dependency used to be elsewhere.
<infinity> At least, I think they always have been...
<infinity> But really, no amount of Enhances or Recommends magic can make it DTRT for all people.
<cjwatson> I may just be misremembering.
<infinity> The per-package mini langpack spec would solve the issue, but I so think it would cause more problems than it solves. :P
<smoser> cjwatson, you pointed at python-apt earlier, do you know if i can use it to tell me if a package is installed without having cache available ?
<cjwatson> You generally need to instantiate a cache to find out much of anything.  Why don't you want to?
<infinity> You could just use dpkg...
<infinity> (or dpkg-query)
<cjwatson> dpkg's own interfaces for this are actually kind of crappy, so I understand preferring to ask apt.
<infinity> Forking dpkg is going to still be less painful than spinning up an apt cache, if you didn't need the latter.
<cjwatson> $ time python -c 'import apt; cache = apt.Cache()'
<cjwatson> real    0m0.900s
<infinity> Though it would be nice for libapt/python-apt to be able to give dpkg status info with no cache built...
<cjwatson> $ time dpkg-query -W man-db
<cjwatson> man-db  2.6.1-1
<cjwatson> real    0m1.882s
<cjwatson> I'd use apt if I were you :-P
<infinity> cjwatson: I'm unconvinced that benchmark is linearly true on slower hardware.
<cjwatson> Possibly, but dpkg has never been very quick to parse its own status file.
<infinity> No, true.
<infinity> apt takes nearly a minute to rebuild a cache here, though.
<infinity> (assuming a fresh invalidation, ie: apt-get update)
<infinity> Oh, actually, most of that is probably unzipping lists.  So, I guess it depends on smoser's definition of "no cache".
<smoser> "no cache" really meant no /var/lib/apt/lists
<cjwatson> I suppose you could use python-debian to parse /var/lib/dpkg/status if you were desperate
<smoser> and i'd really hope to be able to query "is a package installed" in less than a second.
<infinity> smoser: Well, nothing there at all?  In that case, building a cache as per cjwatson's code above would just build one with dpkg/status.
<cjwatson> Or python-apt might have a way to do that too which might be faster, I forget
<smoser> infinity, right. thats what i'm seeing.
<cjwatson> smoser: Do you need to query more than one?
<smoser> in this caase i'm only after if a package is installed. dont eed to query more than once.
<cjwatson> Then none of the options will be significantly faster as far as I can think of.
<cjwatson> If you're prepared to hardcode things about the packages you could check for a file they're known to ship.
<infinity> Ew?
<cjwatson> Or possibly check for the existence of /var/lib/dpkg/info/$pkg.list.  But if you do that you need to be very clear on how/whether multiarch will affect you; that's an implementation detail.
<cjwatson> I mean, .list files are an implementation detail.
<infinity> Surely, higher level abstractions of dpkg/status are the sane way to go...
<cjwatson> Yes.  As I say, I'd use python-apt.
<smoser> so.. the general idea here is this (feel free to tell me any portion of this is wrong)
<cjwatson> Because normally it's already done the work of parsing the status file into a more quickly loadable cache format, that being a lot of the point of the cache.
<smoser>  * bug https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/859814 shows the issue we're trying to address (and links to other bugs there too)
<ubottu> Launchpad bug 859814 in cloud-init (Ubuntu) "Locale issues with beta-1/2 cloud-images" [Medium,In progress]
<smoser>  * cloud-images have not in the past had a language pack installed, resulting in stderr output when someone ssh's in with other than en_US.UTF-8
<smoser>  * cloud-init has long had this support for setting a default host locale, and only now have we found that that didn't really  make sense without installing language-pack-XX
<smoser>  * so we're looking to install language-pack-en in the default images, and if the user asks cloud-init for "configure my default locale to french" we'll want to install language-pack-fr
<cjwatson> If you're trying to test whether a given locale is installed, the right way to do it is:
<cjwatson> import locale
<smoser> i want to ask "do i have language-pack-fr" installed before doing an apt-get update and 'apt-get install language-pack-fr'
<infinity> smoser: Now, this is a slightly different direction, but do these VMs typically actually need a langpack installed?  Cause if it's just about annoying error messages from shell/perl/etc, you could localegen the world. :P
<cjwatson> try:
<smoser> infinity, you can't just use localegen.
<cjwatson>     locale.setlocale(locale.LC_ALL, '')  # or a specific locale as the second argument if you don't want to take it from the environment
<smoser> unfortunately. :)
<cjwatson> except locale.Error:
<cjwatson>     # take steps to install the locale
<smoser> https://bugs.launchpad.net/ubuntu/+source/postgresql-9.1/+bug/969462
<ubottu> Launchpad bug 969462 in postgresql-9.1 (Ubuntu) "fails to start after install if invalid locale is set" [Undecided,New]
<infinity> smoser: Since when?  I do it all the time.  Doesn't buy you translations (obviously), bet gets you a valid locale.
<cjwatson> so you could easily touch the apt cache only in the locale.Error slow path there
<smoser> well, ok. maybe you can do that i guess.
<cjwatson> infinity is correct too
<smoser> hm..
<infinity> cjwatson: And, of course, your code is tripped up by people like me, since it's testing for a locale as a key to installing a langpack, the two are only loosely related.
<cjwatson> generating locales manually is explicitly supported
<smoser> so it is OK to localgen even if i dont have the language-pack-xx installed ?
<cjwatson> sure
<infinity> Of course.
<cjwatson> there're special arrangements to remember which ones you've locale-gen'ed manually vs. via language packs
<cjwatson> the manual ones will end up in /var/lib/locales/supported.d/local
<infinity> smoser: Of course, if you really do want translations as well as valid locales, you need to go the langpack route.
<smoser> infinity, yeah. so i think i'll go the quick 'imporet locale' route to test, and if thats not there, then install the package.
<GrueMaster> soren: ping - need some assistance with preseeding.  I have the same preseed for 3 different systems, and I am getting two different errors in partman.
<smoser> allowing for the case when i've been trick'ed by you, infinity
<infinity> smoser: And I really see no reason that can't just be a shell 2-liner of dpkg-query && apt-get install.
<smoser> s/allowing/ignoring/
<GrueMaster> Or anyone else that wants to jump into my preseed nightmare.
<infinity> smoser: My trickery is fine.  If I'm generating locales by hand, it's because I don't want the langpack, so that seems a sane thing.
<smoser> infinity, yeah, the reason i'm concerned is this happens on first boot.
<cjwatson> infinity: or even just apt-get install --no-upgrade
<smoser> and its generallyhappening serially.
<cjwatson> but, indeed, I don't really see what installing the package is going to buy you, from your description.
<cjwatson> it's strictly more than you actually want.
<GrueMaster> http://paste.ubuntu.com/912292/ for anyone that wants to look.
<smoser> so i dont really want to postpone boot by .5 seconds or more.
<cjwatson> and language-pack-en take significantly longer, since it will generally have to generate rather more locales.
<cjwatson> *will take
<smoser> right
<cjwatson> even discounting having to download and unpack it and its -base pair.
<infinity> Yeah, the localgen in langpack-en is painful.
<smoser> so maybe doing localgen is enough.
<infinity> I just had a perverse idea.
<infinity> pam module that checks the starting ENV and forks localegen for uninstalled locales.
<infinity> Please pretend I didn't just say that.
<infinity> Thanks.
<smoser> yeah. i sort of looked there.
<infinity> (It's quite easily doable...)
<smoser> what we have now is a profile.d message that informs the user how to make the environment usable if they do want their locale
<infinity> And would once and for all end the "I sshed from my desktop to my server, and Perl whines at me, HALP" bugs.
<smoser> well, thtas sort of what i was addressing here.
<cjwatson> GrueMaster: suggestion for you in bug 971608, assuming that this is the same thing.
<ubottu> Launchpad bug 971608 in partman-auto-lvm (Ubuntu) "Unable to create blank lvm volume in preseed install" [Undecided,New] https://launchpad.net/bugs/971608
<infinity> It's not really any uglier than pam_userdir and other such one-time violence.
<smoser> but i thikn i'm good enough at this point to just locale-gen, and inform the user on how to fix the issue.
<infinity> In fact, less so, because it doesn't need to keep track of priv bouncing, it would just be a pre-session root deal.
<infinity> Anyhow, not suggesting this as the solution for your bug in the next few weeks before release.
<infinity> But now the gears are turning in my mind. :P
<GrueMaster> cjwatson: Yes, I have that in my current preseed for both panda and armada systems.  Pandas are now complaining about not mounting /boot, armada is complaining about blank lvm.
<GrueMaster> Preseeds are identical.
<smoser> the "locale_warn" branch is at https://code.launchpad.net/~utlemming/cloud-init/cloud-init.profile.d/+merge/100262
<cjwatson> GrueMaster: I need the precise text of the complaints in order to help
<cjwatson> paraphrasing means I can't grep for it
<smoser> infinity, just in case you care. and it might be updated with what i learned here. thank you cjwatson and infinity
<GrueMaster> panda:  The attempt to mount a file system with type ext3 in SCSI1 (0,0,0), partition
<GrueMaster> #1 (sda) at /boot failed.
<GrueMaster> Armada:  No file system is specified for partition #1 of LVM VG eilt0, LV Test1.
<cjwatson> I don't see method_only in http://paste.ubuntu.com/912292/ or in your bug report from earlier, by the way.
<infinity> GrueMaster: Not ext4?
<GrueMaster> I added the method_only after filing that bug report (found it at noon PST).
<GrueMaster> infinity: Which?  /boot?  u-boot doesn't understand ext4.
<cjwatson> GrueMaster: And the message you quote for Armada will be silenced by preseeding partman-basicmethods/method_only.  Please check again that you really preseeded it.
<cjwatson> The u-boot case might want to be something like  method{ format } use_filesystem{ } filesystem{ uboot }  instead.
<cjwatson> Oh, except partman-uboot is still dove-only, unless ogra fixed that ...
<cjwatson> So maybe not.  That's unrelated to the blank partition problem, anyway, I think
 * cjwatson -> really crash
<GrueMaster> partman-uboot was dove only.
<smoser> ok..
<smoser> i'm doing an automated install.
<smoser> i watch the installer get up and do some downloading of the installer packages.
<smoser> and i'm seeding this to use a squid-deb-proxy
<smoser> heres a snippet of my squid proxy logs
<smoser>  http://paste.ubuntu.com/912304/
<smoser> why is the installer doing 10 requests for Pakcages.gz ?
<GrueMaster> groan.  To add to my issues, it would appear that my most recent preseed was clobbered due to stale vi swap.  Fortunately, I have a copy on another system.  retrying.
<smoser> and then it dies complaining about it being corrupt
<smoser> but i'm validating it manually locally, and it has identical checksum as reported by Release
<infinity> hloeung: Did you restart lp-buildd on nihal when you were done tidying?
<smoser> earlier today we thought this issue was https://bugs.launchpad.net/ubuntu/+source/squid-deb-proxy/+bug/971820 , but that change has been applied locally
<ubottu> Launchpad bug 971820 in squid-deb-proxy (Ubuntu) "squid-deb-proxy needs special handling of Release, Packages, Source" [Undecided,In progress]
<hloeung> infinity: I've stopped it now. Am going through cleaning up build-* and the filecache-default
<hloeung> and will start it back up when done
<infinity> hloeung: Ahh, okay.  I was just being impatient then, nevermind. ;)
<GrueMaster> Well, this is...different.  cjwatson:  New pastebin.  http://paste.ubuntu.com/912305/
<hloeung> infinity: heh sorry, I'm also uploading a copy of the filecache which doesn't help. Each command is taking quite some time to send over
<Shinobi> What is the local port for mount.cifs?
<infinity> hloeung: No rush, I'm about to head out for food anyway, and one dead Panda won't kill the rebuild.
<infinity> hloeung: Just poke me on IRC when it's all done, and I'll look at things when I get back.
<GrueMaster> Now I still get the same failures as above, but on different systems.  2 pandas and armada fail to mount /boot, 1 panda now fails with "!! ERROR: No root file system
<GrueMaster> "
<hloeung> filecache-default.tar.bz2                      31%  137MB  94.2KB/s   53:55 ETA
<hloeung> infinity: ^
<hloeung> so it'll probably be done when you return...
<infinity> hloeung: Err, are you bouncing it from your home connection?
<hloeung> infinity: yep
<infinity> hloeung: You could have just put it in ~buildd/public_html/ and grabbed it from another host in the DC. :P
<hloeung> errr...   why didn't you tell me that earlier? ;-)
<infinity> Well, not from just any host, but some have firewall rules to allow it (nusakan, lillypilly, etc)
<infinity> And lillypilly would be a fine choice.
<hloeung> infinity: ah, I'll remember that for next time.
<hloeung> anyways, launchpad-buildd bounced on nihal
<infinity> Danke.
<infinity> Design Capacity: 22 Wh, Energy when Full: 27 Wh.
<infinity> This is one heck of a battery.
<micahg> infinity: any chance of helping me to get https://launchpad.net/~ubuntu-security-proposed/+archive/ppa/+build/3377300 going on roseapple?
<infinity> micahg: You expect it to magically not fail there?
<micahg> infinity: hoping :)
<micahg> infinity: I got it to build locally in a 32 bit chroot
<infinity> Yeah, the 64-bit kernel might "fix" it.
<infinity> But, uhm.  That's not really fixing it.  Just sayin. ;)
<micahg> infinity: yeah, there's something weird going on in that build, <= natty takes a lot of memory/space, oneiric+ takes very little (relatively)
<micahg> infinity: I'd rather just get it built now and figure that out later
<infinity> Already on it.
<infinity> It's ridiculous how long that PNG optimising stuff takes.
<infinity> pitti: ^-- Is it really that hard, or is the code just that bad?
<micahg> infinity: also, would you mind copying chromium-browser lucid, maverick, and oneiric from ubuntu-security-proposed to -proposed
<infinity> micahg: Can you ask me to do that after I've eaten? ;)
<infinity> micahg: (the build is on roseapple, though)
<micahg> infinity: thanks, sure, I'm heading out for a bit, will ping when I return
<infinity> Kay.
 * infinity goes to wander the streets of SF aimlessly until he smells something good.
<psusi> bug #919281 appears to be the result of some kind of error spinning the server cd and leaving out kernel modules.  What's the correct package that should be assigned to?
<ubottu> Launchpad bug 919281 in Ubuntu "Ubuntu installation image Fake RAID" [Undecided,Confirmed] https://launchpad.net/bugs/919281
<smoser> lifeless, around ?
<lifeless> smoser: hi, sure.
<smoser> https://bugs.launchpad.net/ubuntu/+source/squid-deb-proxy/+bug/971820
<ubottu> Launchpad bug 971820 in squid-deb-proxy (Ubuntu) "squid-deb-proxy needs special handling of Release, Packages, Source" [Undecided,In progress]
<smoser> i'm desparate
<smoser> i'im hoping that you could tell me some magic "the right way" to run a squid proxy for apt.
<smoser> i had an issue earlier today, we opened that bug, and hoped it had been addressed, but with the suggested lines:
<smoser> refresh_pattern \/(Packages|Sources)(|\.bz2|\.gz)$ 0 0% 0
<smoser> refresh_pattern \/Release(|\.gpg)$ 0 0% 0
<lifeless> you can at best work around things; apt archives are not HTTP safe.
<smoser> I've still got a squid proxy that has cached a bad version of http://archive.ubuntu.com/ubuntu/dists/precise/main/binary-i386/Packages.gz
<smoser> well, i'm very interestedin your input on the best possible configuration.
<lifeless> the thing is that the constant-named files have no safe cache semantics should of must-revalidate
<lifeless> s/should/short/
<smoser> well, honestly, i'd greatly prefer horrendous waste of network badwidth to the pain of a bad cache'd value.
<lifeless> blacklist Releases/Sources/Packages then
<lifeless> sorry, I don't have a good canned answer for you
<lifeless> caching debs is fine, anything that we replace the content on has a race window *if* any other file is coordinated with it
<hloeung> infinity: chinstrap:~hloeung/filecache-default.tar.bz2
<lifeless> at scale, any size race is exploitable
<smoser> lifeless, as in 'cache deny PACKAGES'
<lifeless> yah
<lifeless> IIRC you can force must-revalidate as well, which would be a little more efficient
<smoser> "force must-revalidate" would be doc'd here http://www.squid-cache.org/Doc/config/refresh_pattern/ ?
<lifeless> *note* though that you will *still* hit these races: our mirror update scripts reduce the window down to subsecond, *but* different mirrors update up to 15 minutes apart, or more.
<lifeless> smoser: IIRC last we looked at this we determined your squid was using multiple upstreams ?
<smoser> this one is not.
<smoser> we have had that issue in other cases.
<smoser> but this one has a pinned IP somewhere for me.
<lifeless> smoser: what version of squid are you using ?
<smoser> 3.1.19-1ubuntu1 (precise archive)
<lifeless> so - re the upstream bug
<lifeless> http://www.squid-cache.org/Doc/config/balance_on_multiple_ip/
<lifeless> I think the thing is that squid by default is much more sticky
<smoser> lifeless, fwiw, the mirror update scripts window is not subsecond.
<smoser> even in a single mirror, its well above that.
<lifeless> but that probably it only takes a single failure to trigger a rotate
<lifeless> might be worth adding that to the bug
<lifeless> smoser: really? How long does the critsection take?
<smoser> its bad.
<smoser> i dont have numbers in front of me, but we hit it way too often for it to be sub second.
<lifeless> smoser: and the mirrors are using the three-run rsync approach ?
<smoser> they're canonical run mirrors
<smoser> i dont really know.
<lifeless> hmm
<smoser> https://code.launchpad.net/~smoser/+junk/check-archive/
<lifeless> I can look into that
<smoser> that script, run it in a loop (on canonistack if you'd like)
<smoser> you'll hit single inconsistent mirrors way to often
<smoser> (and by "in a loop", i mean with a 1 or 2 minute sleep)
<lifeless> smoser: so the thing is, that either a) apt needs to send appropriate paranoid cache-busting headers, or b) apt needs to retry on inconsistent results (with appropriate headers) or c) we have to change the apt disk format.
<smoser> lifeless, yeah.
<lifeless> smoser: you're really at the edge of the fixes that can be done for dealing with live repositories
<smoser> i have a list of apt greivences against apt.
<lifeless> other mirroring scripts might be able to force it to subsecond, but even then, as discussed, at scale, it will be hit.
<smoser> and server team hopes to have some session on that at uds-q, and we would love to have your expertise there.
<smoser> i'd like to address it where it can be fixed for good.
<smoser> we want to tell people to install packages and provision things in an automated fashion.
<smoser> and when doing so, at least for the development release, the archive is the most likely cause of failure.
<lifeless> smoser: the root cause is to fix apt's disk format: it needs to depend on only a single file being updated atomically at a time, not two files.
<smoser> well, N files.
<lifeless> 1
<smoser> multiple Packages.gz and Source.gz have to be in sync with Release
<lifeless> at the moment, Packages.gz <- Release
<lifeless> and separately
<lifeless> Sources.gz <- Release
<lifeless> but this is a meaningless difference in model; the key thing is that to be safe in the absence of caching, the archive has to be fully readable at any given state, including when only one file of a group has been updated.
<smoser> right.
<lifeless> To be safe in the presence of caching the archive has to be fully readable with the old versions of a file at each url.
<lifeless> the way I would approacho it, if I were to work on it, would be to ditch Packages.gz and Sources.gz and the other similar fixed-name metadata files;
<lifeless> use hash or otherwise uniquely generated names for them and reference those from Release
<lifeless> and inline-sign Release [if its not already]
<lifeless> this would make mirror pushes atomic - write the new debs & source packages, new packages/sources/contents, new releases, and as each release is written it becomes visible.
<lifeless> until a client sees the new releases, it will happily read the old packages.gz and debs etc
<smoser> sign is separate now, but i'm told that in-line is done or soon to be done.
<lifeless> smoser: I'd be delighted to write up something somewhere, but I can't commit to implementing :)
<lifeless> we could publish both styles in parallel quite cheaply, and new clients would be more robust.
<smoser> above, how would you atomically handle Releases ?
<smoser> ie, that would still be a single path, right?
<infinity> You don't need to, you just make sure you mirror Releases last.
<infinity> (In lifeless's scenario)
<infinity> The old Release file will remain valid for the old hashed Packages files, you get new hashes on disk, mirror new Release, maintain consistency.
<infinity> It's elegant enough.  Probably not wildly difficult to implement.  Does make archives less human-navigable, though.
<infinity> Perhaps a small price to pay.
<infinity> (And fixable by making Packages.gz a symlink to the most recent hash, for people who prefer the fixed names for non-apt uses)
<smoser> yeah.
<infinity> lifeless: Can you write this up as an apt bug?  I suspect mvo and I would both be interested in looking into it further.
<infinity> lifeless: Doing it on the LP side is borderline trivial (or possibly even "for free", with an apt-ftparchive upgrade), but the apt side will take some thought.
<lifeless> sure
<psusi> slangasek, why is plymouth not in the initramfs normally?  I could have sworn it was supposed to be.. that would eliminate the gui vs text console early boot failure problem woudln't it?
<slangasek> psusi: it's not in the initramfs normally because it slows down the boot when it is, since you can't get out of the initramfs then until the video driver has loaded
<slangasek> (so the system waits, making no use of either cpu nor disk, while the video card is initialized)
 * slangasek trades a negation for a vowel
<slangasek> psusi: I am increasingly thinking that we should just stick it in the initramfs and try to make up the boot speed impact elsewhere, but it's a bit late to be pondering this for 12.04 :/
<psusi> hrm... so it did used to be there?  and to speed boot, it was removed because loading the video driver was wasting too much time?
<psusi> video driver is kind of required for text mode console as well isn't it? ;)
<Sarvatt> psusi: it was only there for a short short time in the 10.04 dev cycle
<Sarvatt> maybe you had the cryptsetup packaged installed previously or something
<psusi> how long does it take to init the video card anyhow?  and doesn't it have to do that anyhow when you don't pass the quiet splash boot options?
<slangasek> which is certainly possible, as it gets installed in support of encrypted swap if you choose the encrypted homedir option in the installer
<slangasek> psusi: depends on the video card and driver and and; but it may be as much as a couple of seconds
<slangasek> (in various common cases)
<psusi> wow!
<slangasek> yes, you have to init the video card anyway, but when you *don't* have to do it in the initramfs, you're not stuck *waiting* for it
<RAOF> You need to do all sorts of output probing, running BIOS scripts, etc.
<psusi> RAOF, just to load the dri driver and not even switch video modes?
<RAOF> Yes, because loading the dri driver generally implies switching video modes.
<slangasek> :)
<psusi> not any more... we have gfxpayload=keep
<slangasek> heh
<RAOF> The dri driver doesn't know that it's not going to switch video modes or bring up new outputs until it's probed all the outputs.
<psusi> so... the video driver is still in the initramfs and loaded, just doesn't block switching to the real root?  or you're saying it isn't even loaded until after the root is mounted?
<slangasek> yeah; gfxpayload=keep just means the framebuffer is passed to the kernel, it doesn't mean the drm driver is smart enough to *use* it
<slangasek> no, the video driver isn't included in the initramfs at all
<slangasek> unless you've asked for it to be
<psusi> umm... then how is initramfs rescue recovery ever possible at all?
<psusi> ohh, it's only possible when the kernel comes up still in VGA text mode?
<psusi> that's no good at all...
<psusi> this might tie into something else I was thinking of the last time I worked on ureadahead... why doesn't it start in the initramfs... if you're doing readahead while loading the video driver that should fix the slow down problem without breaking initramfs recovery
<slangasek> psusi: yes, precisely - and if you're booting in rescue mode, you *are* coming up in text mode, that's one of the differences between the main boot option and the fallback one
<psusi> slangasek, of course, on macs or whatnot that don't have vga text boot and require fbcon, then you're screwed?
<infinity> psusi: How do you propose we readahead before we have a rootfs to read ahead on?
<slangasek> psusi: what kind of macs are we talking here?
<slangasek> UEFI has its own framebuffer
<psusi> infinity, you obviously mount the root fs first, but you can start the readahead and video driver load in parallel, all before you actually run-init the real root fs
<slangasek> and we're supposed to be using that, but I have certainly seen bug reports about it not working
<slangasek> psusi: you can't start the readahead until you have the root filesystem mounted to find the ureadahead pack data
<infinity> psusi: If we've found the rootfs, we should be pivoting ASAP, there's no reason to stay in the initrd.
<psusi> infinity, if you're still waiting for the video to init, you can at least start the readahead...
<infinity> slangasek: To be fair, I'm not sure we can guarantee every device will have a usable text mode.  We're only saved on ARM by building every subarch individually and building in framebuffers, that can't last if we ever have a unified ARM kernel.
<psusi> if you do that, then delaying the pivot for a second or two doesn't matter since all you'd be doing after is waiting for the readahead anyhow
<slangasek> infinity: sure; we might prefer to special-case the initramfs video handling on different architectures then
<slangasek> anyway, as I said, I think we should bite the bullet and put the video in the initramfs - just not for 12.04
<slangasek> oh, also, aren't we getting rid of initramfs on arm, making this a moot point ;)
<infinity> slangasek: On some ARM machines, perhaps, I doubt we are on all.
<Sarvatt> it would be so freaking nice to have the splash up 1.5 seconds into the boot instead of 7 seconds when the desktop starts at 8 so you barely see it, but yeah cairo in the initrd, 20mb+ extra initrd size on proprietary drivers, etc..
<infinity> slangasek: And hey, if someone makes uBoot suck less, we won't really need to at all.
<psusi> Sarvatt, exactly..
<slangasek> psusi: so I think what I would prefer is to put the video drivers in the initramfs unconditionally, but *not* block the initramfs waiting for plymouth to start unless we know cryptsetup is in use
<psusi> I thought most of the proprietary driver bulk was the xorg user mode driver part, not the kernel module?
<infinity> slangasek: Though, really, any machine that doesn't NEED an initrd shouldn't have one.  uBoot isn't the only bootloader that sucks at loading things from disks.
<Sarvatt> the kernel module is like 10mb last i checked for nvidia
<psusi> what the crap?
<psusi> wow... I guess fglrx_updates.ko is 4.3M... wow...
<Sarvatt> 17M /var/lib/dkms/nvidia-current/295.33/build/nvidia.ko
<psusi> jesus... what the hell are they shoving in there?  it wasn't that long ago that debian netinst came on two 1.44 MB floppies and that was the whole linux kernel plus root fs
<slangasek> no, no... it was that long ago :)
 * psusi corrects himself... damn old misnomer... 1440K floppies, which is not 1.44 MB ;)
<psusi> slangasek, so wait... can you even flip it back to vga text mode without the driver loaded?
<slangasek> well, *I* haven't managed to yet
<psusi> I wouldn't think you could...
<slangasek> well
<slangasek> you should be able to do it as raw VGA
<slangasek> not using a kernel fb driver
<micahg> infinity: or slangasek: could one of you copy chromium-browser lucid-oneiric from ubuntu-security-proposed to *-proposed*
<slangasek> but I haven't found the right tool for it yet
<psusi> right, but you need something to modeset it back to vga mode don't you?
<infinity> micahg: If you ask really nicely.
<slangasek> psusi: maybe? :)
<infinity> micahg: (looking at it right now)
<micahg> infinity: please.....with visions of bunnies and kittens
<infinity> micahg: I assume we don't care about the oneiric build failures?
<micahg> infinity: not enough to block the rollout
<infinity> Alright.
<infinity> LP is grinding, but it'll be done "soon".
<infinity> micahg: Finally done.  Double-check after the next publisher that it's all sane?
<micahg> infinity: yep, thanks
<lifeless> smoser: infinity: https://bugs.launchpad.net/ubuntu/+source/apt/+bug/972077
<ubottu> Launchpad bug 972077 in apt (Ubuntu) "apt repository disk format has race conditions" [Undecided,New]
<smoser> thanks.
<infinity> lifeless: Danke.
<lifeless> infinity: I've elaborated a little, perhaps. Its likely we need to do some dance around mirror pushes to really hammer that down, but thats orthogonal - push mirrors are already pretty tightly synced, and the new format will self-correct as soon as they have all pushed (which the current one does not)
<lifeless> smoser: if you have a session on this @ UDS and you want me there - I'm attending remotely.
<lifeless> smoser: so feel free to put me in as mandator or whatever, but I can't make the first 2-3 hours of each day
<smoser> lifeless, do not pretend to be mortal by implying you have to sleep
<smoser> thanks for your help./
<infinity> I suspect mvo and I might want to take it upstream a bit, but a UDS session isn't out of the question.
<smoser> right. upstream is correct, but we can have a good plan in ubuntu.
 * infinity nods.
<lifeless> upstream honour patches :)
<lifeless> you can call the file Releases.lifeless if you want to give me cred :P
<smoser> lifeless, are you opposed to forwarding that to upstream ?
<infinity> Well, we already have InRelease (the inline signed version)
<infinity> LinRelease?  Lifeless's Inline Release? :P
<lifeless> smoser: I think its totally appropriate to be upstream
<smoser> right.
<infinity> (I'm sure we can do it in the existing InRelease withough adding a new file)
<lifeless> smoser: I think we need to resource doing it ourselves. Upstream doesn't move at our pace, nor have our cloud adoption, so won't be seeing it anywhere near as much.
<infinity> Given that old clients verify from Packages->Release (not the other way).
<smoser> lifeless, do you mind filing upstream?
<infinity> lifeless: Some of us *are* upstream.
<lifeless> infinity: (InRelease) - cool : I didn't want to make assumptions about all the clients out there
<infinity> But yeah, I think we could implement it in the current InRelease without breaking the world.
<lifeless> smoser: I think someone likely to be doing it should file it upstream.
<infinity> I'll talk to mvo about it a bit, and then we can file upstream.
<lifeless> smoser: I'm really just applying my HTTP + doing whacky shit databases with filesystems knowledge here :)
<smoser> lifeless, thats fine.
<infinity> Or just implement it as a fait accomplis.
<infinity> The more I think about it, the more it actually doesn't sound hard.
<smoser> its clearly a valid bug wether or not we're going to work on it.
<lifeless> smoser: it is, but also the symptoms are already reported upstream
<smoser> no, its not that hard. just different filenames.
<infinity> smoser: No, I mean the client implementation.
<infinity> smoser: It's not just new filenames. :P
<lifeless> theres what, a half dozen clients to update
<infinity> (Currently, Release serves no purpose but to sign Packages, we'll be turning it into an index)
<lifeless> apt, various apt proxies, apt-ftp and so forth.
<infinity> lifeless: Maintaining backward compat is cake, so I'm less concerned about clients following suit ASAP.
<lifeless> infinity: always an advantage
<lifeless> {I wish we did that for more of our transitions}
<smoser> infinity, well it largely is just new filenames. you just have to update the name versus path.
<smoser> the way i read lifeless bug is that Releases-lifeless has '<sum> Packages-$HASH.gz'
<smoser> or something
<infinity> smoser: Yes, but then we need to make apt care about that. :P
<infinity> smoser: Right now, apt downloads Packages, then checks Release for the sum.
<infinity> smoser: So, we're flipping that on its head.
<smoser> but i tihnk '<sum> old-school-filename fullpath/new-school/filename' would make sense.
<infinity> smoser: And using Release as the index of available Packages files.
<smoser> then you dont have to parse the filename out of some token, you're fed it explicitly
<infinity> Anyhow.  Implementation details.
<infinity> Just saying it's more than "new filenames".
<infinity> But not rocket surgery either.
<lifeless> hah, this is *all* implementation details :)
<smoser> well, my "just filenames" was implying that clients already read the releases, and get the path relative to that
<infinity> smoser: They don't.
<smoser> no? my client does
<smoser> :)
<smoser> what do they do?
<infinity> smoser: It finds Packages from Release?
<smoser> why wouldnt it?
<infinity> smoser: apt finds Packages on its own, then verifies it with Release.  Not so subtly very different.
<lifeless> heheh, I *knew* there would be clients out there doing that
<smoser> infinity, yeah,that makes sense.
<infinity> And yes, if clients are doing that backward, we need to rename InRelease for the new implementation, or they explode.
<smoser> for a mirror (my client is "check-mirror") it is easier to just get Releases and walk thorugh it.
<infinity> Though I'm not sure how much I care about !apt...
<infinity> Anyhow.  We'll discuss more later.  Lots more.
<infinity> And yeah, maybe do a UDS session, though I think this is more of a pair-programming "hammer on it til it works" thing, not something that needs a committee to argue about it for an hour.
<lifeless> infinity: right, not encouraging you to have a session, just noting that *if* you have one *and* you want me, those are the constraints involved
<infinity> lifeless: I think your bug (and the above discussion) probably outlines things well enough anyway.
<infinity> Pretty clear problem and pseudo-atomic solution.  Just need to sort out transition, and argue about things that don't matter.
<lifeless> yup
<lifeless> if you want more chatter of any sort, just ping me
<lifeless> otherwise I'll assume that Q will be perfect.
<infinity> Of course it will be.
<infinity> Every release is.
<infinity> And I won't hear another word on that topic.
<StevenK> infinity: Explain Edgy, then?
<StevenK> :-P
<infinity> StevenK: We don't talk about edgy.
 * micahg wonders if Maverick broke the LTS+1 streak
<StevenK> micahg: Intrepid wasn't that bad.
 * micahg wasn't around for edgy
<StevenK> Like infinity says, we don't talk about edgy.
<lifeless> forget edgy. Talk warty.
<lifeless> *warty*
<StevenK> I missed warty, my first release was breezy.
<infinity> lifeless: warty doesn't count.
<lifeless> infinity: sif
<infinity> And hoary was actually pretty good, given it was only the second try.
<StevenK> I liked breezy as a release. Ran it off a Live CD for two days.
<JontheEchidna> I started using Kubuntu intermittantly at feisty, more often in gutsy, and started contributing around the time hardy was released
 * ScottK started using a Dapper a bit before it's release and started contributing mid-cycle in Feisty.
<ScottK> Edgy wasn't so bad.
<StevenK> ScottK: Compare it to Dapper, though.
<ScottK> What?  You mean released on time?
<ScottK> I know what you mean though.
<ScottK> Edgy felt better after I'd been through Hardy, Intrepid, and Jaunty.
<StevenK> ScottK: It was the first LTS, I was willing to wait and see and not complain. And it was worth it, IMO.
<ScottK> Sure.  Makes sense.
<ScottK> I used Dapper pre-release and was happy with it.
<smoser> pitti, you're last-touched lp:~ubuntu-core-dev/ubuntu/precise/apport/ubuntu . i'd appreciate a review and merge of https://code.launchpad.net/~smoser/ubuntu/precise/apport/ec2-metadata-timeout/+merge/100552
<smoser> (but anyone who wants to can do it, i can, but just owuld  like the peer review, and havne't touched apport before).
<smoser> goot night.
<pitti> Good morning
<nigelb> Good Morning pitti :)
<pitti> infinity: we can parallelize the PNG optimizing stuff, that's on my TODO somewhere; each individual PNG does not actually take long (subseconds), just packages with tons of PNGs will take a while
<pitti> infinity: SVGs take a tad longer
<pitti> smoser: looks nice, thanks
<micahg> pitti: you mean it might be possible to build openclipart in a reasonable amount of time :)
<pitti> if that causes so much trouble, you can also build it with NO_PNG_PKG_MANGLE=1
<micahg> for the 2 or 3 times a year we build it, it's not that bad
<micahg> it just seems crazy for clip art :)
<dholbach> good morning
<pitti> jibel: our meeting is where? G+?
<pitti> jibel: oh, mumble
<cjwatson> GrueMaster: Nothing jumps out at me; I'd need to see syslog/partman to look for errors there.
<jibel> pitti, mumble but we can do it on g+ if you prefer
<cjwatson> lifeless: there's a bug for inline-signing Release, but implementing it before we've switched to a new signing key opens the ability to exploit old versions of apt
<lifeless> cjwatson: well, we don't want that :)
<lifeless> cjwatson: however, the main part of the discussion wasn't that, but getting to a less cache-incoherent layout
<cjwatson> sure; it's an important piece though
<hrw> hi
<cjwatson> bug 804252, FWIW
<ubottu> Launchpad bug 804252 in Launchpad itself "Please support InRelease files" [Low,Triaged] https://launchpad.net/bugs/804252
<hrw> lifeless: is subunit your project?
<lifeless> hrw: I'm its BD
<lifeless> hrw: and I founded it
<hrw> lifeless: sorry to bother but it ftfbs without python 2.6 ;(
<lifeless> works for me
<hrw> lifeless: http://people.ubuntuwire.org/~wgrant/rebuild-ftbfs-test/test-rebuild-20120328-precise.html lists it as broken on all 3 archs in precise.
<lifeless> bad testtools version
<lifeless> testtools had a release that broke subunit
<lifeless> the next release fixes it
<lifeless> nothing to do with python version
<hrw> thanks
<lifeless> jodh: btw, please include the OOPS id if you're reporting a failed page in launchpad
<lifeless> jodh: the oops id lets us tell whats going on without having to guess.
<lifeless> jodh: saying 'if you do x you will get a timeout' does not work because timeouts are often usercode specific, due to team memberships.
<lifeless> jodh: I've taken a guess in this case, but including the oops id in future will make it a lot easier; thanks.
<smb> cjwatson, I got the feeling a recent upgrade to grub2 may be causing problems when using block lists (I know there are deprecated but just so useful). bug 972250
<ubottu> Launchpad bug 972250 in grub2 (Ubuntu) ""This GPT partition label has no BIOS Boot Partition"" [Undecided,Confirmed] https://launchpad.net/bugs/972250
<cjwatson> smb: I had a Debian report of a problem as well
<cjwatson> I expect it's the 4K sector backport, sigh
<cjwatson> can you debug it?
<smb> cjwatson, I have an affected system sitting around. So I should be able to check things (not yet sure where exactly to look)
<smb> Great, since a bit ago and now, the error changed from the non-sector aligned data to "cannot read `/boot/grub/core.img' correctly"
<cjwatson> Otherwise it'll need to wait until I can set up a suitable VM and look for myself.
<smb> cjwatson, The fs /boot/grub is on is ext4 which has 4k sectors. Partition looks reporting 4k block size as well and 512 sector size
<cjwatson> I hope it's not actually dependent on having logical 4K sectors since I can't test that.
<smb> Never tried to change things, but blockdev has an option to modify the block size
<doko_> hmm, updating to the new grub:
<doko_> Setting up grub-pc (1.99-20ubuntu1) ...
<doko_> /usr/sbin/grub-setup: warn: Attempting to install GRUB to a partitionless disk or to a partition.  This is a BAD idea..
<doko_> /usr/sbin/grub-setup: warn: Embedding is not possible.  GRUB can only be installed in this setup by using blocklists.  However, blocklists are UNRELIABLE and their use is discouraged..
<doko_> /usr/sbin/grub-setup: error: non-sector-aligned data is found in the core file.
<doko_> cjwatson, ^^^
<smb> doko_, See bug I just talked to him about. :)
<doko_> ohh
<cjwatson> I'll look at it once I've finished with the thing I'm currently on
<smb> A bit weird is that blockdev --getbsz returns 4k but all the locical and physical block sizes values in sysfs/queue are 512...
<cjwatson> Hopefully this is a red herring.
<cjwatson> It might just plain be broken with blocklists.
<smb> cjwatson, I could offer an strace of the run, but for some reason my error has changed now. :(
<cjwatson> Don't bother; I'm not convinced that would be terribly helpful.  I'll see if I can reproduce it first.
 * cjwatson curses blocklists.
<smb> cjwatson, Ok, got it back (it was not helpful to have had a peek with debugfs while being mounted). At least that way I could make a note of the message I get on boot: "error: out of partition" (press any key to continue). But it does come up
<cjwatson> Some systems will still work as they might just be using the old core image, but there was an ABI change in the disk structure so I expect it will depend on the complexity of the partitioning of /boot.
<cjwatson> Anyway that isn't too interesting.
<cjwatson> Best to debug the first error.
<smb> OK, unfortunately have to run now, but in case you need someone doing something on an affected system, let me know
<pitti> jibel: so, turns out that the upower autopkgtest actually discovered a crash in upowerd :)
<cjwatson> jibel: it was a lot quicker for me to use autopkgtest's schroot runner, which did reproduce an xvfb-related failure in ubiquity; hopefully it's the same one
<cjwatson> (admittedly I had to fix a bug in the schroot runner first ...)
<Daviey> Okay.. I've been handed a machine that when i create files, they get permission d-w---x--- root:root .. but the same action on a supposedly equal machine are created with drwxr-xr-x .. umask is normal, both are ext4 with no special mount flags.  Indeas?
<cjwatson> pitti: to save you debugging the same thing: Xvfb currently breaks if TMPDIR is set
<cjwatson> or rather if it's set to something which isn't on the same mount as /var/lib/xkb
<pitti> cjwatson: ah, thanks; I would have hit that in jockey
<pitti> cjwatson: I copy and run the tests to $TMPDIR as otherwise python uses the local ones from teh package source instead of the system
<pitti> s/package/source tree/
<cjwatson> pitti: bug 972324
<ubottu> Launchpad bug 972324 in xorg-server (Ubuntu) "server fails to start up if TMPDIR is set to something on a different filesystem from /var/lib/xkb" [Undecided,New] https://launchpad.net/bugs/972324
<pitti> cjwatson: thanks
<cjwatson> I'll probably work around it by something akin to env -u TMPDIR xvfb-run env TMPDIR="$TMPDIR"
<pitti> jibel: so, I'm not really sure what https://jenkins.qa.ubuntu.com/view/Precise/job/precise-adt-postgresql-common/lastFailedBuild/ARCH=amd64,label=albali/console is
<pitti> it doesn't seem to find the .deb it just built
<pitti> cjwatson: did you see failures from Python tempfile operations?
<pitti> I'm gettin
<pitti>     fd = _os.open(file, flags, 0600)
<pitti> OSError: [Errno 13] Permission denied: '/tmp/tmp.FecYZsCFYt/ubtree0-build/tmpdir/tmpkLfNk4'
<cjwatson> I haven't seen anything like that as yet
<cjwatson> but I'm using the schroot runner for convenience so perhaps that's a bit different
 * cjwatson <3 schroot
 * pitti tries to replicate this in his local kvm
<cjwatson> ubiquity's problem is part that X bug and part me being desperately stupid.
 * pitti seriously doubts the latter
<cjwatson> smb: reproduced
<penguin42> cjwatson: I put you as a reviewer on the fix for the procps/watch bug we discussed the other night
<cjwatson> penguin42: oh, yeah, I saw that in my mailbox thanks
<pitti> jibel: could you please re-run the upower adt test, and perhaps udisks with 1.5 GB RAM?
<cjwatson> jibel: OK.  I think the combination of autopkgtest 2.0.1ubuntu3 and ubiquity 2.10.6 should fix precise-adt-ubiquity.
<jibel> cjwatson, k, I re-run the test when it is in the archive. I'll add an option to run in a schroot when the test doesn't need the level of isolation of a vm
<jibel> pitti, tests are running with 2GB
<cjwatson> jibel: watch out that the schroot runner is a bit broken right now though - I filed a Debian bug with a fix, which I guess will show up on bugs.debian.org sooner or later
<cjwatson> so no rush on that, I can easily just do something like 'sudo adt-run ../ubiquity_2.10.6.dsc --- ~/src/ubuntu/autopkgtest/git/autopkgtest/virt-subproc/adt-virt-schroot precise-i386-sbuild'
<ochosi> kenvandine: ping
<kenvandine> ochosi, pong
<ochosi> kenvandine: hey, i wanted to inquire about indicator-messages-gtk2 a bit, are you the right guy to talk to? (lp suggested that)
<kenvandine> yup
<ochosi> ok, i wanted to ask about this bug (i
<ochosi> 've been going in circles trying to figure out what's wrong)
<ochosi> https://bugs.launchpad.net/ubuntu/+source/xubuntu-artwork/+bug/956147
<ubottu> Launchpad bug 956147 in xubuntu-artwork (Ubuntu) "thunderbird message indicator icons" [Undecided,Confirmed]
<ochosi> (afaik there shouldn't even be any icons)
<kenvandine> there shouldn't be
<kenvandine> there should be a thunderbird icon
<ochosi> right, so there's nothing for me (xubuntu artwork-dev) to fix
<ochosi> yeah, that's there, and then two text-only entries for addressbook and compose
<kenvandine> oh
<ochosi> it works as long as tb is closed, but as soon as it's running a "missing icon"-icon is shown
<kenvandine> looking at his screenshot, that isn't for thunderbird
<kenvandine> that is for evolution
<ochosi> right, well i can confirm it for thunderbird :)
<ochosi> i didn't test it with evolution
<ochosi> but thanks, i didn't notice that at first
<kenvandine> interesting, with the gtk3 build of it, it doesn't even try to add icons tehre
<kenvandine> there
<ochosi> is there anything i can do to debug this?
<sconklin> @pilot in
* udevbot changed the topic of #ubuntu-devel to: 12.04 Beta 2 Released! Precise: UI and feature freeze | Dev' of Ubuntu (not support or app devel) | build failures -> http://bit.ly/xmGdCW | #ubuntu for support and general discussion for hardy -> oneiric | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: sconklin
<kenvandine> ochosi, i am triaging it so the indicator-messages upstream sees it
<ochosi> kenvandine: thanks!
<ochosi> it'd be pretty great to get this fixed in time for precise, it's a highly obvious and annoying bug
<ochosi> and it affects ubuntu-studio and mythbuntu as well
 * astraljava emerges
<astraljava> What's that?
<pitti> jibel: hooray, adt-upower succeeded now
<ochosi> astraljava: https://bugs.launchpad.net/ubuntu/+source/xubuntu-artwork/+bug/956147
<ubottu> Launchpad bug 956147 in Messaging Menu "thunderbird message indicator icons" [Medium,Confirmed]
<ochosi> astraljava: if you can help me following up on that, that'd be great
<pitti> jibel: could you please restart jockey, too? fix is in teh archive
<kenvandine> tedg, did you see bug 956147?
<astraljava> ochosi: Whoopsie... I hadn't even noticed. Sure, I'll do what I can.
<tedg> Hmm, there shouldn't be icons there.
<tedg> They should be blank space.
<ochosi> tedg: as long as thunderbird is not running, there are no icons (i.e. everything is fine)
<kenvandine> tedg, right... so something weird with the gtk2 builds
<kenvandine> tedg, and notice in the screenshot it is evolution
<kenvandine> so it seems to affect both
<tedg> kenvandine, I think you have your default mail client set to Evolution :-)  "Mail" is default client
<kenvandine> oh
<kenvandine> ok
<kenvandine> :)
<kenvandine> tedg, i reproduced it with the indicator-loader
<tedg> larsu, Have you seen bug 956147 ?  Seems to happen in the GTK2 version.
<ubottu> Launchpad bug 956147 in Messaging Menu "thunderbird message indicator icons" [Medium,Confirmed] https://launchpad.net/bugs/956147
<kenvandine> evolution has the missing icons now
<kenvandine> tedg, so does "Update Status" under gwibber
<larsu> tedg, I'll have a look at it in a bit (doing the blacklist thing right now)
<apw> @pilot in
* udevbot changed the topic of #ubuntu-devel to: 12.04 Beta 2 Released! Precise: UI and feature freeze | Dev' of Ubuntu (not support or app devel) | build failures -> http://bit.ly/xmGdCW | #ubuntu for support and general discussion for hardy -> oneiric | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: sconklin, apw
<bigon> slangasek: hey, I'm looking at your multiarch patch for libcanberra, and it seems that libcanberra-gtk-module and libcanberra-gtk3-module are not really m-a
<bigon> as you are installing files in no m-a paths
<smoser> lool-, around ?
<PaoloRotolo> Hi all!
<smoser> lool- so i don't forget.  if/when you see this, my query was about linaro use of s3 mirrors, and if they've had issues.  we believe we've found and fixed the last issue in bug 948461
<ubottu> Launchpad bug 948461 in cloud-init (Ubuntu Hardy) "apt-get hashsum/size mismatch because s3 mirrors don't support http pipelining correctly" [High,Triaged] https://launchpad.net/bugs/948461
<tgardner> cjwatson, does the debian installer need to be rebuilt before linux-firmware udeb updates are incorporated into the ISO ?
<slangasek> bigon: hi, how do you mean, "not really m-a"?
<bigon> slangasek: well it was a misunderstanding that you can actually have bitwise identical files outside of /usr/share/doc/<pkgname>
<slangasek> bigon: ah, ok
<cjwatson> tgardner: scsi-firmware yes, nic-firmware no
<tgardner> vjwk, thanks
<tgardner> cjwatson, ^^
* stgraber changed the topic of #ubuntu-devel to: 12.04 Beta 2 Released! Precise: UI and feature freeze | Dev' of Ubuntu (not support or app devel) | build failures -> http://bit.ly/HaWdtw | #ubuntu for support and general discussion for hardy -> oneiric | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: sconklin, apw
<lool-> smoser: I seem to recall repsonding to an earlier query on the topic, but I don't remember who had asked me; in any case, I have been moderately using the S3 mirrors and didn't have any issue with them; they worked fast and reliably in my personal experience
<cjwatson> smb: OK, so I have a bit of a problem here
<cjwatson> smb: I've backported an upstream patch which I'm pretty sure fixes this problem, and it certainly makes grub-install work again
<smb> cjwatson, ok...
<cjwatson> smb: however, when I install that, it doesn't boot
<cjwatson> smb: now normally this would make me give up and revert the whole thing
<cjwatson> smb: except, when I install 1.99-18ubuntu1, that doesn't boot for me either in this environment
<cjwatson> smb: so I'm pretty sure this is a local problem.  Could you try out the packages I've built?
<smb> cjwatson, sure.
<smb> where ?
<GrueMaster> cjwatson: Morning.
 * smb meant where can I find the packages...
<GrueMaster> Here is a syslog from this morning's attempt.  The system is sitting at a prompt failing to mount /boot.  http://paste.ubuntu.com/913180/
<cjwatson> smb: just copying them up now
<cjwatson> GrueMaster: could I have the current recipe to go with that?
<cjwatson> preseed file, I mean
<GrueMaster> cjwatson: http://paste.ubuntu.com/913187/
<cjwatson> smb: http://people.canonical.com/~cjwatson/tmp/grub2/ - let me know if you need amd64 and I can build that
<smb> cjwatson, Yes, the box here is 64bit
<cjwatson> smb: OK, ETA <30m
<smb> ack
<GrueMaster> cjwatson: Where would I find what options partman is trying to mount /boot with?  That appears to be the failure (according to syslog).
<cjwatson> GrueMaster: mm, something's odd here, I want to trace this a bit
<GrueMaster> Let me know what I can run to help.  I have a system sitting at that failure, and I have ssh access.
<cjwatson> it looks for all the world like an attempt to mount ext4 as ext3
<cjwatson> what I don't yet know is why
<cjwatson> oh, blah
<cjwatson> GrueMaster: sorry about this - change "format { }" to "format{ }"
<cjwatson> as a result of that it wasn't formatting /dev/sda1, so you got whatever was there beforehand, which was apparently ext4
<cjwatson> it's not the world's smartest parser
<GrueMaster> Ah.  Let me respin with that.  Good eye.  I've been staring at partman recipes since Friday, getting a little buggy.  :P
<GrueMaster> YAY!  Seems to be going through.  Now installing base system (which means partman, while still grumpy as all hell, is satisfied for the moment).
<cjwatson> phew
<cjwatson> sorry that was opaque!
<cjwatson> the parser badly needs (a) a test suite (b) a rewrite, in that order.
<GrueMaster> And (c) Decent documentation.
<cjwatson> That wouldn't hurt.
<GrueMaster> Thanks for your help though.  I really appreciate it.
<cjwatson> You're welcome
<cjwatson> Hopefully that will cover the problems on all your machines ...
<GrueMaster> Now to figure out why 2 of the 3 systems is complaining about base system installation (3rd is almost finished).
<cjwatson> subarch-specific?
<cjwatson> though base-installer should support all the subarches in question.
<GrueMaster> All three are pandas.  Exact same makeup.  And they are all pulling netboot & preseed from the same location.
<GrueMaster> Only diff is mac address/ip.
<GrueMaster> Probably a network glitch.  I've seen it before.  Just need to kick the fenders.
<GrueMaster> cjwatson: Of lesser concern is the lvm naming.  In my recipe, I have Test-LVM as a blank area.  The finished product names it Test--LVM.  Not sure where the extra "-" is from, and it doesn't hurt (I plan on renaming that partition before production anyways).
<smoser> roaksoax, join #ubuntu-server
<roaksoax> lol o'm there :)
<cjwatson> GrueMaster: That's a devmapper requirement.  It uses "-" as a separator, so "-" gets escaped to "--".
<cjwatson> Though it should generally still be presented as "-", unless you're looking in /dev/mapper/ directly.
<GrueMaster> Ok.  Like I said, it isn't really a concern.  I plan on renaming that partition in my local systems anyways, to match the arm server testing environment.
<bdrung> doko: bug #972625
<ubottu> Launchpad bug 972625 in gccgo-4.7 (Ubuntu) "Can't install gccgo-4.7 in precise" [High,New] https://launchpad.net/bugs/972625
<doko> ouch
<smb> cjwatson, Ok, so for my system the updated grub packages fix the error on running grub-install and boot ok
<cjwatson> brilliant
<cjwatson> I was just about to tell you that the amd64 binaries were up ...
<cjwatson> (I missed them finishing for 20 minutes.)
<smb> :) Have been polling for them to appear because I got to leave soon.
<cjwatson> OK.  I'll get that uploaded then; it'll actually be -21ubuntu1.
<cjwatson> thanks!
<smb> Ah, ok. The I get them replaced when they are up. Thanks for resolving that so quickly
<cjwatson> Yeah, you would have done anyway actually since apt will reinstall even same version when the checksums differ.
<k-rAd-> what is the email address for ubuntu selinux department ?
<hrw> fun during oneiric->precise upgrade:
<hrw> locale: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.15' not found (required by locale)
<k-rAd-> i wish to lend a hand
<hrw> locale: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.14' not found (required by locale)
<slangasek> hrw: should be a non-fatal warning (which is why we haven't dug into it)
<micahg> k-rAd-: there isn't really one, you can try in #ubuntu-security though
<k-rAd-> thank you
<hrw> slangasek: its non-fatal
<dobey> hey all
<dobey> if i have a change which is related to a bug, but doesn't fully fix it for all cases, what's the best way to reference that in the changelog so lp doesn't auto-close the bug? is there a regex somewhere for what the server does, which i can match against to check my changelog?
<slangasek> dobey: the regexp is applied in dpkg-genchanges, not on the server; you can examine your .changes file prior to upload to see if there are launchpad bug references
<slangasek> (I don't remember the field name off the top of my head, but grep for Launchpad :)
<dobey> ok
<dobey> thanks slangasek
<cjwatson> dobey: I usually use 'LP #nnnnnn', omitting the colon after LP.
<dobey> cjwatson: thanks, i'll try that
<apw> cjwatson, load_video, can i tell if that worked?
<apw> cjwatson, in grub2 .cfg files ...
<cjwatson> EOD, sorry
<cjwatson> suggest you RTFS as I don't know off the top of my head anyway :)
<apw> cjwatson, np :)  will do ... have a good one
<cjwatson> probably depends what you mean by "worked", given it's graphics
<apw> cjwatson, yeah indeed, thats another wrinkle... i think we have enough info to avoid the question and for where we are in the cycle thats safest ... i'll brief you when i have the paired changes ready for thinking about committing
<apw> slangasek, did you have a machien which had the broken handoff behaviour ?
<apw> @pilot out
* udevbot changed the topic of #ubuntu-devel to: 12.04 Beta 2 Released! Precise: UI and feature freeze | Dev' of Ubuntu (not support or app devel) | build failures -> http://bit.ly/HaWdtw | #ubuntu for support and general discussion for hardy -> oneiric | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: sconklin
<rlaager> I maintain various packages in a private repository and a few PPAs. Is there a way to flag them so apport doesn't offer to send a report to Launchpad when, for example, their postinst fails?
<dobey> rlaager: it should not be doing that anyway, as they are not official ubuntu packages
<rlaager> dobey: I'm on Precise and it just did.
<slangasek> apw: remind me which broken handoff behavr we're talkig about?
 * slangasek stabs kvm in the face.  Give me back my keyboar interrupts.
<dobey> rlaager: is it a bug about the installation of your package, or the removal of an official ubuntu package, while installing your package which replaces the official one?
<rlaager> dobey: The postinst for my package failed on installation. This particular package, at least, did not cause any official packages to be removed.
<apw> slangasek, there are two triggers, (broken graphics cards in grub, or encrypted root so no way to do graphics), but with nouveau i think and psb graphics crossing from grub in text mode but with 'vt.handoff=7' triggers black screens of doom, double ESC sometimes helps sort of thing
<apw> slangasek, i am sure you were bugging me about something similar
<slangasek> apw: ah right, that one
<apw> slangasek, and i have potential fixes in the works which i'd like to get tested once they are packaged
<apw> and you are awake :)
<slangasek> apw: I have a box with nvidia graphics here for testing, but I haven't tried to reproduce this yet
<tgardner> apw, I've got one for the nVidia problem
<apw> tgardner tells me his box hits the issue, with nvidia ... :)
<apw> see
<apw> ok will start with tgardner and expand from there
<dobey> rlaager: ah sorry, i misread. apport will offer, but it will fail because it's not an official package. i don't think there is any way to prevent that in package metadata itself
<tgardner> apw, guess I'll get it back in that state again....
<rlaager> dobey: Okay. Well, I'll just have to make less buggy packages. ;)
<dobey> yes :)
<apw> slangasek, in your inbox is an email 'On vt.handoff' which has the details of what I would like to test
<infinity> Someone remind me which bit I need to double-check to make sure my headless/remote machine will reboot with a degraded RAID?
<infinity> Maybe I should just fix the disk and rebuild the array before I try rebooting. :P
<stgraber> infinity: mdadm/boot_degraded
<stgraber> infinity: that and make sure you have grub in the mbr of the working disk
<infinity> stgraber: grub *should* be correctly installed to both disks.
<infinity> stgraber: But thanks for the boot_degraded pointer.  I'm pretty sure I answered that at install, but wanted to be sure.
<rlaager> Security Question: /usr/bin/at is currently permissioned "6755 daemon daemon". Doesn't that make it possible, if there's a bug in at, for a regular use to run at, which could be used to overwrite itself, leaving evil code for root to run later on? In other words, wouldn't 6555 be better?
<infinity> rlaager: Can you file a bug?
<infinity> rlaager: But yeah, potentially true of any non-root suid binary, I suppose.
 * infinity wonders how many of those we have...
<rlaager> I think at is the only one (in a <= desktop install, which is what I have).
<infinity> rlaager: The real bug could be that it should be 2755 root:daemon instead.
<rlaager> infinity: The changelog documents the intention to be suid daemon.
<infinity> (See: mlocate, wall, ssh-agent, etc)
<rlaager> I have some permission limiting code that I've carried forward forever. It was originally from the bastille script. I was just auditing it to see what it actually accomplishes any more. It was basically that, removing setuid from mount/umount (these are servers, so there's no need for users to mount filesystems), and dropping read permissions from ELF binaries (which seems of dubious value).
<infinity> rlaager: Sure, but perhaps sgid would be enough.  Dunno.  Either way, bug report please. ;)
<rlaager> infinity: Should I subscribe the Ubuntu Security Team or not?
<infinity> Ahh, kay, so the changelog details why it needs to run as daemon (to signal atd), but it also claims it's installed 6555.
<infinity> So, it might just be a packaging error introduces later that made it 6755.
<infinity> I see no mention of the change.
<infinity> rlaager: If it's in previous releases as well, yeah.  This would probably warrant an update.  It's not exactly a massive exposure window (or, possibly, not one at all, if at is bug-free), but it's a security bug nonetheless.
<infinity> The part where it does everything internally sgid, though, and only needs daemon to signal itself seems like something that cuold be fixed.
 * infinity shrugs.
<psusi> cjwatson: is installing grub to partitions supposed to be supported in Ubuntu or not?  I thoguht it wasn't, but the debconf screen for grub-pc has a note saying it is possible, but doesn't actually give the partitions as a choice
<vanhoof> superm1: ping
<superm1> vanhoof: hi
<vanhoof> superm1: alberto mentioned a change for dkms that he recently proposed that you ack'd, just curious when we might see a new dkms upload?
<vanhoof> superm1: not sure if you have other bits to factor in first :)
<superm1> vanhoof: i was hoping to do another release first, but I could just test that patch and do an upload to ubuntu this week in case I don't get around to another release in time for next freeze
<vanhoof> superm1: cool, that would be awesome if you could :)
<superm1> sure, will plan to do that
<vanhoof> superm1: thanks Mario
<cjwatson> rlaager: I'm not sure I see how 6555 could help.  A process whose effective UID matches the owner of a file can chmod that file.
<cjwatson> Non-owner-writability is more a safety catch than an effective security measure.
<cjwatson> That said, writing to the file as daemon will clear the set-user-id bit, IIRC.
<nailora> could one of you make  bug #954895 public if possible
<ubottu> Error: Launchpad bug 954895 could not be found
<Laney> nailora: done
<rlaager> cjwatson: Good point. I was actually hoping for "you're missing X" as the answer, so I could drop that from my configuration.
<rlaager> cjwatson: Are you confident enough in that answer to (tell me to) close the bug?
<cjwatson> rlaager: I'm not confident that it isn't an issue, just that 6555 wouldn't help. :-)
<cjwatson> Or at least seems to have some problems as a solution.
<rlaager> Can someone please re-open #570542? It has multiple comments confirming the bug is present in Maverick final, Oneiric, and Natty and #658461 has been marked as a duplicate of it.
<micahg> rlaager: you should talk to the kernel team (#ubuntu-kernel)
<jono> I wonder if anyone can help with this? I am trying to generate a .pot file from a .desktop file that has underscores before each key - I created po/POTFILES.in with the file in it and have run 'intltool-update --verbose --pot --gettext-package=foobar' but it says 'None of the files in POTFILES.in contain strings marked for translation.' - which is odd as the .desktop does have the underscores before the strings
<jono> any idea?
<cjwatson> I bet there's more output than that
<cjwatson> also are you running that in the right directory?  I think you normally want to run it in po/
<jono> cjwatson, I am running it in po/
<jono> cjwatson, I will pastebin the full output
<cjwatson> Maybe it would be quicker to debug from a tarball
<jono> cjwatson, http://pastebin.ubuntu.com/913809/
<jono> cjwatson, I can put that together if you prefer
<cjwatson> yeah, that would be easier
<jono> thanks cjwatson, one sec
<jono> cjwatson, I emailed it to you
<cjwatson> jono: move foo.desktop to foo.desktop.in and make the same change in POTFILES.in
<cjwatson> it's not actually a valid .desktop file when it has the translation prefixes in it - it needs to be run through intltool-merge first
<cjwatson> sorry, I don't really mean first, you'll do that afterwards
<cjwatson> anyway the rename to .in makes it work
<doko> bdmurray, do you have a lp script which takes a list of debian bug reports, files corresponding ones in lp, and links the debian reports?
<tumbleweed> doko: there's one in ubuntu-dev-scripts import-bug-from-debian (single bug, though, but that's easily scripted around)
<tumbleweed> err ubuntu-dev-tools
<doko> tumbleweed, thanks, I'll have a look
<tumbleweed> oh, it does do multiple bugs
<jono> thanks cjwatson, sorry was on the phone
<jono> so it requires the .in extension
<jono> thanks
#ubuntu-devel 2012-04-04
<cnd> doko, how can I easily test gcc 4.7 in precise, so I can fix an FTBFS in debian when compiled with 4.7?
<cnd> perhaps I just need to create a sid or wheezy chroot?
<cjwatson> cnd: creating a sid chroot is easy with mk-sbuild (say), and I'd recommend having one available if you need to test builds on Debian
<cnd> ok
<cnd> I'll try it out
<cjwatson> in my setup, I can type 'sbuild -Asd unstable' and the source package tree I'm in gets built in an unstable chroot and produces a .changes that's suitable for upload to Debian
<cjwatson> or 'sbuild -Ad unstable /path/to/foo.dsc' in a temporary directory to test-build a .dsc
<thestormsedge> hello all :)
<thestormsedge> I want to get invovled with Ubuntu development (preferrably on a Python or PSQL project) and how do I do that?
<sconklin> @pilot out
* udevbot changed the topic of #ubuntu-devel to: 12.04 Beta 2 Released! Precise: UI and feature freeze | Dev' of Ubuntu (not support or app devel) | build failures -> http://bit.ly/HaWdtw | #ubuntu for support and general discussion for hardy -> oneiric | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<RAOF> thestormsedge: Is there anything particular that you want to do?  One of the problems with people asking about getting involved is that the possible answers are huge.
<thestormsedge> mostly simple things, probably just edits in application source code first or Ubuntu websites
<thestormsedge> though I don't know much C++, I would probably have to tackle some Python issue
<thestormsedge> I guess my biggest question is how exactly does the contribution process works, lets just say I have I figure out how to do a simple patch on my own
<thestormsedge> do I just haphazardly start figuring out how to code, then start submitting things, or is there a more formal process?
<RAOF> Pretty much the former.
<RAOF> The other thing to realise is that *almost all* of the work that goes into Ubuntu isn't done by us, and we aren't really the gatekeepers for it.
<RAOF> It's done by the various âupstreamâ projects.
<thestormsedge> oh ok thanks the advice RAOF. I've always wanted to work on some FOSS project and was sort of confused on how all the Wikis, intros, et al. were organized
<RAOF> So one of the possible endpoints of contributing to Ubuntu is to find a project that you care about and start fixing things there.
<thestormsedge> basically I just take the tutorials, begin coding on something of my interest, and then see if it gets accepted via Launchpad, Github etc?
<RAOF> We do have some process around being something of a central place for contributions - you *can* attach patches to Ubuntu bugs on Launchpad, and we'll check them out.  Much of the time we'll then prod you to submit them to the upstream project, though.
<thestormsedge> kk thanks for the explanations ^-^ I have been super confused about FOSS development for the longest time
<RAOF> There are a wide variety of ways that upstreams like to receive contributions, but one common thread is that the (almost!) always have some form of mailing list for discussion, and reading the mailing list archives should give you a reasonable idea of how to submit code and what people think need fixing.
<thestormsedge> kk cool :)
<pitti> Good morning
<dholbach> good morning
<bkerensa> cjwatson: ping
<sabdfl_> how does one run a shell script so that it echoes what it's doing?
<geser> sh -x the_script
<geser> or bash -x if it's a bash script
<sabdfl_> thanks geser
<sabdfl_> geser, is there a way to turn that on inside the script?
<geser> add "set -x" near the top of the script (adding -x to the shebang line should work too)
<pitti> sabdfl_: you can surround the part that you want to debug with set -x and set +x
<pitti> sabdfl_: if you want to write the output into a file, put a "exec 2>/tmp/log" in front of it
<sabdfl_> pitti, geser, thanks much
<sabdfl> pitti, morning, quick question re live cd image
<sabdfl> can the filesystem on that have a UUID?
<pitti> sabdfl: the squashfs you mean?
<sabdfl> pitti, hmm, no i meant the iso9660 one
<sabdfl> i have a peculiar interest in mounting it over iscsi
<pitti> I don't think it can; blkid at least doesn't give an UUID for it
<sabdfl> yeah, question is whether that's intrinsic to the fs, or just something we didn't turn on when we made it
<pitti> there do seem to be approaches to generate one, like in grub (http://www.mail-archive.com/grub-devel@gnu.org/msg07924.html)
 * pitti RTFS util-linux
<pitti> above grub patch makes one up from the timestamp
<pitti> confirmed, no UUID support in libblkid/src/superblocks/iso9660.c
<pitti> that doesn't necessarily mean that iscsi doesn't support it, of course
<pitti> blkid is just what udev etc. use
<cjwatson> bkerensa: hi - yep, got your mail
<cjwatson> sabdfl: squashfs doesn't have a UUID itself as far as I know, but we hack around that by putting a file matching .disk/casper-uuid* on the filesystem
<cjwatson> sabdfl: that doesn't help directly with mounting remotely - casper mounts, checks whether that file matches its own notion of what the UUID should be, unmounts if it doesn't and tries again
<cjwatson> oh, I should have read all of scrollback :-)
<sabdfl> ah, ok, that might help
<cjwatson> oh actually .disk/casper-uuid* is on the ISO9660 filesystem not the squashfs, so even better
<doko> pitti, no, no, no for your mpfr4 upload ...
<doko> just use -O2 for that one file
<pitti> doko: as I said on the bug report, it's not just one file
<pitti> I stopped after it crashed on the 7th
<pitti> (selectively building with -O2)
<doko> bah
<pitti> doko: shoudl I try it with gcc-4.5, and -O3?
<doko> pitti: no, not anymore in main
<pitti> gcc-4.5 | 4.5.3-12ubuntu1 |       precise | source, amd64, armel, armhf, i386, powerpc
<pitti> doko: it's still in main; is it planned to drop it still?
<doko> looking ...
<doko> pitti: mysql-5.5, u-boot-linaro still using it
<bdrung> doko: bug #966570 (gccgo seems to need something from the gcc-4.7 package
<ubottu> Launchpad bug 966570 in gccgo-4.7 (Ubuntu) "/usr/bin/ld: cannot find -lgcc_s" [Undecided,New] https://launchpad.net/bugs/966570
<doko> bdrung, expected, use -static-libgcc
<azeem> can you get a newer openjdk6 than 6b20 to run on lucid, like 6b23 or 6b24?
<azeem> (are there any backports?)
<nailora> once again a request to make a bug public: bug #937249
<ubottu> Error: Launchpad bug 937249 could not be found
<nailora> thanks in advance
<penguin42> cjwatson: I pushed an update to my procps fix that also fixed bug 432861
<ubottu> Launchpad bug 432861 in procps (Ubuntu) "kill -s crashed with SIGSEGV" [Medium,Triaged] https://launchpad.net/bugs/432861
<apw> cjwatson, slangasek, either of you seen reports of the boot splash being ok,
<apw> but the shutdown splash being all odd colours ?
<doko> pitti: https://bugs.launchpad.net/ubuntu/+source/pygtk/+bug/955898   these issues are again accumulating for the interpreter package :-(
<ubottu> Launchpad bug 955898 in pygtk (Ubuntu) "python2.7 crashed with SIGABRT in raise()" [Undecided,New]
<dobey> hey all. what's the best way to install extra files into /usr/share/doc/$package? i have override_dh_installdocs, which seems to get run, but the files aren't in the resulting binary packages it seems
<janimo> dobey, adding them in debian/docs ?
<janimo> or debian/binary-name.docs ?
<dobey> janimo: eww. those are ugly. discovered dh_installdocs -A though, which seems to do it. was looking at another package for example that was apparently last updated in 2009, which didn't use -A, so maybe that changed at some point, or that package has always been broken. :)
<janimo> dobey, I always thought d/docs is better as it is declarative, i.e less chances of messing up cp/install invocations, and keeps rules file cleaner. I do not know what the recommended way is though or whether the docs way is discouraged
<dobey> janimo: well, having N .docs files which all list the same things seems bad to me. for things which should only go in the -dev package or such, i would agree those should be done with the docs files
<janimo> dobey, listing the same things? One package installs the docs and the other binaries should symlink only but I admit I don't know if that is handled by declaring them in docs
<cjwatson> if you want to install the same docs into lots of packages, you should consider using dh_installdocs --link-doc=some-appropriate-common-package
<cjwatson> you may need some preinst code to deal with upgrades, as dpkg deliberately never replaces a directory with a symlink of its own accord
<dobey> well they are just license files
<dobey> it seems those get copied to all packages by default?
<cjwatson> licensing information should go in the copyright file rather than being installed as separate files
<dobey> the copyright file is also installed
<cjwatson> licensing information should not be installed as separate files
<cjwatson> if everything necessary to understand the licensing of the package isn't in copyright, that's a bug
<cjwatson> once you've done that, you don't need any other files
<dobey> for the GPL+OpenSSL exception case where the OpenSSL license is included in the source, but openssl itself is not?
<cjwatson> my statements apply regardless of the details :)
<dobey> what is the "proper recommended way" to do this then? the package (hpoj) i was looking at as an example, and which was mentioned in http://lists.debian.org/debian-legal/2004/05/msg00595.html seems to install the extra files
<cjwatson> copy necessary information into the copyright file
<cjwatson> (preferably in the new machine-readable format, although that isn't yet mandatory)
<cjwatson> eventually we want to be able to automatically scan copyright files for problems, and it won't fly to have to go hunting around other files as well
<cjwatson> the copyright file must have everything
<dobey> what is "necessary" here? it's not entirely clear
<cjwatson> if it isn't necessary, you don't need to install it :-P
<cjwatson> perhaps http://www.debian.org/doc/packaging-manuals/copyright-format/1.0/ will help, to have a fixed format
<cjwatson> necessary: the package must include its copyright information and a copy of the licensing terms under which it's distributed
<cjwatson> so if something's part of its licensing terms, it's necessary, if not, it isn't
<dobey> ok
<seb128> doko, I wonder if all those segfault in __find_specmb() are not a libc issue
<seb128> doko, like we got a bunch of those in C softwares as well, i.e bug #966446
<ubottu> Launchpad bug 966446 in gnome-control-center (Ubuntu) "[soundnua]: gnome-control-center crashed with SIGSEGV in __find_specmb()" [Medium,In progress] https://launchpad.net/bugs/966446
<doko> seb128, but there pygobject is involved too. do you see one unrelated to python?
<seb128> doko, the one I just pointed
<doko> ahh, control-center ...
<cjwatson> seb128: __find_specmb calls strchrnul on the format string provided, so it will segfault in the same way that strchrnul will segfault on invalid data
<cjwatson> i.e. my guess is that this is an application bug for providing a non-null-terminated format string, or a pointer into invalid memory as the format string
<cjwatson> libc's entitled to segfault when you do that
<seb128> cjwatson, could well be yes
<seb128> cjwatson, doko just reassigned a bunch of such bugs to pygobject, so I pointed we got some similar non python bugs as well
<cjwatson> valgrind should find it
<seb128> but yeah, they could well be different issues
<doko> yeah, that was my best guess, but maybe pygtk would be the common denominator then?
<seb128> doko, it would be a bug in pygobject yes, I will let pitti check, I will try to get a valgrind log for the gnome-control-center one
<seb128> cjwatson, doko: thanks
<doko> slangasek, 954609, no, I'll add the python2 symlink to python-defaults, now that the pep is accepted
<Sweetshark> do I need to fear someone syncing neon27? because of http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=667043 that would cause trouble.
<ubottu> Debian bug 667043 in libneon27-gnutls "libneon27-gnutls: Breaks bzr-svn (via subvertpy): undefined symbol ne_ssl_context_get_flag" [Serious,Open]
<Sweetshark> or to put the question differently: where can I put a big fat yellow signpost saying: "If you sync neon27-0.29.6-2 you will need to fix bzr-svn, libreoffice and likely a few other!!!1!" to make sure it meets the right audience?
<nessita> hello all! quick question, if an upstream code is released under the AGPL license, shall the ubuntu packaging distribute the AGPL license? I'm asking since I don't have the AGPL text in /usr/share/common-licenses/
<cjwatson> nessita: yes, it must
<nessita> cjwatson: any reason why the AGPL is not already in the common-licenses folder?
<stgraber> nessita: http://dep.debian.net/deps/dep5 describes that case (the full license needs to go in debian/copyright if not in common-licenses)
<cjwatson> nessita: it's insufficiently common
<nessita> stgraber: right, thanks
<nessita> cjwatson: ack :-)
<ochosi> kenvandine: hi again, quickly wanted to follow up on Bug #956147.
<ubottu> Launchpad bug 956147 in Messaging Menu "thunderbird message indicator icons" [Medium,Confirmed] https://launchpad.net/bugs/956147
<kenvandine> ochosi, it's on my list of bugs to nag tedg about :)
<ochosi> kenvandine: ok thanks! :)
<kenvandine> tedg, or should that be larsu that i nag for that one?
<larsu> kenvandine, it's larsu :(
<larsu> kenvandine, ochosi, sitting on it right now, expect a patch in a bit
 * tedg hears that larsu loves GTK2
<kenvandine> larsu, i assigned it to you :)
<ochosi> larsu: sweet! if i can help you test it let me know
<ochosi> larsu: i'll be around for ~another hour or so
<larsu> ochosi, cool thanks!
<larsu> tedg, can't decide if I'll hack a fix into messaging-menu or fix it correctly in libdbusmenu
<larsu> tedg, gtk2 ftw!
<ochosi> +1 (as long as xfce isn't ported yet)
<kenvandine> larsu, if you get a patch that is confirmed to work, ping me and i can distro patch until we get around to doing a release
<larsu> kenvandine, cool thanks, but I think I've just decided to fix this in i-messages and get that patch into the release charles is doing today
<kenvandine> ok
<bdrung> doko: can you give the eclipse-* package a retry for the test rebuild?
<doko> bdrung, done
<bdrung> thanks
<larsu> kenvandine, ochosi, no matter what I do, I always break something else in that menu. Are you okay with me ifdef'ing a line that'll break the alignment of "Compose New Messsage" and "Contacts" for gtk2
<ochosi> larsu: define "break the alignment"
<larsu> ochosi, they'd be left-aligned instead of with the label of the app, as in the gtk3 version
<larsu> ochosi, i.e. the label floats to the left, were the broken icon is now
<ochosi> larsu: humm, well it's not ideal, but it's better than the broken icon
<ochosi> larsu: how is the alignment done atm?
<larsu> ochosi, setting an empty icon. For some reason, gtk2 interprets that as broken...
<ochosi> larsu: yeah, i was mostly wondering because this kind of alignment is nothing special in gtk2 menus, i actually thought it is default behavior...
<larsu> ochosi, indicator-messages is not using the standard menu items, because it adds all kinds of stuff. If I remove the icon completely, the labels float left in gtk3 and gtk2
<ochosi> larsu: hmm, i guess i'd have to look at the indicator-messages code myself to understand the problem for real
<ochosi> larsu: if you have a screenshot or something to test for me, i guess that would help in giving a real opinion. but if you say it's not fixable in any other way atm then go ahead
<larsu> ochosi, http://imgur.com/H9Ope (note the left-aligned labels under Polly and Thunderbird)
<ochosi> larsu: yeah, it's not unreadable or anything, there are still separators and appicons to help with the structure of the menu. i'm ok with that
<larsu> ochosi, cool. Sorry, I'd have rather fixed it the right way, but i-messages has gotten quite complex (especially since it contains both the gtk2 and 3 version in the same source)
<ochosi> larsu: thanks for fixing this so quickly! :) yeah, i'm wondering how long will you maintain the gtk2 version?
<ochosi> larsu: one more thing: i assume that you also positioned those menuitems with empty images when thunderbird or $application wasn't running, i wonder why the bug only occurs when thunderbird is open (the action-items "compose" and "addressbook" are there before as well)
<larsu> ochosi, I'm not the maintainer of i-messages, but I'm pretty sure we'll drop gtk2 support next cycle
<larsu> ochosi, the empty icon is only set when thunderbird is running. That's a different bug which also affects the gtk3 version :-/
<ochosi> larsu: ah ok
 * micahg would like to know how much work the gtk2 support is for the indicators, Xfce is stuck with GTK2 until at least 13.04
<ochosi> micahg: +1
<dobey> ok, can someone tell me what the heck is going on here? http://paste.ubuntu.com/914786/
<dobey> why is bzr bd not using the changes i just imported/committed, correctly?
<dobey> james_w: ^^ any ideas on that?
<james_w> dobey, would you pastebin "bzr diff -c -1" please?
<dobey> james_w: http://paste.ubuntu.com/914804/
<james_w> dobey, find /home/dobey/Projects/canonical/ubuntu/ -name "rhythmbox-ubuntuone_2.99.92.orig.tar.gz"
<hallyn> drat - can't reproduce the libvirt race in fedora.  nor do the fedora out-of-tree patches help our package.
<james_w> I wonder if there is a rogue copy of that file around that isn't what we think it is
<dobey> james_w: indeed there was a tarball that had the old version in it. how the heck would that have happened?
<dobey> inside build-area
<james_w> dobey, I don't know. It can happen if you have some tags messed up
<james_w> dobey, but if that log was all your interactions with this version then I've no idea how it happened
<james_w> like, if you accidentally pass it the wrong tarball once it can be hard to make it forget it
<james_w> but it shouldn't just decide that a tarball is actually called something different
<dobey> yeah. well i've tried the same thing like 10 times it wouldn't stop doing that
<dobey> but all the same commands
<dobey> same commands i've used a million times to update all the other packages i work with :-/
<dobey> weird
<apw> slangasek, about?  i think you are the closest to an expert on plymouth splash ... i have a radeon which is showing very odd colouring during shutdown splash particularly, and when configured 'right' i think is also wrong during boot
<apw> slangasek, seen anything like that, and any ideas how to debug this puppy ?
<slangasek> apw: what sort of "very odd colouring"?  Like, 16-bit framebuffer where you'd really rather have a 32-bit one?
<apw> slangasek, like the colourmap is wrong i think the bitcount is good
<slangasek> apw: right, the colormap is wrong because you *have* a colormap ;)
<apw> so purpleish background, but a green spray where it should be fading into the background (it == UBUNTU)
<slangasek> apw: plymouth only actually supports truecolor, and VGA
<slangasek> so if your video card gives you a 16-bit framebuffer, this is what you get
<slangasek> (there's a bug open on the plymouth package; I can hunt the bug # if you like)
<apw> slangasek, so if i see it on shutdown, seeing it on startup means my startup _isn't_ wrong :)
<slangasek> yes... :)
<apw> slangasek, this is in the context of the handoff bug, in fixing it, i have exposed this on my test box
<apw> slangasek, and that lets me say ... i think its ok then
<slangasek> apw: bug #564471
<ubottu> Launchpad bug 564471 in plymouth (Ubuntu Natty) "Lucid: garbled video at boot on radeon cards: bad color map due to 16-bit fb" [High,Triaged] https://launchpad.net/bugs/564471
<slangasek> OTOH, I don't know what bit-depth the fb is supposed to be when grub hands it off to the kernel... :P
<slangasek> though the drm driver is probably inclined to reconfigure that regardless
<apw> slangasek, heh well this is in the "we are not handing off" mode.  in handing off mode it happens to work ... presumably because grub didi the right thing
<slangasek> right, ok
<apw> so for me, fixing this handoff=true breaks things bug will regress boot on my radeon, by making it look poor like it already does on shutdown :)
<slangasek> heh
<apw> slangasek, did you have an affected machine ?  i forget now ?
<slangasek> how exactly are you "fixing" the handoff though?
<apw> slangasek, the theory here is to pass over a handoff enable flag as well based on the gfxpayload setting
<apw> slangasek, this has all sorts of niceties ... one its only enabled when grub says it did it, two if you change gfxpayload=xxx to =text the right thing happens
<apw> slangasek, basically i am doing this in grub: adding 'vt.handoff_enable=$gfxpayload' to the default command line
<slangasek> apw: I have a radeon machine for testing, I don't know if it's able to reproduce this particular bug
<slangasek> apw: aha, that sounds perfect
<apw> slangasek, of course we still need to tell grub that its got no hope of doing graphics when you are on encrypted disk
<apw> slangasek, any suggestions as to the best way to figure that out
<slangasek> apw: would it be simpler to overload vt.handoff itself, not passing it at all when gfxpayload != keep?
<slangasek> sorry, what do you mean "no hope of doing graphics when you are on encrypted disk"?
<charles> larsu, wrt bug #956147, can you walk me through that proposed merge?
<apw> slangasek, to do that we'd need something clever in grub ... here i am literally making the bit that grub includes in the command line 'vt.ha
<ubottu> Launchpad bug 956147 in Messaging Menu "thunderbird message indicator icons" [Medium,Confirmed] https://launchpad.net/bugs/956147
<apw> slangasek, to do that we'd need something clever in grub ... here i am literally making the bit that grub includes in the command line 'vt.handoff=7 vt.handoff_enable=$gfxpayload'
<charles> larsu: in short I guess I don't understand what http://bazaar.launchpad.net/~indicator-applet-developers/indicator-messages/trunk.0.6/revision/252.2.2 was for
<apw> slangasek, as grub fills that in with 'text' or 'keep' and i use those as special cases of true and false
<slangasek> apw: doesn't require too much cleverness, I think we could easily toggle the vt.handoff=7 in grub
<apw> slangasek, appearenetly the grub device drivers for graphics are in the encrypted disk
<apw> slangasek, at least that was what i thought i was being told
<slangasek> that makes no sense to me :)
<slangasek>  /boot always has to be unencrypted
<apw> slangasek, that is a good point ... hrm ... i am sure thats what cjwatson was saying
<slangasek> I'm using cryptsetup, I have no problems with video here
<apw> yeah now i am flummoxed as to what the heck i am doing
<slangasek> :)
<apw> the underlying issue is that nouveau and psb drivers are not always happy when we handoff to them, if grub puts us in text mode, but we claim handoff so the kernel does not reset things
<apw> so that if grub is set for text, we don't want to enable handoff, so thats really what i am aiming to fix
<slangasek> right
<apw> as you would do that if its broken
<slangasek> so there are two cases you'll get text instead of keep, on any system
<slangasek> - the recovery boot option
<slangasek> - when the previous boot didn't complete successfully
<apw> in recovery we don't add the handoff at all so its not relevant i think
<apw> but for the second one we must hit the issue yes
<apw> slangasek, now if we can not put on handoff that is fine, i was under the impression it wasn't easy as string mangling was hard.  i have the patches to use this new enable just testing the cleaned up kernel bit now
<apw> and the patch for grub is very small as its only 10_linux that changes
<slangasek> apw: splitting strings is hard, concatenating them is easy... we'd just move the vt.handoff=7 bit out of the pre-generated string and append it dynamically, I think
<slangasek> should still only change 10_linux
<apw> does that make it harder to debug should you not want it
<apw> should you want to test without it
<slangasek> I don't think so
<apw> http://people.canonical.com/~apw/vt-handoff-grub-precise/0001-TEST.patch
<apw> bah not that one
<apw> http://people.canonical.com/~apw/vt-handoff-grub-precise/grub-10_linux.diff
<apw> slangasek, ^^ that is the grub change i am using
 * slangasek nods
<apw> slangasek, ok ... wahts the right thing to do here.  not specificying the handoff at all will work fine kernel side
<slangasek> apw: on a call now; give me about an hour to cook a patch for grub the way I think it should be, that won't require any extra kernel options?
<apw> slangasek, ok .. will check back later
<L3mce> Hello. In an attempt to run our script in init.d prior to the other S99's, but after the S98's our project has always named that script beginning with a 0. I have rewritten the way this script functions and as a result noticed that it was running twice, whereas the old method masked this behavior. Throwing a $1 confirms two starts were sent, pstree indicated that rc was issuing both calls, so I read rc, and it turns out that it is
<L3mce> very clever in attempting to figure out runlevel, however as a result, any scripts updated there with a digit are run from rc5.d as (in our case) 99 and again as 90. Would it be appropriate for me to write a patch which counts digits and changes the nomenclature of the symlinks created?
<L3mce> I guess it would be smarter to make rc count digits
<apw> L3mce, can't you use _ or something similar ?  instead of 0, and avoid the issuue?
<L3mce> I have renamed it a0start_avwizard I just thought that in the future if rc was not confused by digits it would be better for the product.
<L3mce> I am solved. I just didn't know whether to file a bug and a fix.
<L3mce> or which version to attach it to
<sabdfl> what tool builds the iso? i have a squashfs from live-build and would like to make a small live iso from it
<penguin42> would you expect fortify to throw if you tried to snprintf into a 64byte buffer, a 40 character string, but the length you told snprintf the buffer was was 128 ?
<penguin42> I guess snprintf might 0 term the last byte or something
<slangasek> sabdfl: the "last mile" of ISO generation is done with ubuntu-cdimage and an internally-maintained debian-cd; both of these are private branches on nusakan
<kees> what does whoopsie-daisy do that apport doesn't?
<JanC> slangasek: why private?
<slangasek> JanC: because, er, sabdfl didn't let cjwatson release it ;)
<slangasek> (or something like that)
<sabdfl> yeah yeah
<slangasek> kees: it's the crash-database client
<slangasek> kees: so it reports to the crash database with its nosql magic data aggregation, rather than LP
<kees> ah-ha
<kees> so it took over some of the crash reporting stuff that apport was doing?
<L3mce> sabdfl: take a look at ubiquity/casper
<sabdfl> thanks slangasek
<slangasek> sabdfl: sure :)
<slangasek> kees: yes; the plan is that pre-release, it'll be reported to *both* LP and the crashdb, and post-release we'll only report to the crashdb - so not asking users difficult bug-reporting questions
<kees> slangasek: excellent.
<hallyn> FINALLY!
<hallyn> apparmor is to blame!  but, only indirectly :)
<L3mce> mountall?
<stgraber> hallyn: still balming apparmor? ;)
<stgraber> hallyn: btw, if you want to blame it some more, it looks like "ro, remount" still doesn't match (or stopped matching again, one of the two). Got some apparmor DENIED when rebooting a container today
<hallyn> stgraber: see final comment in bug 961217
<ubottu> Launchpad bug 961217 in libvirt (Ubuntu) "virsh start domain sometimes fail in oneiric" [High,Confirmed] https://launchpad.net/bugs/961217
<hallyn> stgraber: hm, interesting - but the noise is ok with me so long as we're refusing the remount :)
<stgraber> hallyn: yeah, at least that part works ;)
<stgraber> jjohansen: ^ :) not urgent but "deny mount options=(ro, remount) -> /," still doesn't match... (call "halt" in a container and look at dmesg to reproduce)
<jjohansen> stgraber: yep, still working on part 3 of the fix, it should hopefully land friday
<stgraber> jjohansen: hehe, ok :)
<slangasek> apw: untested: http://paste.ubuntu.com/915139/
<quadrispro> hi all
<slangasek> apw: do you have a master bug # for this, btw?
<slangasek> N: 1020 tags overridden (1020 errors)
 * slangasek fears
<seb128> slangasek, hey
<slangasek> seb128: hey there
<slangasek> freetype? :)
<seb128> slangasek, are you subscribed to the freetype mailing list?
<slangasek> yeah
<slangasek> seb128: isn't Werner wrong about default dpi?
<seb128> slangasek, I think they picked up the space discussion from my email, not the gtk underline issue
<slangasek> my X server says 96
<slangasek> not 72
<slangasek> right
<seb128> slangasek, 96 is default yes
<slangasek> maybe if we get the code right, both issues are fixed?
<slangasek> I don't know though
<seb128> and I'm pretty sure things in the stack hardcode 96 nowadays
<seb128> slangasek, well, reverting fixes both
<seb128> slangasek, but upstream doesn't seem to think it's the way forward :p
<slangasek> yeah
<slangasek> but upstream may just be mistaken about what the defaults are
<slangasek> I was going to follow up later today and point that out
<slangasek> though perhaps the conclusion there is still that gtk is using the wrong API call?  I don't know
<slangasek> the discussion is a bit too deep for me :){
<seb128> slangasek, yeah, I didn't understand everything either but I'm pretty sure GTK enforce 96 dpi and doesn't use the xorg returned value
<slangasek> well, and X is spitting out 96 anyway regardless of physical dpi
<seb128> slangasek, http://git.gnome.org/browse/gnome-settings-daemon/commit/?id=a49af89751057649034a42c511d2330d63bbfa6e
<slangasek> for reasons that have been well-trodden :)
<seb128> slangasek, right
<seb128> slangasek, well in any case I was pinging because I'm unsure their discussion is covering at all the gtk underlining issue, I don't understand why that has to do with the spacing
<slangasek> I don't either...
<slangasek> perhaps it's because gtk calculates the bounding box with an off-by-one error compared with what freetype returns, and the underline gets clobbered by the glyph?
<seb128> slangasek, I pointed it to the gtk guys, behdad (pango's upstream) said he would have a look
<seb128> <Company> it's either clipping (though we don't do that for labels)
<seb128>  or a pango bug
<seb128> slangasek, that's basically the replies I got, but I think I will have news tomorrow from their side
<seb128> slangasek, I will keep you updated
<slangasek> ok
<bdrung> jdstrand: re distro-info MIR, in your last comment, did "upstream is volatile" refer to liblist-compare-perl?
<jdstrand> bdrung: no, it referred to the fact that the package is constantly being rewritten
<bdrung> jdstrand: see my comment. it won't be rewritten again.
<jdstrand> well, constantly is probably strong
<jdstrand> but this is the 3rd time
<jdstrand> :)
<bdrung> jdstrand: the third rewrite wasn't necessary, but i was curious about the result
<jdstrand> bdrung: ok. that seems reasonable I guess, but poke smoser about commenting on it
<bdrung> tumbleweed: can you comment bug #964008 regarding liblist-compare-perl?
<ubottu> Launchpad bug 964008 in distro-info (Ubuntu) "[MIR] distro-info, distro-info-data, and shunit2" [Undecided,In progress] https://launchpad.net/bugs/964008
<apw> slangasek, been using this one: https://launchpad.net/bugs/942846
<ubottu> Launchpad bug 942846 in linux (Ubuntu Precise) "encrypted install fails to boot as long as vt.handoff=7 is used" [High,In progress]
<apw> slangasek, if you have something that needs testing let me know ;)
<slangasek> apw: did you see the pastebinned patch?  I can push a bzr branch for it
<slangasek> my own testing here is waiting for the test system to be upgraded from oneiric
<slangasek> (I don't boot it very often :P)
<slangasek> apw: lp:~vorlon/ubuntu/precise/grub2/lp.942846
<slangasek> apw: though actually, I'm wondering why the reporter's machine should have ended up with =text... that should only happen if 1) the previous boot failed, 2) the 'hwmatch' command failed in grub, or 3) the card was in the blacklist, and the last should not be the case since he's using nouveau?
<slangasek> I think you're absolutely right that there's a bug here in our vt.handoff usage, I'm just not convinced fixing it will help this bug submitter
<slangasek> oh, maybe he has GRUB_GFXPAYLOAD_LINUX=text in his /e/defaults/grub
<slangasek> which means I have a bug in my patch as well, let's fix that
<slangasek> stgraber: how do graphics work/not work in containers?
<slangasek> stgraber: I'm considering /etc/init/udevtrigger.conf at the moment, which moved from an 'exec' to a 'script' for container support... and I'm pondering whether it can be switched back by dropping the 'container' condition, but want to be sure I understand the knock-on effects for other services
<slangasek> stgraber: we could make udev-fallback-graphics start immediately on 'container', or we could make it not run at all when in a container... I don't know which would be better
<infinity> roaksoax: Where's my feature freeze request for that maas upload with all the new features? :P
<infinity> roaksoax: (Your standing freeze exception was until Beta 2, and we're well past that now)
<roaksoax> infinity: heh, well i was told I have until FinalFreeze :)
<stgraber> slangasek: right, so the problem is that we don't have a separate device namespace yet, so the reason why we prevented udevtrigger from starting in a container is that if run, it'd re-trigger everything in all containers and outside the container, which we certainly don't want
<infinity> https://bugs.launchpad.net/ubuntu/+source/maas/+bug/937121 disagrees
<ubottu> Launchpad bug 937121 in maas (Ubuntu) "Standing feature freeze exception for maas in Precise" [Undecided,Triaged]
<stgraber> slangasek: but to answer your question, a container usually doesn't have direct access to graphic hardware
<infinity> roaksoax: And even if the bug didn't disagree, common sense probably does. :P
<roaksoax> infinity: well, could you please raise this issue with Daviey
<infinity> roaksoax: ...?
<roaksoax> infinity: the FFe only standing to Beta2
<infinity> It's right there...
<infinity> Agreed to by Francis even.
<roaksoax> infinity: yes I know, that's why I'm saying. Could you please raise it to Daviey ? Because, Daviey himself I can freely upload until Final Freeze
<slangasek> stgraber: so the bits that chain off of udevtrigger currently are udev-fallback-graphics, networking, cryptsetup, and, er, cups.  cups almost certainly needs fixed in that case to be 'or container' (or to just drop it completely).  Do you think we can generalize about the right thing to do with the others?
<stgraber> slangasek: in general 'or container' should be safe for these
<slangasek> stgraber: safe yes, but is it *correct*?  I don't want to change all of them if I don't have to :)
<stgraber> slangasek: it's unlikely we'll ever need udev-fallback-graphics or cryptsetup in a container but at the same time, if I want, I can make you a container using these, so it's not impossible someone would actually need these for something useful
<slangasek> stgraber: you would 'modprobe vesafb' in a container?
<slangasek> hmm, what's 'netscript-2.4-upstart'?
<slangasek> (archive-grepping)
<stgraber> slangasek: you can get 'modprobe vesafb' to work in a container but I really don't see a case where you'd want that job to trigger and where it'd be useful (didn't trigger outside of the container first)
<slangasek> right
<stgraber> slangasek: so you can probably keep that one as it's
<slangasek> stgraber: well, I guess the reason to *try* to run u-f-t in a container is that the DMs have a start condition that's udev-fallback-graphics, ORed with drm-device-added... and that's a udev event so would never be seen in the container, right?
<stgraber> currently containers see all events, so I could in theory allow a container access to a displaylink device, then plug it post-boot and the container will get that event and the container's udev will react on it
<stgraber> but as we don't re-trigger existing events, that only applies to devices appearing post-boot and only if the container is then allowed to access it (device cgroup restrictions)
<slangasek> and if the video device you're plugging in comes up as card0, which is not likely
<stgraber> indeed
<slangasek> ok, so I think u-f-g should be 'or container'
<stgraber> yeah, I think it's best to consistently have 'or container' so these weird people copy/pasting without reading will get it for sure and we won't get stuff not starting in container in later releases because of bad copy/paste :)
#ubuntu-devel 2012-04-05
<slangasek> stgraber: do you think this is important enough to have udev Breaks: the versions of the packages without 'or container'?  Since each of these are unlikely to usefully run in a container, I'm not convinced it's worth it
<slangasek> (and it's higher risk wrt upgrades)
<stgraber> slangasek: no, it's only really a problem when the container starts/restarts not a runtime problem, so just pushing them all at the same time so that they all are updated roughly at the same time should be enough
<slangasek> apw: have confirmed this grub patch DTRT; though on my radeon test machine, I still get garbled fb after handoff
<infinity> No command 'vim' found, did you mean:
<infinity>  Command 'vmm' from package 'vmware-manager' (multiverse)
<infinity>  Command 'zim' from package 'zim' (universe)
<infinity> ...
<infinity> You'd think it would suggest, I dunno, 'vim' from package 'vim'?
<infinity> Oh, but it's an alternative. :/
<infinity> Annoying.
<nigelb> heh
<sladen> infinity: launchpad.net/ubuntu/+source/command-not-found/+filebug?field.title=command-not-found+does+not+suggest+vim+because+it+is+an+alternative
<nigelb> so much troll on the fedora for arm lwn article.
<nigelb> well, I was reading the comments. so I am to be blamed :)
<ajmitch> nigelb: I hope you're not trolling there as well
<nigelb> ajmitch: er, no. I only made the mistake of reading the comments
<ajmitch> sure...
<ScottK> jelmer: Are you planning on an FFe for dulwich 0.8.5 so bzr-git can build?
<smoser> kenvandine, http://paste.ubuntu.com/915581/
<smoser> it seems you inadvertantly regressed the fix i put in for bug 762167
<ubottu> Launchpad bug 762167 in light-themes (Ubuntu) "missing dependency on gtk2-engines-pixbuf" [Low,Fix released] https://launchpad.net/bugs/762167
<Adri2000> hmm, has the archive gpg key really not changed since 2004?
<Adri2000> debian renews its key regularly and now has a 4096R one, while we still have a 1024D it seems. is that something that has already been discussed somewhere?
<infinity> Adri2000: It's been discussed, yeah.
<Adri2000> infinity: and? :)
<dholbach> good morning
<infinity> Adri2000: We know we need to rev to a new key at some point and test that our migration is sane, etc.  We don't have a specific timetable for when.
<smb> @crashpilot in
<udevbot> Error: "crashpilot" is not a valid command.
<smb> Sadly the truth does not work... :-P
<smb> @pilot in
* udevbot changed the topic of #ubuntu-devel to: 12.04 Beta 2 Released! Precise: UI and feature freeze | Dev' of Ubuntu (not support or app devel) | build failures -> http://bit.ly/HaWdtw | #ubuntu for support and general discussion for hardy -> oneiric | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: smb
<Adri2000> infinity: ok
<apw> slangasek, see your branch.  not sure this does quite the same thing.  as if i am at the boot prompt and i edit the gru
<apw> slangasek, grub entry and switch the gfxpayload value i won't influence the value of vt_handoff -- of course thats no worse than now where one has to drop it from both places to be sure anyhow
<tumbleweed> bdrung: done
<cjwatson> slangasek: the debian-cd bit is public; https://code.launchpad.net/~ubuntu-cdimage/debian-cd/ubuntu
<cjwatson> slangasek: not that you'd want to use it for self-builds - easier to use lb config --binary-images iso-hybrid or similar
<cjwatson> apw: I don't think it's necessary to solve the case of editing it by hand at the boot prompt
<apw> cjwatson, indeed, though inspired by his patch i think i have a nice clean fix which does
<cjwatson> I'll have a look when y'all settle down :)
<apw> cjwatson, should have a branch shortly for perusal :)  i hate hate hate quilt
<cjwatson> oh believe me it's better than what we were using beforehand
<cjwatson> I switched grub2 to quilt because it made it about three times faster to refresh patches against new upstream versions
<apw> cjwatson, i don't doubt it :)  i still _always_ use it wrong and eat my tree
<cjwatson> but honestly if you're going to be spending time fighting with it, I'd rather you just attached a bare patch and let me worry about integrating it
<cjwatson> better use of time all round
<apw> cjwatson, well its also good practice :)  if i fail in half an hour i'll send it to you :)
<nailora> bug #955848 -- can one of you make it public if possible? thanks!
<ubottu> Error: Launchpad bug 955848 could not be found
<cjwatson> nailora: is this a bug you're subscribed to, or that you reported?
<cjwatson> nailora: if not, please give reasons
<cjwatson> nailora: if so, you can just make it public yourself
<nailora> i am sorting simple-scan bugs at a the moment. mostly those of the upstream launchpad project, but as most bugs are reported via ubuntu, i look through those as well. however some of them are private. i get to know about them if another public bug is marked as duplicate of the private bug. i suspect there are quite some more bugs i do not even know about.
<nailora> i do not have any special rights with respect to the ubuntu project in launchpad.
<cjwatson> nailora: I'm not sure I'm prepared to unprivate a simple-scan bug you didn't report, because I have no way to know whether e.g. it might be reverse-engineerable into bits of a private document somebody was scanning
<cjwatson> that's the kind of reason why crash reports are private, because it's easy for bits of a dead process to contain confidential information
<cjwatson> somebody who's a specialist in simple-scan can probably sort it out, but I don't think random developers can
<cjwatson> nailora: if you join ubuntu-bugcontrol (https://wiki.ubuntu.com/UbuntuBugControl) then you can see crash bugs
<nailora> i understand that. but in the past (public) reports against simple-scan in ubuntu have been left without reponse for years (!), and i suspect this is even more true for private bug reports.
<cjwatson> ok, you're certainly welcome to sign up for ubuntu-bugcontrol and DIY, I just don't feel comfortable doing it for you in this case
<apw> cjwatson, ok in http://people.canonical.com/~apw/lp942846-grub2-precise/ are two files, 10_linux which is the 'finished' applied version, and a debdiff which in theory at least applies to make the same
<apw> cjwatson, and if i picked the right base, this is it applied: lp:~apw/ubuntu/precise/grub2/lp942846
<cjwatson> the change to ubuntu_recovery_nomodeset.patch looks wrong, but I can clean that up
<apw> cjwatson, oh what did i do wrong there ...
<cjwatson> looks like you did quilt refresh after a previous version of the change, and then went back and cleaned up but didn't quilt refresh your way up the stack
<cjwatson> lp:~apw/ubuntu/precise/grub2/lp942846 looks like something entirely different
<cjwatson> the top change is "grep refuses to process files which are also its stdout channel
<cjwatson> which prevents the password check from working and emits an ugly error.
<cjwatson> (LP: #911225)"
<cjwatson> pushed the wrong branch?
<apw> cjwatson, that is the previous commit, and i did push, then commit and push again, so i think that is LP lag ... grrr
<lag> apw always blames lag :(
<cjwatson> normally if it's LP lag there's a message saying that new versions will be available shortly
<cjwatson> in any case why would the base be that revision of yours?  that was ages ago
 * lag changes his name to lp_is_working_perfectly
<apw> cjwatson, i have lost the plot entirely somewhere ... bzr is doing something i cannot fathom
<cjwatson> oh, there we go, there's a message now
<bdrung> tumbleweed: thanks. can you upload it as 0.8.2 or should i do that?
<apw> cjwatson, i rm -rf'd a grub2/precise directory then branched a new one, and pushed to that name above, when i push it pushes to some other saved place, where it gets that i have no idea
<cjwatson> apw: nope, base for this is completely wrong
<cjwatson> not that that means I couldn't merge, but I think it'd be easier to go off the debdiff perhaps
<apw> bah i am a lost cause
<cjwatson> you can see in https://code.launchpad.net/~apw/ubuntu/precise/grub2/lp942846
<cjwatson> or by 'bzr log' locally
<apw> bzr branch lp:ubuntu/precise/grub2 was in theory waht i used to get it
<cjwatson> ah, er, yeah, don't do that
<cjwatson> see Vcs-Bzr in 'apt-cache showsrc grub2' for the real branch
<cjwatson> lp:~ubuntu-core-dev/ubuntu/precise/grub2/precise
<cjwatson> I think I was having trouble with the importer
<cjwatson> then again, this branch is not based on lp:ubuntu/precise/grub2 either, just based on what the log says
<cjwatson> no idea what you did :)
 * apw cries
<infinity> Poor apw.
<cjwatson> I'm happy to just work off the debdiff if you want
<infinity> Need me to import grub into git for you, so you can figure it out? ;)
<cjwatson> nooooo
<apw> cjwatson, that might be easier :)
<nailora> i will consider joining ubuntu-bugcontrol. i am unhappy with the situation because 99% percent of private bugs with simple-scan are mere cries for help from clueless users switching from windows suffering from crappy drivers. no bug reports should be created and certainly no private ones... nobody will look at the trace and the best thing for everyone is a timely "let me google that for you" or "sorry, we cant change
<cjwatson> apw: ok, let's see
<nailora> i understand that the situation is different for bugs where some engineering is to be done. but this is more first level support where apport made it to easy to file a bug report.
<tumbleweed> bdrung: sure, will upload
<raffa50> hello
<raffa50> i'm triying to add my mime type to ubuntu
<raffa50> i'm pacaging the .deb for my app
<raffa50> where i shoud insert xdg-mime i/src/sly.xml ?
<raffa50> in rules ? where?
<cjwatson> nailora: the crash reporting system is being reengineered to make these kinds of things reports in a separate crash reporting system that can be looked at statistically, rather than bug reports
<directhex> raffa50, man dh_installmime
<cjwatson> we don't have the resources to look at every crash bug individually, and aren't going to have, so it does need a different presentation
<cjwatson> the business of reporting crashes as bugs straight off was only ever intended to be temporary
<cjwatson> https://blueprints.launchpad.net/ubuntu/+spec/foundations-p-crash-database
<smb> @pilot out
* udevbot changed the topic of #ubuntu-devel to: 12.04 Beta 2 Released! Precise: UI and feature freeze | Dev' of Ubuntu (not support or app devel) | build failures -> http://bit.ly/HaWdtw | #ubuntu for support and general discussion for hardy -> oneiric | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<nailora> cjwatson: that might improve the situation
<raffa50> man dh_installmime ????????? where is?
<cjwatson> raffa50: the debhelper package; and please only use one question mark at a time, we don't need nine in a row :-)
<raffa50> can't understand
<apw> cjwatson, i had better re-test this applied version after all these fubars ...  if you push up your applied version i can make sure its right
<raffa50> i extracted .dev
<raffa50> deb
<raffa50> and i opened ruler file
<raffa50> rules
<raffa50> in debian foder
<cjwatson> apw: oh, my comment about ubuntu_recovery_modeset.patch was wrong, sorry, I misread the two levels of patch
<raffa50> now where i must place xdg-mime /src/sly.xml for istalliong
<raffa50> my mine
<directhex> raffa50, "man" is the command to view a manual page. dh_installmime is the command to set up mime types in packages. so <directhex> raffa50, man dh_installmime
<directhex> i.e. if you're manually writing xdg-mime anywhere you're doing things terribly terribly wrong
<cjwatson> mm, xdg-mime uses a different file format from dh_installmime
<cjwatson> no package on my system appears to use xdg-mime at all
<directhex> cjwatson, glorious
<raffa50> i asked aroud
<raffa50> they sayd to add mime in that way
<apw> cjwatson, heh well thats something
<directhex> sigh
<directhex> raffa50, have you read that manual page yet?
<raffa50> yes
<raffa50> but now i'm confused
<raffa50> i wrote an xml
<raffa50> and now what i must do? (sorry i'm italian and only 18)
<directhex> http://wiki.debian.org/MimeTypesSupport
<directhex> i don't have time for the clearly required level of hand holding. you may have better luck in #ubuntu-motu
<cjwatson> directhex: oh, I see, these XML files live in .sharedmimeinfo
<cjwatson> that makes a degree of sense, at least
<cjwatson> raffa50: so put your XML file in debian/YOURPACKAGENAME.sharedmimeinfo, replacing YOURPACKAGENAME with ... your package name
<raffa50> ah
<raffa50> and then?
<cjwatson> raffa50: if you're using sensible modern packaging with dh, then that's all you need
<raffa50> ?
<cjwatson> raffa50: otherwise, you need to call dh_installmime in your binary-arch or binary-indep target in debian/rules as appropriate (there are probably a bunch of other dh_installblah things there already)
<raffa50> i did as you sayd
<raffa50> i placed
<raffa50> my xml
<raffa50> in debian
<raffa50> now it's name is sly.sharedmimeinfo
<raffa50> i need to do other things?
<cjwatson> post debian/rules to http://paste.ubuntu.com/
<raffa50> http://paste.ubuntu.com/915787/
<cjwatson> raffa50: add 'dh_installmime -i' after the line that says 'dh_installmenu'.  The line with 'dh_installmime -i' on it *must* start with a real tab character, just like the other lines around it.
<raffa50> ok
<raffa50> ki try
<raffa50> dpkg-buildpackage -S -sa -kE05C9204 is the command to build right??
<raffa50> istalled
<raffa50> don't work
<raffa50> http://paste.ubuntu.com/915799/
<raffa50> first row is <?xml version="1.0" encoding="utf-8"?>
<cjwatson> raffa50: that builds a source package, not a binary package ...
<cjwatson> 'debuild -uc -us' builds binary packages
<raffa50> ok
<raffa50> i'm noob, but my project is big: Sly IDE for beginners
<raffa50> now it builded .deb'
<raffa50> ? i try again
<raffa50> nothing again
<raffa50> is my xml correct? http://paste.ubuntu.com/915799/
<raffa50> in the first row i missed ? because pastebin doesn't allow it
<raffa50> there is anyone??? yhuuhuuuuu?
<apw> cjwatson, ahh thanks, will re-test it after all that dammage
<directhex> raffa50, run "dpkg -I yourpackage.deb postinst"
<directhex> and pastebin the result
<cjwatson> apw: looks like it should be fine; I have one or two other things I want to sort out, so either feel free to test from the branch, or I'll go through it once I'm ready
<apw> cjwatson, i will test this bit from the branch indeed
<cjwatson> apw: or I can build binaries for you if you're still having trouble getting the right branch
<apw> cjwatson, nope incompentance over, i see your clean tip with the extra change
<cjwatson> 'k, cool
<apw> cjwatson, glad at least the debdiff was right even if i was based in space
<bdrung> tumbleweed: fyi: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=667614
<ubottu> Debian bug 667614 in lintian "lintian: Please query distro-info for getting a valid list of Debian/Ubuntu distributions" [Minor,Open]
<tumbleweed> bdrung: yeah, I saw some of the IRC discussion on that
<bdrung> tumbleweed: you may come up with a patch (you are a better perl hacker than me)
<tumbleweed> heh
<raffa50> http://paste.ubuntu.com/915850/
<apw> cjwatson, ok in my testing that seems to behave as i would expect, this should give those psb people something to switch which will work
<cjwatson> apw: great - I'll upload that later today.  I'll also look at making this automatic in the encrypted-/usr case
<apw> cjwatson, what was it thats on / that breaks graphics?  given all of /boot is not encrypted ?
<apw> cjwatson, as slangasek was saying it worked fine for him which was confusing
<cjwatson> apw: /usr/share/grub/unicode.pf2 is big and isn't copied to /boot/
<cjwatson> see 'if loadfont /usr/share/grub/unicode.pf2' in grub.cfg
<apw> yep ... makes sense.  so yes in that case off sounds good by default
<apw> cjwatson, and i need to get whoever has the psb stuff to get their ids added to the blacklist
<cjwatson> it is possible to manually copy unicode.pf2 to /boot/grub/, and maybe slangasek had done that
<raffa50> help please
<raffa50> http://paste.ubuntu.com/915850/
<raffa50> no way
<raffa50> help me please
<raffa50> there isn't an example?
 * ogra_ wonders if anyone knows a more elegant way to apply arch specific quilt patches to a package than what i do in http://paste.ubuntu.com/915905/
<cjwatson> ogra_: why can't it be ifdeffed and thus just applied for all architectures?
<ogra_> cjwatson, because it changes stuff that cant easily be ifdeffed ... (long story) ... the patch bneeds to be arch specific in this caswe
<ogra_> *case
<ogra_> (it changes the API of some core functions afaik, i'm only the patch delivery guy here)
<ogra_> cjwatson, do you know a more elegant way than mangling the series file ?
<cjwatson> ogra_: I don't
<ogra_> k
<ogra_> i was hoping for some quilt magic i dont know about :(
<cjwatson> although the approach in that pastebin is bad, because it will repeatedly append the arch-specific entries on repeated builds
<ogra_> right
<cjwatson> ogra_: a slightly neater approach might be to have a separate directory for the arch-specific patches, and call quilt twice setting QUILT_PATCHES the second time
<cjwatson> ogra_: or, actually, you don't need a separate directory; you could set QUILT_SERIES=series.$(ARCH)
<cjwatson> you ought to override dh_quilt_unpatch as well
<raffa50> cjwatson: help me don't work
<cjwatson> raffa50: sorry, I can't
<raffa50> :(
<cjwatson> raffa50: I have too many other things to do and you aren't providing any useful information about how it doesn't work
<raffa50> no .deb examples
<ogra_> cjwatson, yeah, thats just for testing the functionality yet
<raffa50> ?
<ogra_> indeed upatch will get aqn override too
<ogra_> *an
<ogra_> *unpatch *sigh*
 * ogra_ goes to look at QUILT_SERIES ... didnt notice that one yet
<raffa50> what shoud i do now?
<cjwatson> perhaps you should write up your question in detail and post it somewhere else, such as askubuntu.com or some appropriate mailing list
<cjwatson> somewhere that's more focused on application developers
<raffa50> i asked on italian forum
<cjwatson> apw: actually, I'm going to skip any changes to the 'if loadfont' path - experimentation suggests that this may be hardware-specific, i.e. it will at least sometimes manage to enable gfxterm anyway even if gfxmode hasn't been explicitly set beforehand
<raffa50> oki
<raffa50> i asked
<cjwatson> apw: I think the only sensible approach long-term is to write a new command that exits zero iff a video mode is active, but I don't want to attempt that for precise really
<apw> cjwatson, yeah that would be nice if we could do it, but as you say that is a Q job
<apw> cjwatson, could you gate it on the existance of that font file for the time being?
<cjwatson> no, because that's actually not correct
<cjwatson> I did some tests here and got a video mode even without loading a font or setting gfxmode
<apw> gurgle
<cjwatson> just with a rescue CD image produced using grub-mkrescue, in kvm
<cjwatson> so something else is going on, and I don't want to make a random change without understanding what :)
 * cjwatson uploads what he has so far
<apw> cjwatson, fair indeed.  well i guess for now we can just leave things as they are perhaps?  and where its known to explode with a specific card we just get those in the blacklist, and if its else they have to do it by hand
<apw> at least now they can use the /etc/default/grub variables to turn it off properly
<raffa50> where can i find a .deb example that adds mime?
<cjwatson> raffa50: the following packages on my system appear to register MIME entries using the system we recommended: apport brasero-common capplets-data fontforge gnome-keyring gramps libreoffice-common nautilus-data shared-mime-info software-properties-gtk tomboy vinagre
<cjwatson> raffa50: so you can 'apt-get source' any of those and inspect them
<cjwatson> apw: provisionally that seems reasonable; I guess we'll see
<raffa50> thanks
<raffa50> when i done
<raffa50> apt-get source
<raffa50> tomboy
<raffa50> what foder i should open?
<raffa50> ls
<raffa50> found
<ogra_> hmpf, so it seems compiz does completely ignore the patch target during build, it inly applies them on unpack :/
<ogra_> *only
<ogra_> (which means that debian/rules doesnt apply indeed ... sigh)
<kenvandine> smoser, sorry i should have noticed that
<kenvandine> smoser, i'll fix it and merge it into the packaging branch
<raffa50> i made some thing
<raffa50> now it says
<raffa50> Tipo application/x-sly
<raffa50> impossible to find application for opening type application/x-sly
<mhall119> dholbach: ping
<dholbach> mhall119, pong
<mhall119> dholbach: https://bugs.launchpad.net/ubuntu/+source/thunderbird/+bug/973394 contains a patch to add Keywords to thunderbird.desktop
<ubottu> Launchpad bug 973394 in thunderbird (Ubuntu Precise) "Typing email into dash gives no results. " [Low,Triaged]
<mhall119> specifically so that a Dash search for "Email" will contain Thunderbird
<mhall119> it's recently been highlighted as something needed for 12.04 in http://www.linuxuser.co.uk/opinion/5-problems-with-ubuntu-12-04-part-1-unity-dash-usability-issues/
<dholbach> nice
<dholbach> chrisccoulson, ^ did you see this one?
<dholbach> mhall119, it seems to be milestoned for precise
<chrisccoulson> dholbach, yeah, it's already fixed in the nightly builds
<mhall119> chrisccoulson: awesome, thanks!
<ogra_> sigh, i wonder if its not easier to just ignore quilt and just use patch conditionally
<hallyn> tjaalton: ok i can't personally list any improvements with the new qxl driver so I can't recommend pushing it (if you haven't already) unless Munzir chimes in
<hallyn> tjaalton: apparently spice updates in debian are slow in coming because of fights over what to do with celt
<hallyn> might have to do something in 12.10 (like do our own updates)
<ogra_> seems if i use quilt here, it still uses the .pc directory which messes up all my overrides
<Laney> you probably can't do stuff like that with 3.0 (quilt), at least not nicely
<ogra_> yeah, just finding that out
<ogra_> i guess i'll just go with a simple "patch -p0 <debian/patches/my_extra_patch.patch" in debian/rules or some such
<Laney> make sure to reverse it in clean too
<ogra_> indeed
<ogra_> intrestingly not even the suggestion from cjwatson above to just set the QUILT_ vars differently seem to help ... seems the .pc metadata is set in stone at this point
<jml> :(
<jml> the phsical 't' ke on m keboard (letter between 'x' and 'z' in dvorak) is being mapped to the Hiragana-Katanana ke
<Laney> there might be $QUILT_PC
<ogra_> oh, wait ! it might help if the package actually used dh --with quilt $@ instead of just dh $@
 * ogra_ slaps forehead
<tjaalton> hallyn: that's ok, let's keep what we have now :)
<tjaalton> it's very simple to backport if someone needs it
<hallyn> ack that :)
<smoser> slangasek, SpamapS bug 974284 raised in openstack-dev
<ubottu> Launchpad bug 974284 in ifupdown (Ubuntu) "invoking dhclient3 with -1 causes issue if no dhcp server available" [Undecided,New] https://launchpad.net/bugs/974284
<SpamapS> smoser: interesting
<smoser> the power fail scenario does seem valid.
<Adri2000> in a default amd64 precise install, can I disable dpkg's "foreign-archicture i386" without any problem? or is it going to break things (I'm thinking of stuff like flash)?
<Adri2000> or do I need to add i386 to my local mirror? :s
<cjwatson> it'd break flash, yes; but you can use "deb [arch=amd64] http://mirror/ubuntu precise main" or similar if you need to have sources.list lines with non-default architecture sets
<Adri2000> cjwatson: after testing looks like flash is ok, but stuff like acroread, needing ia32-libs-multiarch and nspluginviewer aren't...
<Adri2000> well I guess I'll have to choose: proprietary stuff, or more hard disk for my mirror :)
<cjwatson> I gave you an option that didn't involve changing your mirror
<cjwatson> assuming you don't mind downloading a small amount of stuff directly from the primary archive
<Adri2000> I tried, but it has the same effect as changing dpkg conf: ia32-libs-multiarch and nspluginviewer are still unavailable
<Adri2000> yeah, I'd have to keep archive.ubuntu.com in sources.list
<cjwatson> yes, you would
<Adri2000> I see. that won't work for my specific case (should not go directly to outside repositories), but good to know anyway
<slangasek> cjwatson: oh hah, did I manually copy unicode.pf2?  That's possible, I remember something along those lines :/  but I thought grub itself had code to do that copy when needed
<cjwatson> maybe we did once and took it out 'cos it was giant
<cjwatson> I forget :)
<slangasek> apw: so keying off of gfxpayload directly, then?  That makes sense to me
<cjwatson> anyway, I think we've since established that there are other ways you might get a graphical mode
<slangasek> ok
<apw> slangasek, yeah that the hope.  and if you change gfxmode $foo to gfxmode text everything naturally follows
<ogra_> slangasek, wrt the compiz patches, the prob with them is that all i can get is a diff between two bzr branches ... sadly the package has additional quilt patches in debia/patches that touch the same files in some areas so its not just apply and go, i'm trying to work out a better plan with linaro to go forward with that atm
<mpt> ev, reported bug 974428
<ubottu> Launchpad bug 974428 in apport (Ubuntu) "Nautilus error inappropriately shown as "internal error"" [Undecided,New] https://launchpad.net/bugs/974428
<ev> cheers
<smoser> slangasek, i'd really appreciate your brain power on https://bugs.launchpad.net/ubuntu/+source/ifupdown/+bug/974284
<ubottu> Launchpad bug 974284 in ifupdown (Ubuntu) "invoking dhclient3 with -1 causes issue if no dhcp server available" [Undecided,New]
<slangasek> smoser: hmm, had seen your follow-up to bug #838968 this morning in connection with this, and am at the moment still confused
<ubottu> Launchpad bug 838968 in ifupdown (Ubuntu) "static-network-up event does not wait for interfaces to have an address" [High,Fix released] https://launchpad.net/bugs/838968
<slangasek> in part because I thought we'd put that issue to bed :)
<smoser> well, we did a good job on boot.
<smoser> (i think)
<smoser> but apparently negatively affected reliability
<smoser> and the most recent comment there is most damaging.
<slangasek> ah, I see there
<slangasek> I think I would argue that dhclient needs to be modified to give us the behavior we want
<slangasek> stgraber: ^^ what do you think?
<stgraber> yeah, I saw smoser's bug but am not too sure what to do here... assuming the interface is configured when dhclient returns is wrong unless we have -1 but if we call with -1 then it's possible you don't get your IP if the DHCP server was unavailable
<stgraber> our current behaviour is identical to d-i and network-manager's behaviour, if you don't get an IP from DHCP within $TIMEOUT, it fails
<smoser> the one thought i had....
<smoser> most of the time the original 60 second timeout was enough
<smoser> we bumpted that to 5 minutes
<slangasek> stgraber: have posted a couple thoughts on the bug
<slangasek> (and assigned to you)
<smoser> i *think* that dhclient didn't background until that 5 minutes was up.
<smoser> err. that timeout.
<slangasek> smoser: I believe that's correct
<smoser> if thats the case, then we're in a much better position if we revert the '-1' flag.
<slangasek> er, oh
<slangasek> sorry, no, it should background as soon as it gets a lease
<slangasek> I misread
<smoser> ie, ifup will much more often exit with the correct exit value (0 on success).
<smoser> slangasek, oh. well thats good enough.
<slangasek> if it hits the timeout without getting a lease, it exits non-zero, and the interface is marked as down
<smoser> wel... anywah.
<smoser> i'll lave you to think about it.
<slangasek> if it gets a lease, it backgrounds immediately and the parent process exits 0
<smoser> right, which really is "success"
<smoser> so thats fine.
<smoser> i lagely agree with the comment in the bug slangasek
<smoser> but i think ideally we'd also still background on timeout failure
<smoser> initial timeout.
<smoser> ie, to safeguard for the power failure case, where 5 minutes wasn't enough, but 5 minutes and 3 seconds would have been.
<stgraber> so we want dhclient to try for $TIMEOUT, if it gets a lease during that time, background itself and get into a renewal/retry loop, if it doesn't, then ???
<stgraber> for ??? I tend to prefer failing as I really don't want to run the ifupdown hooks unless we have a working connection
<stgraber> but you clearly prefer continuing regardless that'll make all the upstart jobs trigger as well as all upstart hooks (even though you don't have network access)
<doko> bryceh, ping
<stgraber> slangasek: commented in the bug. I scanned through all the existing options and no combination of these that are documented will do what we want, so we need to implement a new option
<slangasek> stgraber: is it wrong to change the behavior of -1?
<slangasek> the fact that dhclient -1 backgrounds and sticks around after getting a lease is already contrary to the obvious meaning of the option
<slangasek> so extending it to also retry on failure once backgrounded would also seem ok to me?
<slangasek> (NM doesn't appear to use -1, so no issues there)
<stgraber> slangasek: I think it might be a problem if something like Network Manager (bad example, it doesn't use it, just checked) expects "dhclient -1" to exit on failure to renew as a way of monitoring it
<slangasek> :)
<slangasek> so, what else besides NM would we need to worry about here?
<slangasek> d-i doesn't monitor either
<stgraber> netcfg
<stgraber> ah, I thought it was calling with -1
<slangasek> it does, but it also doesn't monitor
<slangasek> I think in general anything that's going to monitor for lease renewal failures is going to *not* use -1
<slangasek> because if it's smart enough to monitor, it doesn't need the -1, does it?
<slangasek> oh, maybe -1 is the only way dhclient does any error reporting at all :P
<stgraber> indeed, you shouldn't need -1 if you monitor (using -sf)
<smoser> ok. i have a stupid question. (not uncommon)
<smoser> wget http://us.archive.ubuntu.com/ubuntu/dists/precise/main/installer-i386/current/images/MD5SUMS.gpg
<smoser> wget http://us.archive.ubuntu.com/ubuntu/dists/precise/main/installer-i386/current/images/MD5SUMS
<smoser> gpg  --keyring=/usr/share/keyrings/ubuntu-archive-keyring.gpg --verify MD5SUMS.gpg  MD5SUMS
<smoser> 2 questions
<smoser> a.) is there a better way to know the keyring to use there?
<smoser> b.) when you do that it says: WARNING: This key is not certified with a trusted signature!
<mdeslaur> smoser: why don't you just use the keyring that's in ubuntu-keyring?
<smoser> is that not what i'm doing ?
<mdeslaur> oh wait, I'm misreading :)
<mdeslaur> duh, sorry
<slangasek> smoser: a) no, b) the warning should be ignored
<smoser> slangasek, gracias.
<slangasek> smoser: to expand: the reason you can trust the key is because you have it installed via the ubuntu-keyring package, which uses its own trust path through the Ubuntu archive; so this makes the warning ignorable, but also means it's the only trust path most people have to the key, so you can't just fetch the key from a keyserver for verification
<smoser> right.
<SpamapS> slangasek: so, what do we do about myodbc?
<SpamapS> slangasek: its the last rdep on libmysqlclient16
<slangasek> SpamapS: hmm, in Ubuntu or Debian?  The version of myodbc in experimental should be syncable and work in precise, provided there's an adequate version of mysql-5.5 there
<arges_> Who is the patch pilot today?
<slangasek> I would look it up, but I can never remember the name of the wiki page
<SpamapS> slangasek: ah so perhaps just a sync then? I'll try a test build.
<slangasek> because it doesn't contain the words "patch" or "pilot"
<slangasek> SpamapS: yeah, I would say a sync is best
<slangasek> ah, CodeReview*s*
<slangasek> (and there's now a PatchPilot redirect, goody :)
<slangasek> cnd: are you patch piloting today?
<psusi> why is there no bzr branch for mdadm?
<slangasek> psusi: see http://package-import.ubuntu.com/status/ for the failure
<ogra_> hmm, did debootstrap recently start to set the default locale to en_US.UTF-8 ?
 * ogra_ gets locale warnings inside a fresh chroot where i'm chrooted with LANG=C ... 
<slangasek> ogra_: not that I'm aware of
<ogra_> weird
<psusi> slangasek: so it's a bug in bzr?
<slangasek> it's a bug in the package importer
<slangasek> I don't know if it's a bug in bzr per se
<psusi> slangasek: so I should file a bug against udd?
<SpamapS> slangasek: test rebuild worked, smoke test worked.. myodbc synced
<slangasek> psusi: you can, though I would note that this is unlikely to get actioned very quickly... if you care about seeing this fixed any time soon, you probably have to roll up your sleeves
<slangasek> SpamapS: woohoo
<SpamapS> I *think* thats the last actual mysql 5.1 deps now
<SpamapS> everything left is just suggests
<slangasek> cjwatson, apw: for reference, I do see a comment in the changelog, from 2009, about copying unicode.pf2 to /boot; so I presume that's how I have it :)
<SpamapS> crap.. akonadi-backend-mysql
<slangasek> heh
<SpamapS> no
<SpamapS> strike that
<SpamapS> local version
 * SpamapS needs to run these rdepends in a chroot
<SpamapS> argh
<stgraber> smoser: hmm, can you confirm that when running dhcp without -1 that when the lease expires and dhclient can't renew it doesn't exit and instead retries indefinitely?
<smoser> stgraber, i honestly do not know.
<stgraber> smoser: because I can't find any code doing that in isc-dhcp, the code path with or without -1 seems identical when it comes to renewal
<smoser> so you think it would have failed all the same for the bug opener
<smoser> regardless of the -1
<stgraber> looking at the code, it should, yeah
<stgraber> Â»Â·Â·Â·if (interval > client -> config -> timeout) {
<stgraber> Â»Â·Â·Â·Â»Â·Â·Â·state_panic (client);
<stgraber> Â»Â·Â·Â·Â»Â·Â·Â·return;
<stgraber> Â»Â·Â·Â·}
<smoser> i cannot ocnfirm that.
<smoser> or deny
<stgraber> that code is all the code paths I could find, so when dhclient can't renew, it tries again for $TIMEOUT (5 minutes in our case), then that if matches and dhclient exits with an error message in syslog
<stgraber> smoser: I'll run another test here to confirm that I get the same behaviour without -1
<smoser> stgraber, and it takes down the iP ?
<stgraber> yes
<stgraber> correct behaviour considering it's expired and can get allocated to another client by the server
<stgraber> (when it gets back to life)
<SpamapS> jdstrand: https://bugs.launchpad.net/ubuntu/+source/lemonpos/+bug/894377 .. mysql-5.1 is safe to remove now :)
<ubottu> Launchpad bug 894377 in mysql-5.1 (Ubuntu Precise) "mysql-server-5.1is deprecated for mysql-server-5.5 in precise, should be removed once transition is complete" [High,Triaged]
<jdstrand> SpamapS: ack, thanks
<jjohansen> stgraber: so I have hardware to help debug the web cam bug in Bug #966294
<ubottu> Launchpad bug 966294 in ubiquity (Ubuntu Precise) "Ubiquity loops forever from ubiquity_webcam_play" [High,Confirmed] https://launchpad.net/bugs/966294
<stgraber> jjohansen: cool, I currently have ssh access to gema's netbook for testing
<stgraber> jjohansen: can you confirm that "gst-launch-0.10 v4l2src ! video/x-raw-rgb,width=640,height=480 ! ffmpegcolorspace ! xvimagesink" works on that machine?
<stgraber> it's a bit dark at gema's place at the moment ;) so hard to tell if I'm getting a black/broken input or if it's actually working :)
<jjohansen> stgraber: yes it works
<jdstrand> SpamapS: mythtv has build deps on libmysqlclient16-dev | libmysqlclient15-dev
<jdstrand> SpamapS: I added a task to the bug
<micahg> superm1: ^^
<jdstrand> superm1: fyi 894377
<jdstrand> superm1: also fyi, libmysqlclient16-dev is listed twice as a build dep
<stgraber> jjohansen: ok, I'm starting to downgrade packages to pinpoint when it broke, I might poke you again for more tests soon
<jjohansen> stgraber: sure
<stgraber> jjohansen: do you remember seeing that screen when installing Oneiric?
<jjohansen> stgraber: yep, it worked did it this morning
<stgraber> cool, thanks, that's useful to confirm ;)
<superm1> jdstrand: mythtv has build depends on either so that the same source can be built on lucid->precise
<superm1> we build on the daily PPA using the same source package
<jdstrand> superm1: that is fine-- I'm saying that libmysqlclient16-dev is listed on its own and as part of libmysqlclient16-dev | libmysqlclient15-dev (check the control file)
<superm1> jdstrand: ohh i see
<jdstrand> superm1: problem is, libmysqlclient16-dev is going away in precise. see bug #894377
<superm1> will fix it for next upload
<ubottu> Launchpad bug 894377 in mysql-5.1 (Ubuntu Precise) "mysql-server-5.1is deprecated for mysql-server-5.5 in precise, should be removed once transition is complete" [High,Triaged] https://launchpad.net/bugs/894377
<jdstrand> superm1: can you adjust it to also have libmysqlclient-dev in there?
<superm1> jdstrand: sure
<jdstrand> superm1: awesome-- that should fix the bug
<jdstrand> superm1: thanks!
<superm1> planning next upload to be start of next weekish (right before FF), is that ok, or do you need it fixed sooner so the archive can adjust?
<jdstrand> I'll let SpamapS comment ^
<jdstrand> this is all universe stuff, so it shouldn't really matter
<chrisccoulson> is there an archive admin who can process bug 971525 for me, please :-)
<ubottu> Launchpad bug 971525 in esteid-browser-plugin (Ubuntu Precise) "Please remove esteid-browser-plugin from the archive urgently, as it trashes our Firefox package (was firefox-locale-fi: User Interface completely in English)" [High,Triaged] https://launchpad.net/bugs/971525
<micahg> chrisccoulson: that one wasn't from Debian, Q-FUNK uploaded it
<chrisccoulson> really?
<chrisccoulson> that sucks
<micahg> yeah, I complained at the time
<chrisccoulson> it still needs to go
<micahg> and I thought you said it was fine :)
<chrisccoulson> i was never asked about this
<stgraber> jjohansen: did you try with i386 or amd64?
<chrisccoulson> urgh, no, this isn't. i've never looked at this in my life
<chrisccoulson> i looked at some spice plugin
<chrisccoulson> but not this
<jjohansen> stgraber: amd64
<chrisccoulson> nobody has ever asked me about this extension
<micahg> I will scream louder next time ;(
<jjohansen> do you want me to reinstall and try i386?
<jjohansen> stgraber: ^
<stgraber> jjohansen: I currently don't have any reason to suspect the architecture to impact it but I see that only one of the duplicates was on i386, everything else was amd64
<stgraber> jjohansen: btw, apparently downgrading libgstreamer0.10-0 to oneiric's version, does the trick on that system, now triple-checking this and I'll try to pinpoint a specific part of the library as the changelog is unfortunately huge
<stgraber> jjohansen: so yeah, if you don't care about that system and have a few minutes, testing i386 would be interesting, if only just to confirm that it's not architecture specific
<jjohansen> stgraber: okay, will do
<Q-FUNK> seb128: deleting a package from the archive just like that is not appreciated at all.
<Q-FUNK> chrisccoulson: and if there's a problem with a particulat plug-in, file a bug, rather than acting like you did.
<micahg> Q-FUNK: it never should've been uploaded in the first place
<chrisccoulson> Q-FUNK, it shouldn't have been accepted
<chrisccoulson> we got rid of pretty much all firefox extensions from the archive for a good reason
<Q-FUNK> chrisccoulson: then it should have been said back then.
<bdrung> kenvandine: nice ubuntu-wallpaper upload. finally the old wallpapers can still be used.
<chrisccoulson> of course. but nobody asked me
<Q-FUNK> chrisccoulson: could it have been a good idea to get yourself know to the uploader then?
<seb128> Q-FUNK, breaking firefox is not appreciated at all
<Q-FUNK> chrisccoulson: right now, you're forcing the removal of a package that's needed to access public services and whose upload into the archive took ages to happen.
<Q-FUNK> seb128: do you even have proof that it's what did it?
<seb128> Q-FUNK, the removal has been asked by the firefox maintainer and I trust him to know what he's asking for
<seb128> Q-FUNK, it's not like it's hard to add it back when it's resolved
<seb128> Q-FUNK, it's just the safe way
<seb128> Q-FUNK, if it turns out to be an error I'm happy to NEW it back
<Q-FUNK> seb128: it's not like I can know IF and WHAT is broken after it's been removed without anyone backing up their claims.
<seb128> Q-FUNK, well it's "first let's stop breaking user, then we can discuss"
<chrisccoulson> Q-FUNK - we update firefox every 6 weeks. in adding a new extension to the archive, you're effectively committing me to spend extra time every 6 weeks for the next 5 years unbreaking, updating and testing it to keep it working with new versions of firefox
<kenvandine> bdrung, jbicha did the hard work :)
<chrisccoulson> not cool
<micahg> chrisccoulson: I assume this is not an NPAPI plugin, right?
<bdrung> kenvandine, jbicha: thanks for that. the default wallpaper are missing: bug #974628.
<Q-FUNK> micahg: you're also making assumptions that are unverified.
<chrisccoulson> micahg, it has a binary part that might be, but it also has a firefox extension
<ubottu> Launchpad bug 974628 in ubuntu-wallpapers (Ubuntu) "Default wallpaper for previous releases is missing" [Undecided,New] https://launchpad.net/bugs/974628
<chrisccoulson> Q-FUNK, what assumptions?
<chrisccoulson> i can assure you that extension is what broke your firefox localization
<chrisccoulson> by installing itself in to a location that is meant to be a symlink
<Q-FUNK> chrisccoulson: ok, so why didn't you just file a bug, rather than get seb128 to remove the package?
<micahg> Q-FUNK: we can't have random extensions in the archive as we can't be updating them every 6 weeks, if something is a pure NPAPI plugin, then it shouldn't break anything and should be fine, but even in those cases we have had some issues
<Q-FUNK> micahg: the source package contains both a XUL extension and a NPAPI plug-in, packaged separately.
<chrisccoulson> what functionality does the extension provide?
<micahg> Q-FUNK: right, so one piece is ok and the other isn't :) (assuming the plugin is installed properly)
<Q-FUNK> the XUL extension interfaces with opensc's one-pin module for website logon using PIN1.
<Q-FUNK> the NPAPI plug-in inerfaces with libdigidocpp to enable legally-binding digital signature of online documents using PIN2.
 * micahg will leave the rest here to chrisccoulson
<jbicha> bdrung: I'm not so sure we should include old copies of *the* default wallpaper itself
<chrisccoulson> note, i've just had a quick glance at the extension, and it would have even failed the basic preliminary review on addons.mozilla.org
<Q-FUNK> micahg: it could indeed be that the plug-in is at the correct location, while he extension isn't. if that's the case, please just put the info in the bug and I'll upload a fix.
<chrisccoulson> for polluting the main window global JS scope
<chrisccoulson> quite a lot, too
<Q-FUNK> chrisccoulson: could be.  it needs to do a lot of backflips to interface with the card.
<chrisccoulson> it needs to do that without polluting the main browser window scope though
<bdrung> jbicha: it would be nice to be able to install the old default wallpaper. my favourite ubuntu default wallpaper is the one from hardy.
<chrisccoulson> mozilla provide guidelines for avoiding that
<chrisccoulson> but that can break firefox and other addons in extremely strange, unpredictable and hard-to-trace ways
<bdrung> jbicha: they could either put to the ubuntu-wallpaper-* packages or into a separate package.
<Q-FUNK> chrisccoulson: upstream is quite active, as he is legally-bound to provide support by a public sector contract. if there's any such issue, I'm sure he'd love to hear about it.
<SpamapS> jdstrand: hrm, I wonder why it build-deps but does not have a real dep .. argh!
<Q-FUNK> chrisccoulson: upstream happens to be online now on #esteid if you'd like to explain what you just told me.
<chrisccoulson> Q-FUNK - 1 second. i'm just going to install it to make sure that's correct :)
<jbicha> bdrung: I was thinking of a ubuntu-wallpapers-classic with the pre-karmic wallpapers, but for the lucid-precise series the wallpaper isn't changing much
<jbicha> and I think the intended design is that the new tweaks replace the older version of the orangey-aubergine light thing
<Q-FUNK> chrisccoulson: basically, I'm committed to maintaining the ubuntu package, while upstream is legally-bound to support his code. whatever's wrong, please let us know.
<bdrung> jbicha: a ubuntu-wallpapers-classic package with the pre-karmic wallpapers sounds good.
<jbicha> bdrung: I don't think I'll do the slideshow for them though, just the standalone images
<bdrung> jbicha: creating a slideshow isn't that big deal
<bdmurray> SpamapS: do you plan on working on bug 957494?
<ubottu> Launchpad bug 957494 in mdadm (Ubuntu) "Missing added utility 'mdmon'" [Medium,Triaged] https://launchpad.net/bugs/957494
<stgraber> smoser, slangasek: hmm, apparently I was wrong, something makes dhclient stick around when it's not called with -1, will have to dig some more to figure out where that's
<bkerensa> cyphermox: you have a minute?
<cyphermox> yeah
<smoser> stgraber, thank you for looking at this.
<slangasek> stgraber: ok
<cyphermox> bkerensa: shoot :)
<bkerensa> cyphermox: I hear you are the bt expert?
<bkerensa> :D
<cyphermox> I'd never call myself an expert at anything ;)
<cyphermox> bkerensa: what do you want to know ?
<bkerensa> cyphermox: well I have a bug basically I have a brand new Jabra Halo v2 that pairs fine in Ubuntu but does not function as a headset and wont show up in -> Sound Settings
<bkerensa> and I am wondering who would be responsible for this kind of bug or at least works on these
<bkerensa> cyphermox: https://bugs.launchpad.net/ubuntu/+source/pulseaudio/+bug/972063
<ubottu> Launchpad bug 972063 in pulseaudio (Ubuntu) "Bluetooth Headset pairs but does not show up in Sound Settings profile" [Undecided,New]
<cyphermox> depends what bluez does with the headset; it might be bluez or pulseaudio. I'll update the bug accordingly
<SpamapS> bdmurray: I hadn't looked closely at it since the initial comment. I do want to fix it.
<bkerensa> cyphermox: the only thing that happens is if I press the button on the side of the headset it will mute my system sound and unmute but other than that no audio comes through and no sound settings profile is created
<bkerensa> cyphermox: slangasek did some basic troubleshooting with me but I am more than willing to do more debug if need be to get it sorted
<slangasek> the button working is irrelevant
<slangasek> rather, it's irrelevant to audio, which is a pulseaudio+bluez problem
<slangasek> the button works as a kernel input device
<cyphermox> oh, that changes things
<cyphermox> otoh, it means the device is properly paired and it's likely more of a pulseaudio issue than something with bluez
<slangasek> yes
<bkerensa> cyphermox: so basically I would love to work to try and debug this so whomever works on pulseaudio can perhaps make a crack at fixing it sometime in the future
<bkerensa> :D
<jjohansen> stgraber: so I can confirm i386 exhibits the same issue
<stgraber> jjohansen: cool, thanks
<skaet> We're now a week out from final freeze,  and are going to be freezing the archive, so that we can start to be selective about the fixes getting added.
<cjwatson> slangasek: unicode.pf2> oh, what do you know, we still do that; but for some reason /boot/grub isn't preferred over /usr/share/grub for loading it
<cjwatson> that's a bug I think
<slangasek> ah :)
<slangasek> does that mean we still don't know what's going on with reports of brokenness w/ crypted root?
<slangasek> oh, of course - my / is encrypted and my /usr isn't
<slangasek> so my experience is not going to be typical anyway here :P
<cjwatson> well, I think loading that from /boot/grub would serve to render at least encrypted /usr closer to the standard case
<slangasek> right
<skaet> Please continue to upload fixes,  and allert the release team members in #ubuntu-release for seeded image package fix issues,  and #ubuntu-motu channel for unseeded universe package issues.
<apw> q2
<cnd> slangasek, I'm down with a fever :(
 * kees hugs cnd
<cnd> kees is now infected too
<kees> only virtually
<SpamapS> kees: Hey, you know about md and udev.. any ideas on what adding this rule into the mdadm package might do to peoples' raid arrays? http://paste.ubuntu.com/916749/ ?
<kees> SpamapS: one sec, reading...
<kees> SpamapS: er, is this an entirely new file?
<SpamapS> kees: it would be /lib/udev/rules.d/64-md-raid.rules
<SpamapS> kees: we haven't been installing it since jaunty
 * kees studies
<SpamapS> kees: I think its just missing due to an oversight
<SpamapS> my udev knowledge is very weak.. :-P
<psusi> SpamapS, we seem to be shipping 65-mdadm-blkid.rules instead
<kees> SpamapS: so, the first section is handled (more correctly) by 85-mdadm.rules
<psusi> and that one
<kees> SpamapS: and the rest, as psusi says, is in 65-mdadm-blkid.rules
<SpamapS> interesting
<SpamapS> ok, this is an upstream file
<SpamapS> so it looks like we split it up already
<kees> (which is also more correct)
<psusi> yea.. also it looks like the upstream one is trying to use mdadm to activate intel fakeraid and ddf, which we still have handled by dmraid
<SpamapS> I think I'll keep the upstream one out of the package then
<SpamapS> psusi: this came up when I was solving the mdmon missing problem
<psusi> though someone yesterday had some trouble with intel fakeraid and it looked like mdadm had tried to activate it in the installer
<SpamapS> mdadm is still quite a mess IMO..
<SpamapS> Certainly better, as we're at least up to date with upstream
<psusi> upstream still hasn't sorted out how to deal with the problems introducing support for ddf and intel fakeraid causes... namely mdadm now conflicts with dmraid since both can handle those arrays
<SpamapS> alright, well for this particular fix, I'm just going to keep this file out of rules, but include mdmon and its corresponding manpage. Is mdmon at all part of the ddf/fakeraid case?
<psusi> yes... apparently its a daemon that updates the on disk metadata on behalf of the kernel
<psusi> for the new external metadata types
<psusi> it's required to get the array mounted read/write... and it seems there's a kernel BUG_ON that gets triggered without it... sounds like they assumed it would be there and didn't deal with it when it isn't...
#ubuntu-devel 2012-04-06
<SpamapS> psusi: alright, hopefully having it there doesn't trigger some other weirdness ;)
<SpamapS> psusi: so will we need mdmon in the installer then too?
<SpamapS> according to mdmon's man page.. we'd need to also add jobs to start mdmon after initramfs startup to truly support it properly
<SpamapS> but I suppose at least having the binary will allow users to handle their own business
<psusi> SpamapS, Neil Brown seemed to indicate that mdadm starts it automatically
<ogra_> slangasek, infinity, if one of you could take a look at compiz in the queue, that would be nice, i will do any fixes and the according compiz-plugins-main upload (it build deps on the compiz one) tomorrow ...
<infinity> ogra_: I'll have a look.
<infinity> yofel_: ...
<infinity> yofel_: Those KDE 4.8.2a uploads are literally identical to the previous ones, except for the version in the changelog... (the upstream source didn't even change)
<infinity> ogra_: || true is never a sane thing in a Makefile.
<infinity> ogra_: That cmake copying stuff should be wrapped in ifeq/ifneq gles2_arches stuff, so it will still hard-fail if something goes wrong.
<infinity> ogra_: Other than that (and the massive patch from Linaro that I won't even pretend to audit), it looks fine.
<infinity> jelmer: You probably don't need to sync the same package three times. ;)
<infinity> yofel_: Was 4.8.2a being identical to 4.8.2 intentional, or did you get the wrong orig tarballs?
<slangasek> right, syncing three times is for hard disks
<infinity> slangasek: Oh dang, if I'd thought about the fact that you were working on an apt upload, I would have tossed my own 1-line bugfix in too.
<slangasek> we can reject that one and take a mulligan?
<infinity> Or just build twice. :P
<infinity> I'm preoccupied right now anyway, I'll upload my 1-liner on the weekend.
<slangasek> ok
<infinity> Well, I guess my "weekend" is now.
<infinity> But.  Later on the weekend.
<infinity> 700k diff?  I guess that's translation fallout?
 * infinity looks.
<slangasek> yeah
<infinity> yofel_: ScottK explained the PPA version oops to me, un-rejecting the upload of yours that I bounced.
 * infinity wonders idly what would happen if he let his dom0 use half its ram for zram and then let his domUs overcommit...
<ScottK> yofel_: It would have been nice to have an actual debian/changelog entry that explained what you were doing and why to the poor release team reviewer.
<infinity> I accept payment in tiny violins.
<raffa50> hello i've done mime type!
<raffa50> i only have a problem... i can't see file icon
<raffa50> hello
<raffa50> i added my mime type
<raffa50> when i double click on the file my apps open ups
<raffa50> i only can't see the file icon
<raffa50> how can i do?
<geser> the Ubuntu Mobile Edition is dead and we can drop those changes from packages again, right? (like building with libhildon)
<raffa50> hello
<raffa50> i've added my mime type and mi apps open ups and load the file
<raffa50> but i can't see the file icon
<raffa50> how can i do?
<ogasawara> @pilot in
* udevbot changed the topic of #ubuntu-devel to: 12.04 Beta 2 Released! Precise: UI and feature freeze | Dev' of Ubuntu (not support or app devel) | build failures -> http://bit.ly/HaWdtw | #ubuntu for support and general discussion for hardy -> oneiric | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: ogasawara
<Amoz> ogasawara, hi, since you're on duty I can ask you to take a look at patches, right?
<ogasawara> Amoz: I can, but I'm afraid I can really only be of service if it's against the kernel.
<Amoz> ogasawara, oh, I see. Even if it's just a simple upstream bug release?
<Amoz> it's a bugfix release for pidgin
<ogasawara> Amoz: I've only got upload rights for the kernel, but am happy to review and try and get you in touch with the right person to help get the fix applied and uploaded
<Amoz> ogasawara, I've already subscribed ubuntu-sponsors to the bug, maybe I should just wait for them to review it?
<Amoz> or is there anything else I can do to make it easier for them?
<Amoz> the bug is #964210
<ogasawara> bug 964210
<ubottu> Launchpad bug 964210 in pidgin (Ubuntu) "msn buddies some times appears to be connected but it doesn't (refuses chat messages; if you disconnect and reconnect, buddies aren't show as connected)" [Undecided,Confirmed] https://launchpad.net/bugs/964210
<ogasawara> Amoz: I think you've done everything needed on your part
<Amoz> thanks ogasawara
<ogasawara> kenvandine: ^^ is 964210 you might be able to assist with?  Looks like Amoz already has a patch there and tested
<kenvandine> ogasawara, Amoz: i'll look at it
<Amoz> ogasawara, while you're here, is there any beginner kernel stuff one might be able to work with?
<ogasawara> Amoz: definitely!  what are you interested in?
<Amoz> well, everything?
<ogasawara> Amoz: I usually suggest to being with some simple triage work to get a feel for the workflow, then proceed from there with patches etc.
<ogasawara> s/being/begin/
<ogasawara> Amoz: come jump in #ubuntu-kernel and I can get you in touch with jsalisbury to get you going on triage if you're interested
<jsalisbury> Amoz, o/
<ogasawara> jsalisbury: oi, you're here :) and there :)
<roaksoax> mgw:/win 13
<roaksoax> arghh
<roaksoax> :)
<kenvandine> ogasawara, Amoz: pidgin sponsored
<Amoz> kenvandine, awesome, thanks
<Amoz> everything looked good?
<kenvandine> Amoz, yes
<Amoz> \o/
<raffa50> hello
<raffa50> i've added my mime type, but i can't see the file icon for my extension how can i do?
<Amoz> kenvandine, about the pidgin patch, is it supposed to appear somewhere? and should the bug be set to "fix commited" or something?
<EtienneG> guys, is it too late to request a sync for a package in universe?
<Laney> not if it's bug fix
<EtienneG> actually, someting is seriously fishy with package nsscache
<EtienneG> that's the one I want a sync for, but the version currently in precise is older than the one in lucid
<EtienneG> weird
<EtienneG> or not, actually.  turns out it was not in lucid
<EtienneG> but the Debian changelog has a lucid entry
<ScottK> Probably from a third party repo.
<yofel> infinity: sorry for the uploads, I'll make the changelog more informative next time.
* ChanServ changed the topic of #ubuntu-devel to: Precise: UI and feature freeze  Archive: frozen | Dev' of Ubuntu (not support or app devel) | build failures -> http://bit.ly/HaWdtw | #ubuntu for support and general discussion for hardy -> oneiric | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: ogasawara
<kenvandine> Amoz, it is in the unapproved queue right now, when the release team approves it the bug will get marked fix released
<Amoz> kenvandine, I see, thank you
<kenvandine> Amoz, np
<janimo> ogra_, the compiz GL or GLES backend is selectable at compile time only right?
<ogra_> janimo, i think so
<ogra_> janimo, though i think i saw a mail from alf that he has a patch that makes both (GL/GLES) alongside on an intel box
<ogra_> that should make it runtime selectable
<janimo> ogra_, yes, that would be useful, as some Intel boxes may have PVR based  GLES-only GPUs
<ogra_> right
<ogasawara> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Precise: UI and feature freeze  Archive: frozen | Dev' of Ubuntu (not support or app devel) | build failures -> http://bit.ly/HaWdtw | #ubuntu for support and general discussion for hardy -> oneiric | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<mvdk> I've gotten source package jbigkit accepted by Debian - per https://bugs.launchpad.net/ubuntu/+source/splix/+bug/918435 , I figure it's best to have a shared version of it instead of packages deciding that they'll import the source themselves.  Is there any way to get it accepted into precise?
<ubottu> Launchpad bug 918435 in splix (Ubuntu) "splix built with statically linked JBIG-KIT" [Medium,Confirmed]
<maxb> My guess is that it is a bit late in the cycle to start removing statically linked versions of things that are working fine
<jibel_> slangasek, there is a problem with latest flashplugin. bug 975426
<ubottu> Launchpad bug 975426 in ubiquity (Ubuntu) "flashplugin-installer failed to install during system installation: no alternatives for mozilla-flashplugin." [High,Confirmed] https://launchpad.net/bugs/975426
<slangasek> jibel_: thanks, looking
<slangasek> jibel_: got it, I think; gonna reproduce in a chroot first, but I should have the fix uploaded shortly
<jibel_> slangasek, thanks
<slangasek> jibel_: confirmed, and fix uploaded.  Sorry about that; the irony is that I made these changes to make the install more robust, but I only ever tested upgrades, so didn't notice the bug in the existing code :/
<mvdk> Is there anyone here who might be able to take jbigkit from Debian into Ubuntu?  It adds support for printers for SPLiX, and it was only recently accepted because the patents have finally expired (on Wednesday).
<slangasek> mvdk: maxb's comments above were directed at you
<mvdk> I don't see maxb's comments
<slangasek> i.e., it's probably not worth taking that package for precise, because if we *do* take it, we probably *won't* take the changes to split out any statically-linked versions from other packages at this stage
<slangasek> mvdk: ah, it was shortly before you disconnected :) 14:32 < maxb> My guess is that it is a bit late in the cycle to start removing statically linked versions of things that are working fine
<mvdk> Is that really true? It seems to me that it's a somewhat serious breach of policy, to include statically linked dependencies in a package...
<slangasek> it's certainly not preferred
<slangasek> but any instances of this particular linkage have been there for a while
<mvdk> Not without a bug being raised against it for a while
<slangasek> it's mainly against policy because it's a pain for security updates... but I don't think any of the affected packages are likely to get security attention anyway
<mvdk> This is probably true
<maxb> In essence... is there any motivation to need to rush this into precise rather than doing the work for q-series?
<mvdk> Well, jbig is also a minor support thing for libtiff as well, and adds support for JBIG faxes to hylafax
 * maxb dons devil's advocate hat and quietly chants "feature freeze" :-)
<slangasek> we're certainly not going to enable it in libtiff at this stage of the cycle
<mvdk> Those things are probably minor motivations; I rather figured that in effect, libjbig is already in Precise, and not much pain is exacted by splitting it out
<maxb> Whilst that's probably true, it seems there's also not much benefit to be realized by squeezing it into precise?
#ubuntu-devel 2012-04-07
<vibhav> https://bugs.launchpad.net/ubuntu/+source/valatoys/+bug/930568 has a merge request, since the bug is in debian too, wouldn't it be better to solve it in debian and then get a sync?
<ubottu> Launchpad bug 930568 in valatoys (Ubuntu) "gedit crashed with signal 5 in g_object_newv()" [Medium,Confirmed]
<Laney> vibhav: yes, but we could also fix it in Ubuntu and forward the fix to Debian too (so we can maybe sync next time)
<tumbleweed> given the late stage of the release cycle, that's almost certainly the way to go
<hyperair> can i continue a do-release-upgrade that i accidentally ^C'd?
<hyperair> stgraber: ping
<hyperair> stgraber: i noticed you sponsored the last liferea upload. would you mind sponsoring another? https://bugs.launchpad.net/ubuntu/+source/liferea/+bug/976120
<ubottu> Launchpad bug 976120 in liferea (Ubuntu) "liferea is built without libindicate support in Precise" [Undecided,Confirmed]
<jarnos> I just installed using an alternate i386 image (lubuntu) using encryption, automatic partitioning using entire disk. No I can not login in the display manager: it throws me back in login.
<jarnos> in boot there is complaint about not finding disk drive for /dev/mapper/cryptswap1
<jarnos> or to be more specific: the disk drive is not ready yet or not present.
#ubuntu-devel 2012-04-08
<Sonja> hi
<lsmagalhaes> hello everybody
<lsmagalhaes> I'm using Ubuntu 12.04 beta
<lsmagalhaes> and last time that I ran apt-get upgrade the flash-plugin crashed.
<ScottK> lsmagalhaes: When was that?
<lsmagalhaes> today, at afternoon.
<ScottK> There were a number of fixes for it done yesterday.
<geser> infinity: are you aware of the dependency loop between libomxil-bellagio0 and libomxil-bellagio-bin when you fixed bug #921523?
<ubottu> Launchpad bug 921523 in libomxil-bellagio (Ubuntu) "package libomxil-bellagio0 0.9.3-1ubuntu1 failed to install/upgrade: ErrorMessage: subprocess installed post-installation script returned error exit status 127" [Undecided,Fix released] https://launchpad.net/bugs/921523
<infinity> geser: Sure, can you show me where it causes a problem in practice?
<infinity> geser: Dependency loops aren't disallowed, only discouraged (since the tools need to arbitrarily break the loop).
<infinity> geser: It does guarantee that higher level tools feed both packages to dpkg in the same run, which give the desired result in this case.
<geser> ok then, I remember to avoid dependency loops when possible
<infinity> And well you should.
<infinity> Libraries calling stuff from lib*-bin in their postinsts are probably broken. :P
<geser> is this dependency loop safer at this moment instead of a "sync" with Debian? (merge -bin into the library)
<infinity> (Though libc6 is another offender here, and the only reason it doesn't have a loop is because libc-bin incorrectly doesn't have a dep on libc)
<infinity> geser: Well, it would be safe to do that right up until someone decides to multiarch the package.
<infinity> geser: But there's nothing inherently unsafe about dep loops, they just make resolvers work harder and break more often.  For something as leaf-ish as libomxil-bellagio, I doubt it'll cause an issue.
<infinity> (Basically, a dep loop means that higher level tools MUST pass both packages to dpkg in the same run, which means if there are a bunch of rdeps, they often also end up in the same run, which hurts resolvers' brains)
<infinity> Given the nearly nonexistant rdep list for libomxil-bellagio0, I have a hard time seeing the above as a particularly scary problem.
<geser> but in the long run it should be fixed properly, right? (without a dep loop)
<infinity> In the long run, someone needs to examine if the library really needs to be calling that binary in its postinst.
<infinity> If it does, the loops is unavoidable, really.
<infinity> (see: libc and libc-bin)
<infinity> It's not an ideal situation, but it happens sometimes.
<infinity> If they're always found together, and produced from the same source, the dep loop isn't really catastrophic.
<infinity> I could artificially break the loop by making the -bin incorrectly not depend on the lib (like the libc case), but that's both silly and unnecessary.
<geser> thanks for the explanation
<infinity> Anyhow, policy doesn't forbid loops, it just strongly suggests against them because it makes resolving and unpacking somewhat difficult.
<infinity> In the case of libomxil-bellagio, the loop-breaking is actually deterministic.
<infinity> "If one of the packages in the loop has no postinst script, then the cycle will be broken at that package; this ensures that all postinst scripts are run with their dependencies properly configured if this is possible."
<infinity> ^-- Since the library has a postinst, but the -bin doesn't, then we get "lib/bin unpacked in arbitrary order, bin configure, lib configured".
<Laney> infinity: geser: I'm not sure it is actually necessary to call the binary on configure. From its man page: "By default, this will create a file named .omxregister under the home XDG data directory with all the components found in ${lib-dir}/libomxil-bellagio0.", yet this directory is empty in libomxil-bellagio0.
<Laney> Hm, you still need the Depends for the trigger though.
<nelson777br> hello, I'm having some trouble finding resources about how to integrate my application to Unity. I thought I would only create a .desktop file in /usr/share/app-install/desktop. But it's not working. I create the file and it doesn't appear in unity search. I do I make unity recognize my application ?
<nelson777br> I also counldn't find any docs about this in developer.ubuntu.com. If anyone knows about some documentation about this subject I would appreciate it. Thnx
<krnekhelesh> hi, I have a question regarding patches
<krnekhelesh> I have the command bzr diff -r 191..190 | bzr patch
<krnekhelesh> but bzr complains it does not recognize patch
<krnekhelesh> anyone know how to solve this??
<krnekhelesh> I took the info from http://mhall119.com/2012/03/contributing-to-unity-for-non-developers-package-patching/
<jelmer> krnekhelesh: bzr patch is a part of the bzrtools plugin
<krnekhelesh> jelmer: what is the package name?
<jelmer> krnekhelesh: bzrtools
<krnekhelesh> thnx
<nik90> I branched totem, made my changes, converted it into a patch in debian/patches folder and in the series file
<nik90> after reverting back using  bzr diff -r 191..190 | bzr patch, which works
<nik90> I try quilt push -a
<nik90> but I do not get the output
<nik90> I get the output File series fully applied, ends at patch 03_default_options.patch
<nik90> but then my patch name was add_keywords.patch
<nik90> hwo do I fix this?
<nik90> jelmer, do you know?
<nik90> anybody
<nik90> ?
<mhall119> nik90: did you add your patch to the series file
<mhall119> ?
<mhall119> echo add_keywords.patch >> debian/patches/series
<nik90> yes
<mhall119> cat debian/patches/series
<nik90> when I do that I see my patch included
<mhall119> nik90: cat debian/source/format
<nik90> 3.0 (quilt)
<nik90> the same as in your blog post
<mhall119> huh
<mhall119> nik90: run "quilt applied"
<nik90> mhall119, it shows 3 other patches except my patch
<mhall119> nik90: now try "quilt unapplied"
<nik90> File series fully applied, ends at patch 03_default_options.patch
<mhall119> huh...
<mhall119> and you have add_keywords.patch in debian/patches/ ?
<nik90> that's wierd, because in my debian/patches folder I see the add_keywords.patch file
<nik90> yes
<mhall119> try "quilt series"
<nik90> no output
<mhall119> oh, hang on...
<mhall119> nik90: run "echo $QUILT_PATCHES"
<nik90> a blank line output
<mhall119> export QUILT_PATCHES=debian/patches
<mhall119> then try "quilt series" and "quilt unapplied" again
<nik90> quit series gives the following output 00_create_m4_folder.patch
<nik90> 02_lpi.patch
<nik90> 03_default_options.patch
<nik90> add_keywords.patch
<nik90> quilt unapplied shows only my patch
<mhall119> ah ha, that did the trick
<mhall119> now quilt push -a should apply it
<nik90> yup it does now :)
<mhall119> nik90: copy http://paste.ubuntu.com/920422/ into ~/.quiltrc
<mhall119> someone here gave me that, seb I think, but it works
<nik90> so do I have to run  export QUILT_PATCHES=debian/patches everytime i restart>
<nik90> or does the new .quiltrc fix that
<mhall119> I think quilt will run the quilt.rc every time
<mhall119> quiltrc
<nik90> oh good...thnx for your help
<mhall119> np, thanks for the contributions :)
<nik90> mhall119, https://code.launchpad.net/~nik90/ubuntu/precise/totem/add_keywords_new/+merge/101209
<nik90> if you look at diff it added .pc/ since it was from your blog post...does the diff look normal?
<mhall119> nik90: are there any other files in .pc?
<mhall119> I *think* this is okay,  but I'm not 100% sure
<nik90> yes there are more file in .pc
<nik90> I guess other patches made by other users
<mhall119> but those weren't added to bzr?
<nik90> no...but I guess that because I did not create or modify those files
<mhall119> hmmm, my feeling is that it should probably be all or none, but I'm not sure which is more correct
<nik90> the other files include other patch folders which was there when I branched the latest
<mhall119> and it being not only a weekend, but a holiday today, there's not likely anybody around who can give a definitive answer
<nik90> I have anyway proposed a merge...so will what happens tomorrow or the day after
<mhall119> nik90: try asking in here tomorrow, someone should be around to help then
<nik90> mhall119, yeah I will do that
<tumbleweed> jdstrand: poke re bug 967195
<ubottu> Launchpad bug 967195 in ruby-rack (Ubuntu) "FFe: Sync ruby-rack 1.4.0-1 (universe) from Debian wheezy (main)" [Undecided,Incomplete] https://launchpad.net/bugs/967195
#ubuntu-devel 2013-04-01
<vibhav> j #ubuntu-community-team
<vibhav> oops, sorry :)
<Whoopie> debfx: Hi, I just wanted to remind you that the virtualbox unresolved symbol issue is still present with 4.2.10 (libGL error: dlopen /usr/lib/x86_64-linux-gnu/dri/vboxvideo_dri.so failed (/usr/lib/x86_64-linux-gnu/dri/vboxvideo_dri.so: undefined symbol: XCompositeQueryExtension)).
<doko> xnox, do you take care about the Tcl/Tk multiarch ftbfs?
<doko> bdrung_, are you going to fix libarchive? sponsored by you
<debfx> Whoopie: right, I completely forgot about that. I have done way too many virtualbox uploads yesterday ...
 * mitya57_ wonders what MANUALDEPWAIT is
<mitya57_> doko, bdrung_: looks like we need a MIR for lrzip to fix libarchive
<doko> mitya57_, or drop the lrzip b-d
<mitya57_> that'll introduce a delta that I don't think anybody wants to carry
<didrocks> probably a stupid question, but does anyone know if we have a debhelper/dpkg command to know from a source package all archs from all the binaries file generated by this source?
<didrocks> or should I do the parsing by hand?
<debfx> Whoopie: I've uploaded a fix.
<jdstrand> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Ubuntu 12.10 released | Archive: Final Beta Freeze | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of hardy -> quantal | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: jdstrand
<ScottK> ogra_: Congratulations on the chromium-browser build for armhf.
<ogra_> ScottK, well, it was a one char fix
<ScottK> It's not the size of the fix, it's finding where to make it.
<ogra_> (the effort to get it into the package was way bigger than the fix itself)
<mitya57> can we use "lite" version of upstream tarball (which probably has less embedded libraries)?
<mitya57> https://gsdview.appspot.com/chromium-browser-official/?marker=chromium-21.0.1168.0.tar.bz%40
<ogra_> well, that will likely also have less functionality
<ogra_> err
<ogra_> lite ?
<ogra_> the saved 50M wont really help so much i guess
<highvolt1ge> ogra_: very funny ;)
<ogra_> :)
<Riddell> ogra_: winding up my poor community! https://lists.ubuntu.com/archives/kubuntu-devel/2013-April/006928.html
<ogra_> yeah, just heard about it :)
 * ogra_ giggles 
<ogra_> to sad he isnt aroudn to clearify
<ScottK> Humor is apparently wasted on the young.
<ogra_> yeah, i hope he isnt venting too much now
<ScottK> Where did he fail to see the humor?  I must not be reading the right place?
<dobey> ScottK: maybe he thinks the euro really is a stable currency
<ScottK> Found it.
<ScottK> That should have been enough of a clue right there.
<ScottK> Apparently I try to trick my 10 year old daughter far too often on other days to make April Fools any fun at all.  She's sufficiently skeptical to start with, I didn't pull one off yet.
<Riddell> dobey: that's the Hong Kong British legacy, euro is stable from the view of those of us using Sterling
<ogra_> heh
<infinity> siretart: Bah.  mplayer is FTBFS in raring and I didn't notice until after I uploaded an unrelated change.  Do you have a fix for the current failure?  Looks like it needs a bit of porting to a new API, maybe?
<jdstrand> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Ubuntu 12.10 released | Archive: Final Beta Freeze | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of hardy -> quantal | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<mterry> doko, why does component-mismatches point cinder to python-babel?  I can't see it from the source
<doko> mterry: python-cinder depends on python-babel
<mterry> doko, yar, I get that, but I'm just not sure how.  I grepped cinder source for babel, but got no hits
<mterry> doko, ah...  in requires.txt, there is Babel.  But it's not used in the source I don't think
<mterry> ah...  I get it now.  babel.cfg
<mdz> soren, is TB in 10 minutes?
<mdz> we're out of the DST triangle now right?
<stgraber> my phone says it's in 10min
<ogra_> europe is on summer time now
<stgraber> and it's 21:00 in London in 10min, so yeah, TB meeting is in 10min
<stgraber> (well, more like 7 by now)
<mdz> has anyone heard from soren? he wasn't at the previous meeting
<stgraber> mdz: he recently sent an e-mail to the TB mailing-list (27th)
<mdz> I wonder if he knows he is chairing
<stgraber> ah, yeah, looks like you didn't mention it in the minutes
<siretart> infinity: bah, that looks like some change in liblivemedia is responsible for that
<stgraber> mdz: anyway, if soren doesn't show up I'll chair
<mdz> ok, thanks for that
<mdz> I should have emailed him but didn't
<siretart> infinity: when looking at the upstream's commits, this patch might fix it: http://paste.debian.net/246471/
<soren> bryce: Can you join us in #ubuntu-meeting to talk about the Xserver MRE?
<siretart> infinity: nope, that patch is obviously not enough :(
<siretart> infinity: i think i have a workaround: disable live555 support completely for now. my testbuild is still running, but if it works, I'm going to upload that to raring. at least for the time being
<infinity> BenC: New kernel based on 3.8.5, if you have the time to quickly rebase PPC.  If not, it can wait until post-beta.
<BenC> infinity: Should I expect an ABI bump from 3.8.4?
<infinity> Dunno.  Master had one, but that could be unrelated.
<infinity> BenC: Not that it would hurt to artificially bump ABI, if you don't want to bother with a testbuild to find out.
<infinity> (Of course, every time you skip a test build, upstream breaks one of your drivers...)
<infinity> zequence / apw: Anyone going to get linux-lowlatency caught up?
<zequence> infinity: I've prepared package sources in our team ppa. Not sure if I'm missing something still
<infinity> zequence: For SRU or raring?  (I realize my question was originally ambiguous, since we're behind on a few releases)
<zequence> infinity: SRU. I don't do raring yet
<ScottK> If there's a desktop'ish person around you may want to rmadison unity-2d|grep raring and see if maybe something's getting auto updated that shouldn't.
<infinity> ScottK: Looks fine to me...
<ScottK> infinity: unity-2d is still being developed?
<infinity> ScottK: No, it's just a transitional package that depends on unity for "smooth" upgrade purposes.
<infinity> ScottK: And needs to be in place until 14.04.
<ScottK> Ah.
<ScottK> Forgot to check that bit.
<ScottK> Thanks.
<infinity> I use the term "smooth" very loosely here, since the world comes crashing down if you have no useful OpenGL support, but...
<ogra_> in 14.04 unity will depend on Mir anyway ...
<ScottK> http://techland.time.com/2013/04/01/google-april-fools/?hpt=hp_t4 <-- "We tried orange; brown: brown was a disaster."
<infinity> BenC: So, yea or nay on the linux-ppc rebase?  Trying to decide if I hold off on a d-i upload for it or not.
<infinity> BenC: (ARM has about 5 hours to go in its build, so sometime before that would be nice)
<BenC> infinity: In about 30 minutes
#ubuntu-devel 2013-04-02
<BenC> infinity: upload processing
<infinity> BenC: adare and ross on manual, then.
<infinity> (and accepting)
<infinity> BenC: Needs a matching -meta too...
<infinity> BenC: Ahh, there it is.
<ScottK> jbicha: Please don't mark bugs fix released when the fix is in a PPA.  Fix released for an Ubuntu bug is for when the package is in Ubuntu.
<ScottK> (re 1163062)
<jbicha> ScottK: ok, should I mark it invalid? it only affects packages in the ppa
<ScottK> jbicha: Yes.
<ScottK> I wouldn't bother changing this one.
<ScottK> jbicha: For Kubuntu PPAs we created a /kubuntu-ppa project and direct people to file bugs against PPA packages there.
<ScottK> It wasn't clear in the case of that bug it only affected the PPA.
<vibhav> good morning
<doko> infinity, could you leave a comment on http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=701422
<ubottu> Debian bug 701422 in src:cifs-utils "cifs-utils: ftbfs with eglibc-2.17" [Important,Open]
<dholbach> good morning
<infinity> doko: I'm not sure I have an opinion there.  I'm certainly not going to deviate from upstream, but vorlon's welcome to file a bug at sourceware.org
<doko> slangasek, ^^^
<infinity> slangasek: Looking at commit 7e66ee5142deda977163d0a858c3d2883cae3f07 and comparing manpages, I'm inclined to agree that including setfsuid and setfsgid in the list of set*id WUR changes there was probably a mistake.
<infinity> slangasek: If you ask nicely, maybe I'll throw a patch upstream to revert that part of the commit and see if I get any arguments.
<bkerensa> <(o.o) >
<slangasek> infinity: "ask nicely" is code for "buy you a beer", right?
<infinity> slangasek: Could be.
<infinity> Bah, I was going to look and see if reality matched the manpage, but it's a straight syscall, there's no way for glibc to know that anyway.
<doko> $ file !$
<doko> file /usr/include/linux/stddef.h
<doko> /usr/include/linux/stddef.h: very short file (no magic)
<doko> infinity, apw,: empty file. do you know why?
<dholbach> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Ubuntu 12.10 released | Archive: Final Beta Freeze | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of hardy -> quantal | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: dholbach
<infinity> doko: Maybe the one define it used to have isn't necessary anymore?
<doko> infinity, there is *no* define
<doko> well, at least I would expect a comment
<infinity> Hrm.  The kernel source has "#include <linux/compiler.h>" in that file.
<infinity> Weird.
<dholbach> Riddell, do you know if somebody is looking into bug 1131636?
<ubottu> bug 1131636 in skype (Ubuntu) "After QtWebkit update Skype is not launching" [Undecided,Confirmed] https://launchpad.net/bugs/1131636
<dholbach> I'm asking because there's a workaround in bug 1155327 (which is in the sponsoring queue) and I'm not 100% sure what the best solution for now might be
<ubottu> bug 1155327 in skype (Ubuntu Raring) "skype crashed with SIGSEGV in malloc@plt()" [High,In progress] https://launchpad.net/bugs/1155327
<doko> jamespage, could you have a look at the tomcat7 build failure?
<doko> hmm, could retry with the updated openjdk too
<infinity> doko: So, I'd guess the reason it's empty is because the one in the kernel is a single line including linux/compiler.h, which also doesn't exist in the userspace headers.
<infinity> doko: But Andy may have better ideas about WTF oddity is going on there.  The UAPI mangling stuff could still have some bugs.
<dholbach> hey mvo!
<dholbach> mvo, I have an apt question :-D
<mvo> hey dholbach
<mvo> dholbach: sure, fire!
<dholbach> mvo, it seems apt/dpkg is stuck over here unpacking a kernel package for some time now - how do I debug it?
<mvo> dholbach: what does ps afx show?
<mvo> dholbach: hm, its unpacking you say? then its a dpkg bug ;)
<dholbach> mvo, http://paste.ubuntu.com/5669752/
<ogra_> dholbach, hmm, i saw plenty of reports about that on G+ the last days
<rbasak> infinity: ping
<mvo> dholbach: and no terminal prompt/gtk debconf prompt anywhere?
<dholbach> mvo, no
<ogra_> seems to have started around wed. or thu. last week
<mvo> dholbach: can you do a strace -p 19619 ?
<dholbach> mvo,
<dholbach> Process 19619 attached - interrupt to quit
<dholbach> read(3,
<mvo> dholbach: yeah, I suspected this, so it looks like aptdaemon did not give you a terminal/gtk debconf prompt :/
<dholbach> mvo, so it's an aptdaemon problem?
<doko> mvo: https://launchpad.net/ubuntu/+archive/test-rebuild-20130329/+build/4410918
<doko> can you reproduce this? hangs in the testsuite on i386
<doko> didrocks, don't see pitti or seb128 here. could you organize a bug fixing party for the gtk/gir/gnome ftbfs in main (and maybe in universe)?
<doko> didrocks, don't see pitti or seb128 here. could you organize a bug fixing party for the gtk/gir/gnome ftbfs in main (and maybe in universe)?
<doko> seb128, ^^^
<didrocks> doko: see, better to invoke the right people :)
<seb128> doko, hey, just back from 4 days w.e, will have to figure out what's the workload for the next week(s) first, but I can see try to squash a few
<seb128> doko, do you have a list?
<doko> seb128, http://people.ubuntuwire.org/~wgrant/rebuild-ftbfs-test/test-rebuild-20130329-raring.html
<seb128> thanks
<doko> I think you know the package names better than I do
 * ogra_ wonders what esound still does in main
<dholbach> mvo, shall I kill the process and file a bug on aptdaemon about it?
<mvo> dholbach: yes please
<dholbach> thanks mvo
<mvo> doko: probably the same bug that dholbach just experienced
<dholbach> mvo, bug 1163163
<ubottu> bug 1163163 in aptdaemon (Ubuntu) "aptdaemon does not give a terminal/gtk debconf prompt" [Undecided,New] https://launchpad.net/bugs/1163163
<dholbach> doko, ^
<dholbach> Mirv, for https://code.launchpad.net/~timo-jyrinki/ubuntu/raring/ubuntu-touch-meta/fix_lp1163125/+merge/156464 would you mind adding a changelog entry?
<dholbach> Mirv, apart from that I'm happy to sponsor it
<Mirv> dholbach: there is one already?
<Mirv> oh, changelog, not commit message
<dholbach> hum
<Mirv> ok, just a second
<dholbach> perfect
<Mirv> dholbach: pushed changelog change
<dholbach> on it
<Mirv> hmm, version bump probably still as native package?
<Mirv> pushed that as well..
<dholbach> thanks
<dholbach> Mirv, uploaded
<Mirv> thanks!
<cjwatson> dholbach: https://code.launchpad.net/~timo-jyrinki/ubuntu/raring/ubuntu-touch-meta/fix_lp1163125/+merge/156464 - still time to abort that upload?
<Mirv> ah, one more layer of autogeneration
<dholbach> cjwatson, oops sorry - I'm happy to upload a newer version of it with a fix in the seeds file
<cjwatson> dholbach: perhaps you could just sync up the seed branch I pointed to
<cjwatson> that should be enough now, but we shouldn't make this kind of manual change in future
<dholbach> yes, agreed - I haven't touched seed related bits in a very long time and I wasn't sure where this change needed to be made
<dholbach> cjwatson, it's still in the unapproved queue of raring - so it could be rejected there if you like, but I can also just go and update the seeds
<cjwatson> might as well just do the latter now
<dholbach> ok
<Mirv> proposed https://code.launchpad.net/~timo-jyrinki/ubuntu-seeds/ubuntu-touch.raring.fixlp1163125/+merge/156487 as well
<cjwatson> I just want to avoid the two data sources getting out of sync, so that when somebody later comes along and tries to do things the right way they don't get confused at it randomly reverting changes
<cjwatson> yep, that's correct, I'll merge it, thanks
<dholbach> thanks Mirv, cjwatson
<ogra_> cjwatson, hmm, could we set up meta MPs in a way that ubuntu-release, ubuntu-core-dev or ubuntu-cdimage gets the notifications  ?
 * ogra_ would have liked to be notified for that one ... seems the only automatic subscriber for it is ubuntu-branches ... which is rather pointless
<xnox> ogra_: just subscribe relavant team(s) to the lp:ubuntu/meta-foo branches.
<ogra_> xnox, i know i can do that ... but before i blindly subscribe a team i rather get some feedback ;)
 * ogra_ subscribed himself now 
<ogra_> though i dont think that gives me MP notifications ... and i dont want to be the only reviewer
<cjwatson> ogra_: I'm not quite sure how it works TBH - those branches are magic in various ways
<ogra_> heh
<wgrant> ogra_: You'll get MP notifications if you configure your subscription to give you them.
<wgrant> By default it doesn't, I don't think, but it asks you.
<ogra_> wgrant, thx, i'll make sure thats set
<doko> Laney, could you take of goocanvas for the next cycle? I see you are involved in the Debian issue
<seb128> doko, he's off this week
<doko> Riddell, ScottK: could you have a look at https://launchpad.net/ubuntu/+archive/test-rebuild-20130329/+build/4442123 ? it looks like a wrongly set bin dir
<Riddell> hmm, maybe some clashing with qt 5
<ev> cjwatson: for what it's worth, bdmurray went ahead and implemented the mapping from bugs to crash signatures on https://errors.ubuntu.com: https://rt.admin.canonical.com/Ticket/Display.html?id=60462
<ev> if memory serves, I believe you asked for this a while back
<ev> trying to getÂ it landed today
<cjwatson> is that a bidirectional mapping?  I think I was looking for crash signatures to bugs
<cjwatson> (the particular case I wanted it has been handled, but I'm sure I'll need that again at some point)
<ev> err yes, the bidirectional stuff
<ev> I think :)
 * ev digs
<ev> cjwatson: ah, we don't have that precisely, but its just because the API doesn't expose it. It's an easy fix that I'll make today.
<cjwatson> OK, cool, thanks
<doko> xnox woke up, db uploads starting ...
<xnox> doko: you are funny. I notice a lot of gir ftbfs as well that can be fixed similar to https://launchpadlibrarian.net/135708494/ubiquity_2.14.0_2.14.1.diff.gz
<xnox> doko: also what's up with all the underlinking? something changed in the linker/gcc?
<doko> xnox, yep, did ping seb128 about the gtk/gir stuff
<seb128> doko, xnox: seems like you guys are on desktop stuffs so I will wait before doing some so we don't conflict
<doko> the underlinking was a bug, recently fixed in binutils
<doko> seb128, no we stay away =)
<seb128> doko, ok ;-)
<rbasak> What does the "Set" column mean in the FTBFS reports????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????
<rbasak> Aargh. Sorry, stuck key.
<rbasak> doko: can I help with some of these FTBFSes? What's already being worked on?
 * rbasak is on +1 maintenance this month, but infinity is presumably asleep right now
<doko> rbasak, see the recent uploads, I'll stop myself for today with this stuff. xnox did do the db packages
<rbasak> doko: where to look? https://launchpad.net/ubuntu/raring/+queue?queue_state=3 or somewhere else?
<doko> rbasak, http://people.ubuntuwire.org/~wgrant/rebuild-ftbfs-test/test-rebuild-20130329-raring.html
<rbasak> doko: I mean for recent uploads
<doko> ahh
<doko> https://lists.ubuntu.com/archives/raring-changes/2013-April/thread.html
<rbasak> OK - thanks!
 * rbasak looks at sqlite3
<wgrant> rbasak: The Set column indicates whether the source is in any packageset.
<rbasak> wgrant: ones that are directly listed, or anything seeded?
<rbasak> Oh
<rbasak> Upload set.
<rbasak> Gotcha
<doko> rbasak, sqlite3 is done =)
<wgrant> Packagesets tend to be based on the transitive closures of the seeds, right.
<rbasak> doko: so it is. I'll look more carefully, thanks.
<GunnarHj> cjwatson: Hi Colin, can you please take a look at bug 1163142? seb128 think you may be the right person to spot the problem.
<ubottu> bug 1163142 in language-selector (Ubuntu) "Hangs when "preconfiguring packages" at the installation of a language" [Undecided,Confirmed] https://launchpad.net/bugs/1163142
<seb128> cjwatson, I ran into a similar issue the other day, it seemed like dpkg/debconf being stucked on a read (from strace)
<cjwatson> GunnarHj: is it reproducible locally?
<cjwatson> seb128: in the same language-selector stack?
<GunnarHj> cjwatson: I could easily reproduce it.
<seb128> cjwatson, no, normal upgrade using update-manager for me
<seb128> cjwatson, we have/had issues with the new unity-dash "spamming" gvfsd-http and hiting ulimit on open fds
<cjwatson> seb128: yeah, if it was a different stack that's sort of like "I ran into a compiler error yesterday too" :-)
<seb128> so I wonder if that could break debconf
<cjwatson> much more likely that something is mishandling fds
<cjwatson> in the layers above debconf
<cjwatson> it's easy enough to do if e.g. you forget to mark the right things close-on-exec
<cjwatson> GunnarHj: can you give me step-by-step instructions?
<GunnarHj> cjwatson: Just try to install any language using language-selector. That's it.
<seb128> cjwatson, right, I just wanted to point the dash eating all the available fds issue as a data point in case it's useful, but seems like that one could be a different bug
<dholbach> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Ubuntu 12.10 released | Archive: Final Beta Freeze | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of hardy -> quantal | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<cjwatson> GunnarHj: Got it.  I'll see what I can do
<GunnarHj> cjwatson: Great, thanks!
<didrocks> cjwatson: is it normal that natty is still on http://archive.ubuntu.com/ubuntu/dists/?
<cjwatson> I think so, yes.  There's generally a delay on removing that due to various stragglers
<didrocks> ah ok, thanks :)
<melodie> hello
<melodie> I am seeking help with casper and post install scripts for a little project, and I am not sure what the problem is to get to the goal. I would like the post-install script to put 2 launchers on the desktop : after install, whatever language it will be.
<melodie> I have got it in the Live remix, thanks to a script in the casper-bottom directory, and from there I don't know how to achieve the rest ?
<melodie> I have looked also the chan list to see if there is another chan where I could ask, and I didn't see any other more relevant
<cjwatson> seb128: good news, this has nothing to do with unity; bad news, argh twisty pile of code
<cjwatson> melodie: have a look at the ubiquity-hooks/ directory in the casper source
<seb128> cjwatson, thanks for investigating it!
<cjwatson> It doesn't have a *specific* example for desktop launchers, but scripts there are run by ubiquity post-install in much the same way that casper-bottom hooks are
<melodie> hi cjwatson, among else there is one question I wondered: would the following bug be causing the desktop launchers from the live not be copied to the desktop ? https://bugs.launchpad.net/ubuntu/+source/xdg-user-dirs-gtk/+bug/1163043
<ubottu> Launchpad bug 1163043 in xdg-user-dirs-gtk (Ubuntu) "Directory Desktop stays in English in the Live CD's" [Low,New]
<melodie> i show you the script too:
<melodie> http://paste.ubuntu.com/5670225/
<cjwatson> sorry I don't know and can't look right now
<melodie> no problem
<cjwatson> the whole business of translated directory names is an incredibly stupid design guaranteed to lead to problems, of course
<melodie> is there another chan somewhere else for that sort of question ? anyhow I can stay connected
<melodie> oh so...
<cjwatson> iron rule should be to translate for display but not in the underlying identifier
<cjwatson> sadly some people failed to understand this ...
<seb128> cjwatson, when you do that you run into issues where your filebrowser/fileselector doesn't match your translated UIs (or if you use an app using a toolkit which doesn't do the translation for you)
<seb128> but yeah, each solutions have their issues
<melodie> hi seb128
<seb128> it's not a problem easy to solve as long as you give users direct access to the fs and don't have one toolkit
<seb128> would be easier if we had one API and a file picker ;-)
<seb128> melodie, hey
<melodie> I saw you have triaged this bug I filled. thank you. :)
<seb128> yw
<cjwatson> seb128: the problem with the xdg solution is that it moves all the bugs away from xdg and into everyone else's scripts
<cjwatson> classic example of externalising costs
<cjwatson> which of course looks OK if you aren't on the receiving end :)
<seb128> well, Desktop is sort of a special case and trickier
<cjwatson> ah, here we go, the aptdaemon bug isn't quite as hard as I thought
<cjwatson> missing flush
<seb128> but for things like Music it does make sense to be able to define the directory to be whatever you want and to have the name translated
<GunnarHj> melodie: Hi MÃ©lodie!
<seb128> cjwatson, \o/ on finding the aptdaemon bug ;-)
<melodie> seb128 do you have an idea if it is possible to get these 2 poor launchers from the Live to the installed version ? this is the script which is used, maybe could be improved or completed or ? http://paste.ubuntu.com/5670225/
<melodie> hi GunnarHj :)
<seb128> melodie, can't you just add those files to /etc/skel ?
<seb128> hum, I guess that's where the translated "Desktop" directory makes things harder...
<melodie> seb128 perhaps not as long as casper creates the directories where it is supposed to go ?
<melodie> yes, it is what makes it harder...
<seb128> you don't use nautilus right?
<seb128> nautilus a gsettings key for those special icons
<melodie> I use pcmanfm, and could use as well thunar  or spacefm
<seb128> which would make your job easier than having to .desktop files
<seb128> to copy*
<GunnarHj> melodie: I'm not sure about your suggestion with bold text in the Language Support UI. I do agree it would be motivated - you were not the first to have problem with the drag-and-drop thing - but I don't think we use bold text in other UIs, so it would be a style break.
<melodie> GunnarHj then some color maybe ?
<GunnarHj> :)
<GunnarHj> melodie: Even worse, I'd say.
<melodie> I have to check the bug report page to find another idea then
<seb128> melodie, sorry, I'm not sure what's the best way to do that, out of shipping a small script that create those on first login
<melodie> that would suit the need I'd say
<melodie> I don't know how to do that, so if you would I will be very happy to get help at some point
<GunnarHj> melodie: In the release after 13.04 we will switch to another UI completely. I'd suggest that we are patient in the meantime.
<seb128> melodie, basically add a .desktop in /etc/xdg/autostart that call your script/command and make that script/command write a key/file somewhere to say its job is done and exit when the file exist
<seb128> melodie, so it runs once and then do nothing from then on
<melodie> nice! and that could also reproduce the process for each new user created: right ?
<seb128> yes, those autostarts are run by the user and you should write the key/file in the user dir
<melodie> thanks. I'll ask someone to do it that way and will test it right after
<melodie> GunnarHj I agree when it comes to patience, there is no other way. Just if I can fetch an idea you could use, I'll give it a try. :)
<doko> apw, ogasawara: I was looking at the tcpcopy ftbfs, looks like ip_queue.h isn't included in linux-libc-dev. it is in Debian. why not in Ubuntu?
<GunnarHj> melodie: Thanks. :) (Still thinking about your idea - can't help it's tempting to make an exception.)
<melodie> I am installing a new language in my version now, to remember how it looks like exactly
<GunnarHj> melodie: Hmm... right now is probably a bad time to install a language. You'll probably see what I mean. :(
<melodie> I got a dbus error but I neglected it
<melodie> and that worked
<melodie> I am adding an additional package so that it stops reminding me it is missing...
<melodie> there is no option to dismiss it definitely, so...
<GunnarHj> melodie: Did you succeed in installing a language on an updated Raring?
<melodie> my work box is based on Precise
<melodie> ^^
<GunnarHj> melodie: Aha, that explains it. ;-)
<melodie> when this little project will be fully finished then it will be time to move forward. :)
<GunnarHj> Ok.
<melodie> the program asked me to install gimp-help-fr for some time now : just thinking if an option to dismiss definitely could be nice to have
<melodie> ok
<melodie> GunnarHj I might have an idea you could use:
<GunnarHj> melodie: Why do you think that would be important?
<melodie> GunnarHj let's say it is a wish : the wish to be always free to do things how we want them. If I want to install language packs, but not all of them, because let's say, I don't need gimp help, well, why does this program insist forever ? :)
<melodie> about drag and drop, here is the idea:
<melodie> just adding 'HowTo:' on a line before the rest
<melodie> in french 'Mode d'Emploi:'
<melodie> and so on...
<GunnarHj> melodie: Well, the simple answer would be that in Ubuntu languages are available on an all-or-nothing basis.
<melodie> some of the packages do take quite some space, and it can be nice to be able to choose (it might make it more complicated to deal upstream, on your side, but for people with old boxes, low disk space, or just users who prefer to go minimal, it's nice)
<GunnarHj> melodie: About the "HowTo" idea: There is a "Help" button at the bottom of the window.
<melodie> GunnarHj this is right however it takes to install yelp... whereas the suggest I submit takes a few caracters to add
<melodie> let me see how much adding yelp there brings in with depends...
<melodie> it will bring in 27.2 Mo.
<melodie> I check in the build directory of the project too...
<GunnarHj> melodie: Actually the language support used to be more like you would like it. It was simplified a while ago, and changing it back would be non-trivial.
<melodie> I get that
<GunnarHj> melodie: Why are you so worried about disk space? Is that really an issue for you?
<cjwatson> Language availability in Ubuntu is much less all-or-nothing than it used to be; I would argue that the point of check-language-support and friends was precisely to make it not all-or-nothing.
<GunnarHj> cjwatson: Yeah, in the sense that you only install the languages you need, you are right, of course.
<cjwatson> That wasn't what I meant.  It's much more fine-grained in terms of per-application packages than it used to be.
<cjwatson> In that the only supported interface used to be that of installing language-support-LL, which installed all the support packages available for a given language; now you get to select support packages according to which applications you have installed, and it's clearly within the power of the management tools to be more picky than that if they want to.
<cjwatson> Just a matter of how to handle the preferences.
<GunnarHj> cjwatson: But a few cycles ago you could check which parts of the language support you wanted to install. That possibility is no longer there.
<cjwatson> Right.  But that's a change in language-selector which you seemed to be trying to present as intrinsic to Ubuntu's language support availability.
<cjwatson> It's not - it's purely a question of the UI.
<GunnarHj> Hmm.. Have to think about that. ;-)
<cjwatson> At least, there's nothing in the support package layout to prevent that.
<GunnarHj> cjwatson: No, I agree it was a UI change. Still affecting the users' options in practice.
<melodie> GunnarHj I didn't answer your question yet : it is interesting to spare disk space whenever possible. It is also often a difficult choice to do when building a project : keep this for the sake of the comfort of the user ? Or let the final user get it by himself ? what if he doesn't even fancy it can exist ? this is why I pay systematic attention to those details.
<GunnarHj> melodie: A new UI will need to be written for language support handling when we switch to a new UI for the rest of language/locales settings. Maybe something to consider then.
<melodie> GunnarHj this is very nice
<melodie> if you can keep the idea aside...
<melodie> :)
<GunnarHj> melodie: Will try. :)
<melodie> GunnarHj thanks. :)
<xnox> wgrant: is it possible to "manually" superseed packages in test-rebuild results? e.g. with my pending tcltk-defaults uploads pidgin & ace are fixed from FTBFS.
<cjwatson> xnox: It's simpler to retry those packages in the rebuild test
<xnox> cjwatson: ah, awesome.
<wgrant> xnox: Yeah, what cjwatson said.
<mvo> cjwatson: thanks for your aptdaemon fix, shall I upload or are you on it already?
<cjwatson> mvo: already uploaded
<mvo> ta
<cjwatson> Since I was pretty certain of it
<davmor2> mvo: how do
<mvo> cjwatson: yeah, totally
<mvo> davmor2: good, thanks! and you?
<davmor2> mvo: good, busy but that is good too :)
<doko> xnox, did you give up with the Tcl/Tk multiarch thing?
<xnox> doko: I didn't give up, just put in place compat shell script that can be sourced -> calls dpkg-architectures and chain sources the correct one.
<xnox> doko: I'm not planning on spending my time fixing universe, when I can do it once and fix it for $most packages.
<seb128> xnox, is that for tclConfig.sh changing path?
<xnox> seb128: yes.
<seb128> xnox, how is your fix working? does it mean I don't need to fix pidgin? ;-)
<xnox> seb128: no need to fix pidgin. Pidgin will works out-of-the-box with fix in-place. (tested locally as one of the guinea pig packages)
<doko> seb128, glib2.0 did fail again in raring on armhf
<seb128> doko, it's weird, the same version built fine in debian and raring last week
<doko> TEST: gdbus-close-pending... (pid=27574)
<doko>   /gdbus/close-pending:
<doko> (/build/buildd/glib2.0-2.36.0/debian/build/deb/gio/tests/.libs/lt-gdbus-close-pending:27574): GLib-CRITICAL **: g_main_context_wakeup: assertion `g_atomic_int_get (&context->ref_count) > 0' failed
<doko> FAIL
<doko> GTester: last random seed: R02S9237789288b283d4b059cc2abb315517
<doko> /bin/bash: line 1: 19034 Terminated              G_DEBUG=gc-friendly MALLOC_CHECK_=2 MALLOC_PERTURB_=$((${RANDOM:-256} % 256)) dbus-launch ../../glib/gtester --verbose io-stream memory-input-stream memory-output-stream readwrite g-file g-file-info converter-stream data-input-stream data-output-stream g-icon buffered-input-stream buffered-output-stream sleepy-stream filter-streams volumemonitor simple-async-result srvtarget contex
<doko> ts gsettings gschema-compile async-close-output-stream gdbus-addresses network-address gdbus-message socket pollable tls-certificate tls-interaction cancellable vfs network-monitor fileattributematcher resources proxy-test simple-proxy inet-address permission task credentials actions gdbus-connection gdbus-connection-loss gdbus-connection-slow gdbus-names gdbus-proxy gdbus-proxy-threads gdbus-proxy-well-known-name gdbus-introspec
<doko> tion gdbus-threading gdbus-export gdbus-error gdbus-bz627724 gmenumodel gdbus-close-pending gdbus-connection-flush gdbus-peer gdbus-exit-on-close gdbus-non-socket gdbus-peer-object-manager appinfo contenttype mimeapps file live-g-file desktop-app-info unix-fd unix-streams gapplication basic-application gdbus-test-codegen gdbus-auth
<doko> make[7]: *** [test-nonrecursive] Error 143
<doko> make[7]: Target `check-local' not remade because of errors.
<doko> make[7]: Leaving directory `/build/buildd/glib2.0-2.36.0/debian/build/deb/gio/tests'
<doko> make[6]: *** [check-am] Error 2
<doko> make[6]: Leaving directory `/build/buildd/glib2.0-2.36.0/debian/build/deb/gio/tests'
<doko> make[5]: *** [check-recursive] Error 1
<doko> make[5]: Leaving directory `/build/buildd/glib2.0-2.36.0/debian/build/deb/gio/tests'
<doko> make[4]: *** [check] Error 2
<doko> make[4]: Le
 * seb128 hands a pastebin to doko
 * doko hands seb128 https://launchpadlibrarian.net/135923939/buildlog_ubuntu-raring-armhf.glib2.0_2.36.0-1ubuntu1_FAILEDTOBUILD.txt.gz
<seb128> doko, thanks
<seb128> doko, what builds are used there? is that a normal/real builders or is that a qemu/virtual one?
<tkamppeter> Anyone can help me with a problem caused by moving a conffile from one binary package to another? Bug 1162164
<ubottu> bug 1162164 in cups (Ubuntu) "during installation of kubuntu 13.04 alpha1 on an older hardware system from 2007/2008 in the middle crash happens and kubuntu is installed only half - doesnt work" [High,New] https://launchpad.net/bugs/1162164
<doko> seb128, normal, as for every test rebuild
<desrt> how many CPUs are being emulated?
<desrt> in the builder....
<desrt> ie: is it emulating SMP or no?
<seb128> desrt, doko is saying that's a normal builder and not a virtual one
<seb128> doko, it's weird that we never hit that issue on the normal archive uploads
<desrt> is it possible that the normal archive builders were single-core and this builder is multi-core?
<desrt> the testcase is testing concurrency issues and the critical is on an atomic update of a refcount.... if that doesn't scream 'threading bug' i don't know what does
<doko> afaik, all of these are configured for parallel=2 (or 3), just print DEB_BUILD_OPTIONS
<desrt> doko: the build options are not interesting.  it's the hardware that is.
<desrt> the testcases are run serially....
<doko> desrt, well, then disable parallel tests
<desrt> but they have threads
<desrt> which is kinda the point... we want to test that our threading is working properly
<xnox> tkamppeter: the best you can do is "Replaces: cups (<< 1.6.2-1ubuntu3)" in the "cups-daemon" package. There is no sane way to "unown" and "reclaim ownership" on a conffile and thus move it to a new binary package.
<xnox> tkamppeter: where the version is the first one of package cups that does _not_ have /etc/init/cups.conf
<desrt> does anyone know how many cores this builder has?
<doko> desrt, these are all pandas, so two
<desrt> and the other builders on which the build worked?  also two?
<doko> <doko> desrt, these are all pandas, so two
<xnox> desrt: we have procenv package that a build time does a lot system detection and prints a lot of interesting info. See https://launchpadlibrarian.net/126054733/buildlog_ubuntu-raring-armhf.procenv_0.19-1_BUILDING.txt.gz
<desrt> seb128: we should have this in all our builds :)
<cjwatson> xnox: are you certain that aleya and mothallah are identical hardware?  (I'm not)
<seb128> desrt, did you find the bug?
<desrt> seb128: no.  i don't even have an idea for the basis of the bug.
<xnox> cjwatson: let me check what other builds of procenv we have in the history...
<cjwatson> I checked, don't see one on mothallah.  it's probably quicker to ask webops.
<seb128> doko, is there any way to throw a debug version of the package to the builder if we get one?
<doko> seb128, upload to a non-virtualized ppa and make it build on armhf only?
<ogra_> seb128, want access to the canonical-arm-dev PPA ?
<seb128> ogra_, that could be handy but I don't have a strong need for it either, your call
<ogra_> well, for doing testbuilds it might help
<ogra_> it is real hardware ...
<seb128> ogra_, can you get me added?
<ogra_> seb128, done
<seb128> ogra_, thanks
<bdmurray> jodh: is there a ppa with a fix for bug 1163103?
<ubottu> bug 1163103 in upstart (Ubuntu) "upstart file bridge: "unable to write pid file"" [Undecided,Triaged] https://launchpad.net/bugs/1163103
<jodh> bdmurray: not atm. It wasn't clear from the bug, but if that message is the only issue, ignore it - it's harmless.
<bdmurray> jodh: oh, so it should still work then?
<jodh> bdmurray: I certainly hope so :)
<jodh> bdmurray: the problem is that the nih calls we're making assume the daemon is running as root. and it isn't :)
<xnox> jodh: should be using XDG_RUNTIME_DIR for pid files as a user =)
<bdmurray> jodh: and where is it logging?
<jodh> xnox: the bridge now does, but NIH isn't xdg-aware yet alas :)
<tkamppeter> xnox, thank you very much, strange is the message "trying to overwrite '/etc/init/cups.conf', which is also in package cups 1.6.2-1ubuntu3" as I have checked on my box and cups 1.6.2-1ubuntu3 does not contain /etc/init/cups.conf.
<jodh> bdmurray: as of now, syslog (erroneously). The issue is fixed in upstream such that it'll log to stdout and thus end up in ~/.cache/upstart/upstart-file-bridge.log.
<xnox> tkamppeter: correct, it doesn't exist on fresh installs. One must upgrade from the time when it did. =) I recently had to deal with a broken conffile dating back to hardy times =))))
<tkamppeter> xnox, I have also checked http://packages.ubuntu.com/search?suite=raring&arch=any&searchon=contents&keywords=%2Fetc%2Finit%2Fcups.conf and only cups-daemon provides /etc/init/cups.conf, independent of the architecture.
<doko> zul: are these server uploads (rc2) needed for the beta?
<zul> doko:  when is the beta out again?
<xnox> tkamppeter: sure, but in quantal it was in the cups package. So anyone upgrading from quantal or before, and had that conffile for example modified, it will be there causing upgrade conflict.
<doko> zul: Thursday?
<tkamppeter> xnox, and cups-daemon contains "Replaces: cups (<< 1.6.1-1~)".
<xnox> tkamppeter: yeah, noticed.
<zul> doko:  yeah i think they would be nice to have
<doko> zul: could you note in the MIR issue, why cinder/nova need python-babel?
<zul> doko:  i reopened the MIR that was previously opened but babel causes this bug when its not installed https://bugs.launchpad.net/ubuntu/+source/cinder/+bug/1126378
<ubottu> Launchpad bug 1126378 in cinder (Ubuntu Raring) "SchedulerHostFilterNotFound: Scheduler Host Filter AvailabilityZoneFilter, CapacityFilter, CapabilitiesFilter could not be found." [High,Fix committed]
<xnox> tkamppeter: hmmm... it looks like it could be a bug in apt-clone restore (used to upgrade using the desktop cd, as shown in the bug report)
<doko> zul: could you add this info in 941913?
<zul> doko:  ack
<zul> doko:  done
<tkamppeter> xnox, should I reassign this bug to apt-clone
<xnox> tkamppeter: not sure, needs testing.
<xnox> (reproducer)
<xnox> tkamppeter: potentially cups may have to move the conffile out of the way....
<tkamppeter> xnox, the conffile is /etc/init/cups.conf before and after, how should CUPS move it? Let pre-inst of cups-daemon rename it and post-inst of cups-daemon move it back overwriting the new cups.conf of cups-daemon?
<xnox> tkamppeter: you should use rm_conffile on /etc/init/cups.conf in the cups package just like there are for the rest of conffiles.
<xnox> tkamppeter: that way it will be removed and it will be "resurrected" afresh with no baggage by cups-daemon.
<xnox> tkamppeter: also see http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=672945
<ubottu> Debian bug 672945 in dpkg "dpkg should support moving a conffile between packages" [Wishlist,Open]
<slangasek> "support moving a conffile between packages" - that's called "Replaces:"?
<xnox> slangasek: not really, as the conffile stays allocated to the previous package and even with replaces dpkg does not unpack the new one. See tkamppeter's raised issue in bug  https://launchpad.net/bugs/1162164
<ubottu> Launchpad bug 1162164 in cups (Ubuntu) "during installation of kubuntu 13.04 alpha1 on an older hardware system from 2007/2008 in the middle crash happens and kubuntu is installed only half - doesnt work" [High,Incomplete]
<doko> slangasek, could you have a look at https://launchpad.net/ubuntu/+archive/test-rebuild-20130329/+build/4438112 ? you seem to know the maintainer
<xnox> slangasek: or is the problem here, that we have a too strictly versioned Replaces?
<BenC> cjwatson: Is there a way to make the ISO installer initrd check for install media on non-removable disks as well (e.g. hd partition)?
<doko> afaik, we can't migrate config files between packages
<BenC> I ask because virtio-blk doesn't show up as removable even when media=cdrom on qemu
<ogra_> unless "Replaces" suddenly started secretly using dpkg-maintscript-helper
<blitzkrieg3> would someone please sponsor bug 861171?
<ubottu> bug 861171 in indicator-session (Ubuntu) "Shutdown from greeter does nothing when multiple accounts open" [High,In progress] https://launchpad.net/bugs/861171
<tkamppeter> xnox, but if I use rm_conffile in cups, does this happen before cups-daemon installes cups.conf? Or can it happen I end up without cups.conf at all?
<stgraber> cjwatson: DMB meeting minutes in the ubuntu-devel-announce moderation queue for when you have a minute
<cjwatson> stgraber: done
<xnox> tkamppeter: cups' preinst will move cups.conf out of the way, cups-daemon postinst will put cups.conf in place. If dpkg still barks at you (it shouldn't as far as I remember), then cups-daemon will need a Pre-Depends: cups (at least the first version that did not have cups.conf)
<stgraber> cjwatson: thanks
<xnox> tkamppeter: there will be a window of no cups.conf on disk and depending on the options to dh_installinit it may be stopped as well while the upgrades are in progress.
<slangasek> xnox: the conffile is still attached to the previous package, but is *also* attached to the new package and a subsequent upgrade of the old package fixes up the dpkg database; and regardless of which package it's associated with in the database, TTBOMK the user-visible *behavior* is what we want/expect
<slangasek> doko: "know the maintainer" - you mean I touched it last? :)
<slangasek> tkamppeter, xnox: I strongly disagree that rm_conffile is warranted here - reparenting of conffiles via Replaces: has been working for years
<slangasek> and if it's not working now, we should figure out why and address it
<doko> nm, seb did fix it
<xnox> tkamppeter: in that case the version number should be higher in the "Replaces" field. It should be same or lower than current cups source package. All the way until next lts.
<slangasek> doko: that "nm" is to me?
<slangasek> xnox: it should only need to declare Replaces: on the last version of cups that shipped the conffile
<xnox> slangasek: in the linked error log, the unpack of packageB claims that conffile is still present in packageA off the versionNew.
<xnox> s/off/of/
<slangasek> xnox: I haven't seen this link
<slangasek> link me? :)
<xnox> <xnox> slangasek: not really, as the conffile stays allocated to the previous package and even with replaces dpkg does not unpack the new one. See tkamppeter's raised issue in bug  https://launchpad.net/bugs/1162164
<ubottu> Launchpad bug 1162164 in cups (Ubuntu) "during installation of kubuntu 13.04 alpha1 on an older hardware system from 2007/2008 in the middle crash happens and kubuntu is installed only half - doesnt work" [High,Incomplete]
<xnox> slangasek: I did at 16:14 Oxfordshire time ^^^^
<xnox> =)
<slangasek> xnox: ah, k :)
<infinity> rbasak: What was that contentless ping about?
<rbasak> infinity: sorry. +1 maintenance. It's April.
<infinity> It sure is.
<infinity> In a meeting right now, sec.
<tkamppeter> xnox, so you mean that any version of cups-daemon N should have Replaces: cups (<< N)?
<rbasak> np
<xnox> tkamppeter: (<= N)
<tkamppeter> xnox, so cupsa-daemon should also replace cups of the same source package version?
<tkamppeter> xnox, cups needs cups-daemon.
<xnox> tkamppeter: yeah or less.
<xnox> *sigh*
<xnox> tkamppeter: either get a real solution from slangasek =) or use rm_conffile as my original idea is. Since afaik there is no sane way to "move" a conffile from one package to the other.
<tkamppeter> xnox, so should I assign the bug to slanagasek (and perhaps also add a dpkg task)?
<tkamppeter> s/slanagasek/slangasek/
<xnox> =)))) we should get a simple reproducer of it in a chroot first.
<xnox> cause that's the first thing that will slangasek ask for before punting it into "incomplete" state =)
<doko> chasing this bus error building libx11 docs on i386 ... can't reproduce it in a script :-/
<slangasek> xnox, tkamppeter: right, because I just tested in a quantal chroot with dpkg --auto-deconfigure -i /path/to/cups-daemon.deb, and I don't see this error at all
<slangasek> xnox, tkamppeter: if anything, this looks like a possible corrupted dpkg db on the affected system - I strongly counsel against elaborate maintainer script hacks if we only have one report and it's not reproducible
<xnox> right, I shall quickly install quantal and then use raring cd to upgrade, as this is how the bug report is filed.
 * xnox loves that utah command can just do this for me in the background (download & do a default quantal install)
<tkamppeter> xnox, slangasek, I am still waiting for answers of the reporter what he exactly did. I did a fresh installation of Raring for i386 on a 7 year old laptop this weekend and it worked perfectly.
<slangasek> indeed
<melodie> is it xdg-users-dirs-gtk which creates the default directories in the accounts of new created users at first login ?
<dobey> melodie: probably. i think that's what asks if the user wants them moved, when a different locale is selected and the user logs in
<melodie> dobey what about this issue ? https://bugs.launchpad.net/ubuntu/+source/xdg-user-dirs-gtk/+bug/1163043
<ubottu> Launchpad bug 1163043 in xdg-user-dirs-gtk (Ubuntu) "Directory Desktop stays in English in the Live CD's" [Low,New]
<melodie> hi dobey btw... :)
<melodie> I'll be back in one hour or so, need to go out now.
<melodie> I'll be back and stay connected
<dobey> hi. i don't know about that bug. i guess it's a bug though. seems it does that for multiple directories, not just 'Desktop'
<melodie> dobey no, only Desktop (at least when switching from English to French)
<melodie> dobey you could look at the screenshots I pointed to and you will see that
<dobey> oh, i didn't realize "documents" was the french version as well. anyway, seb already marked the bug as low priority 7 hours ago, not sure why you need to ask about it in here
<infinity> rbasak: So, if you're looking for things to tackle, the FTBFS list (prioritizing on current failures in the archive, and when those are done and/or too hard, moving on to doko's rebuild test) would be a great place to go.
<dobey> if he thought it was filed in the wrong place, he would have moved it
<infinity> rbasak: And feel free to just toss up debdiff on some web space or other and aim me at the lot for review/sponsorship/etc.
<doko> infinity, the current ftbfs list is empty ;-P
<infinity> doko: You have a weird definition of empty.
<ogra_> doko, what did you do ? break the backend ?
<melodie> dobey just because I wonder if this is related with the other question I asked just before:
<melodie> <melodie> is it xdg-users-dirs-gtk which creates the default directories in the accounts of new created users at first login ?
<doko> infinity, well, main
<infinity> doko: +1 maint isn't just main.
<rbasak> infinity: I tried going through doko's rebuild test this morning, but couldn't see any easy way of not duplicating work of people who are way ahead (doko, xnox).
<infinity> Though, very few of those universe failures are likely to be fixable before release.
<melodie> dobey someone will help me with a script and asked what script creates the new directories for each new user : this is why I am asking here where the knowledge is :)
<xnox> infinity: rbasak: I did upload a compat tcltk which should resolve a fair amount of FTBFS.
<infinity> rbasak: Helping Laney unsnag his ghc transition pain before release might be nice too.
<rbasak> I'm happy to take some packages to fix if I know I won't get trumped
<rbasak> (and I'll be on IRC)
<xnox> rbasak: you could be untangling ghc transition, there is an active BigIndian bug blocking a fair chunk of stuff. cjwatson has started poking it, but maybe you'd also be able to fix it.
<rbasak> What's the bug?
<infinity> rbasak: Which could be in the form of fixing a bug or three, or identifying leaf nodes or small branches we can prune from broken arches to smooth things.
<xnox> although it looks like cjwatson was doing test-build with the fix already for that =/
<rbasak> xnox: see what I mean? :)
<cjwatson> Yeah, I'm working on haskell-cipher-aes/powerpc
<infinity> cjwatson: Oh, did you need leviathan back for that? :P
<rbasak> Right now my biggest personal blocker is that I feel that I'll waste effort
<cjwatson> infinity: Maybe, if I fail to zen it with PPAs
<infinity> cjwatson: I'll just turn it on, and you can let me know if you didn't need it.
<xnox> rbasak: this is a good list to work off: http://qa.ubuntuwire.com/ftbfs/
<infinity> I need to test BenC's latest kernel anyway.
<xnox> but it's mostly universe atm.
<ogra_> rbasak, there is a whole universe full of armhf FTBFS and you have the fast hw ;)
<cjwatson> rbasak: I started late last month, so I'm letting myself run late too.  I'll probably be out of your way in a few days.
<cjwatson> rbasak: But, well, just ask
<cjwatson> rbasak: haskell-* probably has a horrible learning curve.  You might be better off looking at other things in general ...
<cjwatson> Unless it's something you already happen to be familiar with
<doko> rbasak, maybe leave a message in +1-maint what you're working on
<cjwatson> infinity: Yeah, I think I will need to work through this on leviathan; I'm not quite enough of a savant to be able to guess it, apparently :P
<cjwatson> Though I'm pretty sure I'm in the right area.
<Whoopie> debfx: Thanks for the virtualbox update. Works great now under raring and precise.
<infinity> cjwatson: Alright, let me upgrade and reboot into the new kernel before you get busy with chroots you don't want me eating.
<infinity> cjwatson: Or am I too late? :)
<cjwatson> infinity: No, go ahead
<ahasenack> guys, just wondering, I'm having crashes every 5min or so in X, and I'm reporting them. I'm on Quantal. Is something widespread going on, or is it just me?
<ahasenack> no nvidia, just plain intel
<xnox> tkamppeter: slangasek: did ubiquity based upgrade off quantal and despite scary messages it did complete fine without cups errors.
<slangasek> xnox: does the log show cups-daemon being unpacked before cups?
<slangasek> (if not, it's not a complete rule-out)
<xnox> slangasek: cups-daemon is unpacked before cups.
<slangasek> ok
<slangasek> so, whatever was happening in that bug report, it doesn't give much evidence that dpkg is broken :)
<infinity> cjwatson: Okay, all upgraded.
<mitya57> ahasenack: do you have a bug number?
<cjwatson> awesomesocks
<ahasenack> mitya57: apport didn't give me one
<ahasenack> mitya57: I don't know where it's uploading this stuff to, but I have probably dozens already
<ahasenack> 5 just today
<xvzf> hi there, what is an "upstream d-i repository"?
<cjwatson> xvzf: d-i is the debian-installer project.  What's the context for your question?
<xvzf> cjwatson: Hi Colin, I'm Gergely, and we exchanged e-mail about the kickseed project. Your answer contained this expression and I didn't have the clue what it is. It is now clear.
<mitya57> ahasenack: ah, it goes to errors.ubuntu.com then
 * mitya57 doesn't have access there, so somebody else should look
<cjwatson> xvzf: OK.  http://anonscm.debian.org/gitweb/?p=d-i/kickseed.git specifically
<slangasek> ev: do we have cross-retracers in launchpad now, or only for errors?
<ahasenack> mitya57: it could be https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/1159536 ranked at number 6 currently
<ubottu> Launchpad bug 1159536 in xserver-xorg-video-intel (Ubuntu) "[sandybridge-m-gt2] False GPU lockup IPEHR: 0x23002000 IPEHR: 0x0b140001" [Undecided,Fix released]
 * xnox realises I should have been off to volleyball 30 minutes ago....
<ahasenack> I don't understand why it's marked "fix released", the comment that changed that says "TLB invalidate bug."
<mitya57> ahasenack: try asking on #ubuntu-x please
<ahasenack> mitya57: ok, thanks
<Sarvatt> ahasenack: the upstream intel developer did that, you're hitting https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1140716/ which is a regression in the last 2 quantal and precise kernel updates that just got narrowed down tho the stable update that broke it
<ubottu> Launchpad bug 1140716 in linux (Ubuntu Raring) "[regression] 3.5.0-26-generic GPU hangs" [Critical,Confirmed]
<ahasenack> Sarvatt: ah, good to know, thanks for the pointer
<mitya57> can anybody please mark https://code.launchpad.net/~lqs/ubuntu/precise/uwsgi/fix-for-1131314/+merge/152324 as WIP?
<xvzf> join #fedora
 * xvzf misses a slash...
<asac> anyone heard that recent linux stable kernel update in precise might have caused problems for iwlwifi users? I rebootted today and I cannot connect to my wifi anymore :/
<asac> err .. .actually i am on quantal :)
<asac> mac80211: fix FT roaming
<asac> mac80211: synchronize scan off/on-channel and PS states
<asac> thats all i found that could be relevant
<asac> iwlegacy: fix IBSS cleanup
<asac> ok will observe a bit more :)
<infinity> asac: You might want #ubuntu-kernel
<bdmurray> mterry: based off the volume of reports on errors about bug 1056545 I think it is worth fixing in Q
<ubottu> bug 1056545 in sessioninstaller (Ubuntu Quantal) "session-installer crashed with AlreadyCalledDeferred in callback()" [High,Triaged] https://launchpad.net/bugs/1056545
<mterry> bdmurray, sure, OK
<ev> slangasek: Looking at ~ubuntu-archive on osageorange, it looks like apport is running the right revno for that and there are logs for armhf, but pitti could say for certain
<slangasek> ev: ok.  it was actually powerpc I was interested in in this case, maybe armhf is set up but powerpc not?
<seb128> slangasek, we don't have ppc retracers afaik
<slangasek> seb128: ok, but we have cross-retracer capabilities
<seb128> slangasek, the number of users didn't make it worth the maintenance cost
<slangasek> so why aren't we using the cross-retracing for powerpc :)
<seb128> because nobody allocated the time/resources to set it up/maintain it? ;-)
<seb128> though that's probably a lower cost since pitti reworked the system to not use chroots with a full system to update daily and keep working
<ev> slangasek, seb128: for what it's worth, we don't appear to have ever received core files for powerpc on daisy.ubuntu.com. Just amd64, i386, armhf, and armel.
<slangasek> ev: fair enough.  Bug #1162692 for an example of a bug missing retracing.
<ubottu> bug 1162692 in plymouth (Ubuntu) "Failed removal of gnome desktop environment - plymouth error" [Undecided,New] https://launchpad.net/bugs/1162692
<ev> hm, strange that we didn't get that on daisy
<ev> whoopsie successfully builds on ppc, but I wonder if it successfully runs :)
<slangasek> ev: so what happens if I just add a 'powerpc' stanza on osageorange?
<slangasek> arges: bug #1157678, "SRUed to other series" - are you actually seeing this issue anywhere outside of raring?  This is definitely a new problem in raring for me
<ubottu> bug 1157678 in xserver-xorg-video-intel (Ubuntu) "unplugging an external monitor from laptop results in corrupted screen. Logging out fixes it." [Medium,In progress] https://launchpad.net/bugs/1157678
<arges> slangasek: i should have added 'IF it affects other series' I've only seen it on raring as well.
<slangasek> ok
<slangasek> ev: apparently the answer is "a whole lot of nothing" because we don't have powerpc on ddebs.u.c
<mterry> bdmurray, uploaded quantal version of sessioninstaller too
<bdmurray> mterry: thanks, I'll approve it soon
<saiarcot895> hi
<saiarcot895> could someone sponsor the merges in LP Bug 1077624 (https://bugs.launchpad.net/ubuntu/+source/flightgear/+bug/1077624) for me?
<ubottu> Launchpad bug 1077624 in simgear (Ubuntu) "Raring: Update Flightgear to version 2.10.0" [Wishlist,Triaged]
<TheLordOfTime> wasn't raring frozen?
<saiarcot895> it is, but I thought that once beta was released, the status goes back to Feature Freeze
<saiarcot895> do I have to wait till the beta is released?
<TheLordOfTime> i'm not sure, but I have a question about the freeze that was announced just over two hours ago.
<jtaylor> the freeze only affects seeded packages
<TheLordOfTime> but it's not important :P
<infinity> saiarcot895: You don't have to wait for the beta to be released, no.
<infinity> TheLordOfTime: What's your question?
<TheLordOfTime> infinity, nevermind, i found the answer myself :P
<infinity> Fair enough.  Then I can go have lunch instead.
<saiarcot895> ok
<melodie> good night
<bdmurray> xnox: bug 1159023 should really be about those three separate packages right?
<ubottu> bug 1159023 in app-install-data-ubuntu (Ubuntu) "File .. could not be read correctly: sonic-visualizer, gmpc, workrave" [Undecided,Confirmed] https://launchpad.net/bugs/1159023
<bdmurray> okay, I sorted that out myself
<xnox> bdmurray: yeap. Just open a task for each one. I think desktop-* something has a checker to run against them.
<xnox> bdmurray: ok =)
<sarnold> thanks bdmurray :)
<xnox> I fixed gmpc recently.
<bdmurray> xnox: yes, I discovered that in my research
#ubuntu-devel 2013-04-03
<slangasek> Logan_: fwiw you really shouldn't file bugs at severity: serious in Debian for build failures only reproduced in Ubuntu (Debian bug #704572). :)
<ubottu> Debian bug 704572 in freetds "freetds: Add -lgcrypt to LDFLAGS to fix underlinking" [Serious,Open] http://bugs.debian.org/704572
<Logan_> slangasek: Ooops. :P What's the appropriate priority?
<StevenK> important
<StevenK> Justification being it might well bite Debian soonish
<slangasek> right - or if it's reproducible with a toolchain in experimental, serious+tags: experimental is ok, preferably with a usertag we can use to find it again later
<pitti> Good morning
<sarnold> good morning pitti :) I just found fatrace today. awesome. thanks. :D
<vibhav> good morning
<pitti> sarnold: :)
<dholbach> good morning
<didrocks> hey dholbach!
<didrocks> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Ubuntu 12.10 released | Archive: Final Beta Freeze | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of hardy -> quantal | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: didrocks
<dholbach> salut didrocks
 * dholbach hugs didrocks
 * didrocks hugs dholbach back
<doko> infinity, could you forward 1154599? is this change intended?
<jibel> pitti, could you have a look at bug 985049 ? the obvious fix is to re.escape the gecos bits but I am not sure that it will not break the replacement.
<ubottu> bug 985049 in apport (Ubuntu) "apport crashed with error in report.py in anonymize(): nothing to repeat - if GECOS field contains regular expression metacharacters" [High,Triaged] https://launchpad.net/bugs/985049
<pitti> jibel: merci, will do
<pitti> jibel: that's covered by tests, I'll add a new one for RE chars in gecos
<ev> slangasek: ha!
<doko> achiang, could you have a look at https://launchpad.net/ubuntu/+archive/test-rebuild-20130329/+build/4442990 ?
<geser> xnox: is the compat tclConfig.sh 'transitional' (till most packages got fixed) or is it going to stay for a long time?
<doko> geser, I'd like to see a plan for Debian ...
<xnox> geser: what doko said really. I will forward it to Debian.
<xnox> it's up to them to decide.
<doko> xnox, see my comment in the report, and maybe cc wookey
<doko> dobey, could you have a look at https://launchpad.net/ubuntu/+archive/test-rebuild-20130329/+build/4448145 ?
<xnox> doko: what report?! =)
<doko> xnox, bug 1122120
<ubottu> bug 1122120 in tk8.6 (Ubuntu) "Multiarchify tcl8.5" [Low,Triaged] https://launchpad.net/bugs/1122120
<xnox> doko: saw that. I tend to agree with colin. Separate bug + low priority. I will not work on that at the moment. Maybe debian folks can do that =)
<doko> pitti, could you have a look at bug 1163786, gir related ftbfs
<ubottu> bug 1163786 in gcr (Ubuntu Raring) "gcr ftbfs in raring" [High,Confirmed] https://launchpad.net/bugs/1163786
<pitti> doko: ack
<seb128> pitti, there are quite a bunch of those (though some already got fixed)
<doko> right, bamf is another one
<seb128> pitti, somewhat it shows that updating the "stack" component and not updating GNOME on top creates issues as well
<seb128> not that it's specific to GNOME, but when we update the whole we get a good part of the build fixes with it
<xnox> doko: seb128: bamf is fixed in lp:bamf, and for some reason it's not autolanding....
<xnox> didrocks: why is bamf not autolanding? we want the FTBFS fixes from lp:bamf =)
<didrocks> xnox: unity integration tests failed
<didrocks> ah sorry, it's in the indicator stack
<didrocks> xnox: cyphermox needs to publish manually the indicator stacks
<didrocks> because there are packaging changes
<didrocks> and see the posts on autolanding, we don't land stuff automatically when there are packaging changes
<didrocks> we need someone with upload rights "acking" for the changes
<didrocks> see https://jenkins.qa.ubuntu.com/view/cu2d/view/Raring/view/Indicators/job/cu2d-indicators-raring-3.0publish/
<xnox> didrocks: to be honest, I read the first one and skimmed through the rest =)
<didrocks> xnox: so ensure cyphermox is reviewing the change today and publish
<pitti> jibel: I fixed that apport crash, and added new tests for this
 * pitti looks at gcr
<pitti> seb128: yeah, GLib.Object doesn't make any sense
<pitti> looks like https://git.gnome.org/browse/gcr/commit/?id=0b8893 will fix it, checking
<jibel> pitti, thanks
<seb128> pitti, ah, that issue is different from the lightdm/bamf ones
<cjwatson> didrocks: the nvidia-cuda-toolkit you sponsored has a typo ("nvdidia" in one place in debian/control).  Do you think you could do a quick reupload with that fixed?
<didrocks> cjwatson: oh sure, didn't notice, sorry about it, doing now
<cjwatson> didrocks: thanks, I thought it'd be better this way than cycling round with the sponsoree
<didrocks> cjwatson: agreed ;) and especially for downloading a source of 900+MB ;)
<alkisg> Hi, just to verify that this isn't a regression: it's still true that one cannot use fuse filesystems like sshfs and ltspfs if he's not in the fuse group, right?
<doko> hmm, I remember I did want remove mozilla-gnome-keyring, but I can't remember anymore why ...
<didrocks> cjwatson: done
<OdyX> tkamppeter_: I have uploaded cups-filters 1.0.31-1 to Debian experimental, including all the Ubuntu changes + some more cleanup (move to debian-printing team, section/prio cleanup, symbols for libfontembed, â¦). You probably need to wait some hours if you want to sync that version.
<didrocks> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Ubuntu 12.10 released | Archive: Final Beta Freeze | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of hardy -> quantal | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<pitti> doko: ah, gcr fix caught in unapproved, but I guess it'll get accepted soon
<doko> cjwatson, still ok to accept the ftbfs fixes in main?
<cjwatson> doko: since beta's in preparation, check with infinity before touching anything on images
<cjwatson> (and if he isn't around, please wait)
<doko> ok
<pitti> xnox: are you on bug 1163293? your last comment sounds like it
<ubottu> bug 1163293 in ubuntu-defaults-builder (Ubuntu) "FTBFS due to obsolete standards version" [Wishlist,Confirmed] https://launchpad.net/bugs/1163293
<xnox> pitti: i thought i uploaded that.... let me check
<pitti> not in unapproved
<xnox> pitti: added a comment. I did fix it for 3.9.4, but I'd rather get it fixed for "real", e.g. parse & find out the latest standards version and use that in the templates always, by default.
<pitti> ah, ok
<xnox> bug 1163293
<ubottu> bug 1163293 in ubuntu-defaults-builder (Ubuntu) "Should always use latest standards version in the template, instead of hard-coding it." [Wishlist,Confirmed] https://launchpad.net/bugs/1163293
<xnox> =) much better now.
<doko> pitti, https://launchpad.net/ubuntu/+source/libgda5/5.0.3-2/+build/3936951 (universe, however)
<pitti> didrocks: would you know what "python unityquantal.py" would be?
<pitti> didrocks: looking at bug 1160448
<ubottu> bug 1160448 in pygobject (Ubuntu) "python2.7 crashed with signal 5 in g_object_newv()" [Undecided,New] https://launchpad.net/bugs/1160448
<didrocks> pitti: I have never seen that file :)
<didrocks> let me look at the bug
<pitti> didrocks: ok, thanks
<pitti> didrocks: there's not much in it, nevermind
<didrocks> pitti: ok, yeah, I can just say it's not something we ship by default
<pitti> didrocks: I updated the bug, thanks!
<didrocks> yw :)
<doko> xnox, https://launchpad.net/ubuntu/+archive/test-rebuild-20130329/+build/4424035 and https://launchpad.net/ubuntu/+archive/test-rebuild-20130329/+build/4424038
<doko> these use the versioned tcl/tk packages explicitly
<xnox> dbarth: mterry (who is not here) barry: bug 1119279 either StringIO stopped accepting bytes, or PyCurl switched to writting bytes (from previously writting py3 strings) which is a bug or a bugfix, and hence thin-client-config-agent is at the moment broken in raring.
<ubottu> bug 1152222 in thin-client-config-agent (Ubuntu) "duplicate for #1119279 thin-client-config-agent fails in pycurl with TypeError: string argument expected, got 'bytes'" [High,Confirmed] https://launchpad.net/bugs/1152222
<xnox> imho switching to bytes over-the-wire explicitly is the right solution here.... as proposed in https://code.launchpad.net/~xnox/ubuntu/raring/thin-client-config-agent/fix-1152222/+merge/156801
<xnox> doko: ok. but why? =) can't they just use a default one....
<xnox> oh, no, it's tied to versions. ok.
<xnox> i guess it also needs multiarching...
<xnox> infinity: doko: also pidgin upload was not necessary as the compat tcltk scripts got uploaded by then already.
<doko> does somebody know the nick of Logan Rosen?
<cjwatson> LoganCloud_ I think
<doko> LoganCloud_, your xf86-video-msm upload
<doko> xf86-video-msm (1.0.1+git20100122.5f7df591-3ubuntu1) raring; urgency=low
<doko>   * No-change rebuild for Ubuntu.
<doko>  -- Logan Rosen <logan@ubuntu.com>  Wed, 27 Mar 2013 20:31:51 -0400
<doko> maybe No-change, but not merging the ubuntu patches is bad
 * cjwatson defeats haskell-cipher-aes/powerpc, woo
<dbarth> xnox: ok
<sunweaver> dbarth: hi
 * sunweaver 's real name is Mike Gabriel from X2Go upstream
<sunweaver> dbarth: I have today started on a patch for remote-login-service that adds protocol type "x2go" to the remote-login-service code.
<sunweaver> dbarth: I guess X2Go for raring has been postponed to later, are you still interested in including X2Go into UCCS?
<xnox> sunweaver: it is best to be included in the S-series once it opens.
<sunweaver> xnox: great.
<xnox> sunweaver: very early on, to allow extensive testing =)
<dbarth> sunweaver: hi Mike
<sunweaver> xnox: testing can already start, ppa:x2go/stable
<sunweaver> dbarth: hi David! Hope you are doing well!
<dbarth> yup, same
<dbarth> so uccs is frozen right now
<sunweaver> the X2Go project just got contracted for writing a web frontend that is compatible with the way UCCS communicats with the remote-login-service.
<dbarth> as a test drive service, not so much activity on it this cycle
<sunweaver> you mean UCCS as a concept is frozen?
<dbarth> sunweaver: the changes you made into remote-login seem a better way to enable x2go access
<dbarth> sunweaver: yup; i'm keeping it as a test drive, but no code change really; can't be on all fronts
<sunweaver> dbarth: yeah, but they hack X2Go sessions into the freerdp protocol type of remote-login-services.
<sunweaver> dbarth: sure.
<sunweaver> what X2Go is working on atm is: X2Go Session Broker
<sunweaver> the session broker of X2Go shall have a UCCS like communication protocol, so that lightdm can talk to the X2Go Session Broker
<sunweaver> thus, companies can use remote-login in LightDM, but have their own session broker (for X2Go and RDP atm).
<sunweaver> as I want to do that in a clean way, I am currently implementing a patch against the remote-login-service that makes remote-login-service aware of JSON objects of type x2go
<dbarth> sunweaver: i think that's the way to go indeed
<dbarth> xnox: just testing your fix
<sunweaver> once that is done, I will change our remote-login hack (lightdm-remote-session-x2go) to use x2go instead of freerdp as JSON object type.
<dbarth> xnox: what's the next step to land that? can i just use the bug as a way to get past the release freeze?
<sunweaver> dbarth: thanks for this short chat, I will ping you (and xnox?) once I have valid patches to propose.
<xnox> dbarth: yeah, just an upload needs to be done with that bug mentioned in the debian/changelog. If you are happy with my change, I can upload it & ping people to accept it into raring.
<dbarth> sunweaver: np, thanks for the contrib
<xnox> dbarth: that issue got raise on foundations radar to fix for raring release ;-)
<dbarth> xnox: cool
<doko> seb128, glib2.0 now built successfully on cetan
<seb128> doko, ok, do you know if there any hardware difference between the builders?
<seb128> it could also just be a flacky test
<seb128> it's weird we never hit any such issue on the archive builders though
<doko> enoclue
<dbarth> xnox: were the unit tests passing in your branch? i'm still pulling updates to verify if that's due to my system being too far behind
<xnox> dbarth: I did not run the unit-tests, I only ran the command to make sure we are not getting a traceback any more. I'd think unittests might need adjustment as well, if we are asserting PyCurl's behaviour as intended.
<pitti> apw: hey Andy, how are you?
<xnox> pitti: ev: I have a crash file generated on an offline machine. Issuing approt-cli file.crash  (a) requiried permissions to read logs (b) overwrote the report with a new one (c) upload the new report, where I was expecting it to upload the existing report.
<pitti> apw: do you know what needs to happen that a device in sysfs gets a proper driver symlink?
<pitti> apw: I'm trying to fix that in the mac80211_hwsim module, so that network-manager accepts it
<pitti> xnox: did you actually run the crash through the UI (or -cli) once on the original machine?
<pitti> xnox: it sounds like the .crash file you copied didn't have all the data collected
<xnox> pitti: I generated the crash with "apport-cli --save ubiquity.crash ubiquity
<xnox> "
<dobey> doko: did you give me the wrong build link? that i386 ubuntuone-client was a successful build. what am i supposed to be looking at?
<doko> dobey, no, retried, and then it did succeed :-/
<dobey> doko: oh. do you have a link to the failed build log?
<xnox> pitti: crash that I meant to upload is attached to bug 1163902
<ubottu> bug 1163902 in ubiquity (Ubuntu) "odly sized machines get odd partitioning" [Undecided,New] https://launchpad.net/bugs/1163902
<apw> pitti, most of the symlinks come as a result of registering things with the right busses
<doko> dobey, no, it's removed with a new build
<pitti> xnox: odd, something is very wrong there -- no Dependencies: field
<xnox> pitti: it's a ~fresh VM install with "odd" sizing (RAM >> HDD) the installation went "odd" since the partitioning was not the default. That crash is unreportable & to top things off firefox does not start.
<pitti> xnox: oh, because it's not installed
<xnox> pitti: as it is usually the case for the ubiquity hook, hence it's shipped in apport and not ubiquity package.
<pitti> xnox: so you found a corner case with uninstalled packages and saving reports
<pitti> apw: that's what I thought, as I don't see anything in other drivers that explicitly sets the "driver" symlink
 * xnox realises now, why I haven't gotten any reports from installed system after I was asking people to use apport-cli to save the report & upload it later.
<dobey> doko: ok
<xnox> pitti: so, should I open a bug against apport then?
<pitti> xnox: yes, please
<xnox> pitti: what might be even more unusual is that I do have ubiquity package installed. But nonetheless the foreign report should be uploaded verbantim.
<pitti> xnox: I think apport uses the Dependencies: field to check whether or not it needs to collect data
<dobey> xnox: btw, did we get the u1 sign-in bits into ubiquity (and enabled in raring)?
<pitti> xnox: for this special case we need some other test
<xnox> dobey: no. FFe not granted.
<xnox> dobey: not merged, not on raring CD.
<xnox> dobey: I shall be doing it early in S-series. Are the in-dash payments landing?
<dobey> i don't think so, but i know basically nothing about that. i think it might if the rebasing on unity trunk is done/tested/working
<dbarth> xnox: the fix works on my raring instance, but i'm still trying to fix the test suite as well; may take a while; i'll ping back
<xnox> dbarth: ack.
<xnox> dobey: well ubiquity plugin does not have Credit Card details input either, so some setup on the installed system will be needed upon first using the U1 in-dash features.
<dobey> xnox: well, but less work. and i don't think the ubiquity bit and the in-dash bits should be considered directly related or one dependant upon the other
 * ogra_ wonders if pitti has an idea what triggers the mount in bug 1160847 every minute 
<ubottu> bug 1160847 in gvfs (Ubuntu) "gvfs should not attempt to mount MTP devices in an endless loop (cluttering your desktop with messages)" [High,Confirmed] https://launchpad.net/bugs/1160847
<ogra_> it seems to be some lower level
<pitti> ogra_: I think running an "udevadm monitor -e --udev" during that will be interesting, to see whether there actually is a corresponding stream of added/removed/changed MTP devices or not
<ogra_> ah, good idea
<ogra_> i'll test that later today ...
<ogra_> pitti, thanks !
<dholbach> mhall119, seb128: do you have an idea who is using the sound indicators in libunity?
<mhall119> every music player
<mhall119> several webapps
<dholbach> mhall119, do you know if there's a list?
<mhall119> I don't think there is
<seb128> dholbach, mhall119: I don't know of any
<barry> xnox, doko yeah bug 1163609 is a nasty one
<ubottu> bug 1163609 in pycurl (Ubuntu Raring) "pycurl FTBFS due to segfault in test suite" [High,Triaged] https://launchpad.net/bugs/1163609
<dholbach> seb128, list you mean?
<seb128> dholbach, mhall119: most player just do mpris over dbus (rhythmbox for example)
<seb128> dholbach, I don't know of anything using libunity for sound indicator integration
<dholbach> ah ok
<seb128> dholbach, if that was your question
<dholbach> yes it was
<xnox> barry: does that mean you fixed it half an hour ago, since you have finalised your opinion of its ugliness =) ?! =)
<barry> xnox: ask me that in a half hour :)
<dbarth> xnox: https://code.launchpad.net/~dbarth/ubuntu/raring/thin-client-config-agent/further-fix-1152222/+merge/156860 should work now
<xnox> dbarth: looks good. I'll merge and upload today.
<xnox> dbarth: thanks a lot for your help!
<barry> xnox: are you still looking for a review of your thing-client mp?
<xnox> barry: for sanity, yes. https://launchpad.net/ubuntu/+source/pycurl/+changelog lists a few uploads related to str/bytes handing inside pycrypto.
<xnox> barry: but I cannot figure out what is the declared expected API for the passed write functions. bytes or strings. In quantal it was strings, in raring it is now bytes (and make sense to me)
<xnox> barry: but I don't want us to be bitten by this badly. E.g. what was the intent in pycurl and what is correct for python3-pycurl.
<barry> xnox: yeah, it certainly makes sense to pass bytes on the wire.  i don't know the api but it could accept bytes or utf-8 strings (if no encoding is available)
<barry> xnox: the latter would be for convenience
<barry> xnox: of course, if i can't figure out why pycurl crashes, it's all moot anyway ;)
<xnox> barry: it's "web" and potentially we could receive broken / half responses and thus encoding "none"
<barry> xnox: in which case, bytes is the only thing that makes sense
<xnox> ok. so I'm not that crazy =)
<barry> well, no guarantees that pycurl won't *make* you so ;)
<didrocks> xnox: hey, around? tried to catch you yesterday on #ubuntu-desktop (you were answering on #ubuntu-devel, not on that channel), and now on #ubuntu-unity ;)
<doko> rbasak, may I reject your ntp upload? see bug 1163768
<ubottu> bug 1163768 in ntp (Ubuntu Raring) "ntp ftbfs in raring" [High,In progress] https://launchpad.net/bugs/1163768
<rbasak> infinity: ^^
<rbasak> doko: I guess, if you're doing it. Not sure what I'm supposed to do though, if everything I do gets trumped.
<rbasak> This is exactly the concern I had yesterday, and it's happened on the first package I've touched.
<doko> rbasak, sorry, but I mentioned yesterday: please leave a note what you're working on
<doko> and I did file the report ...
<rbasak> doko: leave a note where?
<rbasak> In the topic?
<doko> rbasak, on #ubuntu+1-maint for example
<rbasak> doko: in the topic or in the channel?
<doko> I don't care
<infinity> In the channel is fine.  But sometimes stepping on toes happens.
<xnox> rbasak: fixing haskell-conduit/armhf FTBFS will resolve a fair chunk in the ghc transition, see http://people.canonical.com/~ubuntu-archive/transitions/ghc.html
<infinity> pitti: Did you do the langpack uploads in the queue?  Seems a bit premature.
<pitti> infinity: no, they are from the automatic cronjob I guess
<halfie> hi, does the linker in ubuntu automatically ignores the incorrect "-pie" flag when applied to DSOs ?
<pitti> infinity: I suggest to either leave them in the queue until after the beta, or just reject them and take the next set
<pitti> infinity: as we currently have empty update packs and thus minimal size
<halfie>  I am talking about "export DEB_BUILD_HARDENING=1" stuff
<infinity> pitti: Leaving them in the queue is fine, just makes it a bit unreadable. :)
<pitti> infinity: they aren't precious, so feel free to mass-reject
<infinity> pitti: And I assume we want a final langpack upload in ~2w anyway.
<pitti> the cron job uploads twice a week
<pitti> infinity: right
<infinity> pitti: I'll reject the lot for now, then.
<cjwatson> xnox: please, as I said yesterday, I don't think this is a good target
<cjwatson> rbasak: haskell-conduit/armhf is an epic rathole.  I advise against touching it.  It's actually a ghc bug which I've been working on with upstream
<rbasak> cjwatson, xnox: OK, I'll leave that then
<cjwatson> (both because I've been working on it - and have said so - and because it will take days of your time)
<xnox> cjwatson: sorry, I missed your comment yesterday about it.
<cjwatson> there are bits of the ghc transition that somebody familiar with haskell could productively attack, but I think there's probably a limit on how many Ubuntu developers should be trying to teach themselves that on the fly in order to resolve it :-)
<cjwatson> rbasak: it's generally easier to avoid getting trumped in universe, FWIW; it's less valuable than the fixes in main, but it's still within the scope of +1 maint and it does need to get done ...
<rbasak> cjwatson: sure, I can work in universe. My difficulty is picking something to work on - because there are issues that presumably people have left because they're not worth working on (too hard, or root cause somewhere else), and I can't easily tell those apart from the ones that can be worked on or would have a greater impact to work on, since they're all bundled together.
<cjwatson> I think it's probably inevitable that a lot of the initial work is analysis
<infinity> Sometimes, all of the work is analysis.
<infinity> In fact, in main, all of the work is sometimes pinging the TIL "maintainer" and asking if/when they're fixing it, before moving on. :P
<cjwatson> You can probably tell the difference between ready-to-attack and needs-analysis by whether there's a bug filed with description/comments that let you understand what's going on
<sladen> rbasak: is there any software you already use that you have perhaps noticed an issue with?  Or which a friend/colleague has mentioned.  You could look into tracking such as issue down, and it would be rewarding for both you and them.
<cjwatson> At least as a first-pass filter
<infinity> sladen: This is specifically in the context of +1maint, not scratching itches (though it's nice when they overlap, sure).
<rbasak> OK, so I should create a bug with analysis for every package I touch and decide not to try and fix?
<infinity> rbasak: If you get enough analysis to be helpful to the next person, it certainly doesn't hurt to file a bug to share that.
<rbasak> Is there a script that can create a bug from an ftbfs for me?
<infinity> Sometimes, the analysis is just "argh, too hard" or "I don't speak LangFoo, this is gibberish", and you just move on quickly. :P
<rbasak> (if not I might write one)
<rbasak> :)
<cjwatson> I've not found it worth the effort, since it's generally selective copy-and-paste
<rbasak> OK
<infinity> If the analysis is "I reduced this to a small test-case, and here's an example of how that fails, and now I'm stuck because I can't unwind the actual bug", that's valuable to share.
<infinity> But yeah, copy-and-pasting build log snippets isn't all that helpful.
<cjwatson> It can save time if somebody is looking for something to fix that's known to be easy
<cjwatson> Or at least not horribly intractable
<cjwatson> Same way as I think it's worth uploading Haskell transition rebuilds even if they're known to fail, just so that the build log's right there on LP
<Daviey> A while ago, i did a full rebuild of lots of packages that (generally) server cares for.  I tagged them as part of the process, and beated a drum of excitement. Within a week, the 20 or so FTBFS were all fixed.  (Many of them from new contributors.)
<Daviey> Which is why i thing that a large part of +1 maint should be coordination
<Daviey> Adding into a channel topic of random packages to touch isn't decent coordination
<Daviey> let alone outreaching to new contributors
<cjwatson> Things like the transition tracker are very useful, though need explanation
<xnox> not sure how far +1 maint scope reaches. For example S-series will open with boost1.53 by default and there are still 81 unfixed packages that fail with boost1.53 as listed here: http://people.canonical.com/~xnox/boost1.53/
<xnox> I didn't file bugs or anything....
<Daviey> One example is, bug 687976 .. in 2010, i had no idea who xnox was :)
<ubottu> bug 687976 in htmldoc (Ubuntu) "[FTBFS] 'htmldoc' (1.8.27-4.1)" [Undecided,Fix released] https://launchpad.net/bugs/687976
<ScottK> The best way to get those fixed is fix RC bugs in Debian so 1.53 is default there too (due to Wheezy being released)
<infinity> xnox: I don't mind +1-maint being proactive, though I'd like to see people who are pushing a transition be the first ones to take a crack at it before they just dump the problem on us. :P
<xnox> Daviey: those were the days =)
<rbasak> I'd love to just be given something to work on together with some confidence that I'll be left to it for a day or two without being trumped, but also for it to be something that'll have a real impact. Picking something like this turns out to be quite hard.
<cjwatson> Yeah, I can understand that
 * cjwatson has a glance at the list
<rbasak> I spotted a gnash armhf failure that I think would be useful to fix since gnash is more relevant on !intel.
<rbasak> I'll look into it. But it's also nice to have two or three on the go at once, since builds take a while
<CheezeMonkey> Does anyone know what could be going wrong if my ubuntu installation always hangs at the "preparing to install ubuntu" stage?
<infinity> rbasak: The seeded-but-not-in-main stuff at the bottom of the ftbfs list could be worth looking at.
<CheezeMonkey> I had once, a little over a year ago, installed ubuntu 10.10 without any issues
<infinity> rbasak: openimageio, libgda5, etc.
<xnox> CheezeMonkey: bug 1080701
<ubottu> bug 1080701 in ubiquity (Ubuntu Raring) "After 'Preparing to install Ubuntu' screen, raring installation hangs" [High,Confirmed] https://launchpad.net/bugs/1080701
<cjwatson> rbasak: One thing that comes to mind is digging up the remaining qemu BIOSes and the like that need to be converted to use cross-compilers to build now that we have them
<cjwatson> openhackware and the like - I did slof not that long ago if you want an example
<infinity> Do we still have ppc-only and arm-only ones that need crossing?
<infinity> (We're a bit short on other cross-toolchains)
<cjwatson> I think there are one or two, yes
<cjwatson> openhackware is one such
<cjwatson> forked-daapd might be worth looking at earlier rather than later - a cycle or two ago that was the end of a chain that had infinity and I working on llvm/clang at the last minute
<CheezeMonkey> xnox: any way that i can workaround/ solve the problem for my case?
 * rbasak looks
<infinity> Hah, looks like openhackware has everything it needs in debian/rules already.
<cjwatson> and it'd be nice to chase down anything in universe that's failing on all architectures
<cjwatson> infinity: don't steal it :)
<infinity> But.  But.
<infinity> But.
<cjwatson> the point of this was to suggest things that were interesting but not intractable
<infinity> rbasak: If you take openhackware, be sure to revert the Ubuntu delta before you start.
<infinity> (And happy to review when you're done)
<xnox> CheezeMonkey: https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1080701/comments/86
<ubottu> Launchpad bug 1080701 in ubiquity (Ubuntu Raring) "After 'Preparing to install Ubuntu' screen, raring installation hangs" [High,Confirmed]
<rbasak> $ chdist apt-cache raring search hackware
<rbasak> $
<rbasak> What am I missing?
<infinity> rbasak: pull-lp-source openhackware
<infinity> rbasak: You're missing that apt-cache search searches binaries.  Of which there are none.  Cause it's FTBFS.
<rbasak> Oh. OK
<infinity> rbasak: Actually, since the current Ubuntu delta wants to go away anyway, pull-debian-source openhackware might be more appropriate. :P
<rbasak> OK, I'll look at forked-daapd, openhackware and gnash. Thanks!
<CheezeMonkey> xnox: thankyou, i'll give it a shot
<cjwatson> I usually start with both pull-debian-source -d and pull-lp-source -d when investigating this kind of thing
<infinity> cjwatson: Finally trained your fingers to do that?  Took me ages.
<infinity> cjwatson: And not sure how I lived without pull* now...
<cjwatson> Yeah, the benefit function was high enough ...
<cjwatson> Pretty sure I was evangelising it to you for a while :)
<infinity> Now, I just need to teach them about apt proxies.
<xnox> infinity:++
<infinity> Irks me that pull* doesn't hit (or seed) my local cache.
<rbasak> So slof was Arch: all but Debian was making it happen to be a powerpc so that the build would work?
<infinity> rbasak: Right.  Same with openbios-ppc or whatever it was I fixed.
<rbasak> OK, got it. I understand the fix then.
<cjwatson> rbasak: in Debian, binaries for the first architecture are uploaded by the developer
<infinity> rbasak: Debian builds arch:all on maintainer machines, not on buildds, so the maintainer just builds where they work. :P
<cjwatson> i.e. all uploads are source + >=1 binary
<rbasak> I see
<cjwatson> And over the years we've been hammering out "arch all fails to build on buildds" problems
<infinity> rbasak: Anyhow, we build arch:all on i386, so that's where it falls apart a bit.
<cjwatson> It's an excellent approximation, but it's not 100%
<cjwatson> And we don't have a way to say "please build arch all on some other architecture" - that's quite hard infrastructure work
<infinity> And, to be fair, our cross fixes are just as "wrong" as the Debian upstream, from the POV that we don't have cross toolchains from/to every arch.  But at least ours will fail with missing build-deps on the wrong arch, instead of later with some weirdness.
<cjwatson> Hence, cross-compilers save the day
<rbasak> Would a new "Build-Arch" control field be a clean answer? I imagine that requires the same difficult infrastructure work though
<cjwatson> Exactly the same
<infinity> rbasak: Bikeshedding about the field name is the easy part.
<rbasak> :)
<cjwatson> And I think we'd determined it was better to put it in Packages-arch-specific, possibly
<infinity> rbasak: But the implementation details (in both DAK and Soyuz) are something I've been trying to find the time to look at.
<cjwatson> Or at least that was what I heard last time I talked to Debian ftpmasters about this
<infinity> cjwatson: Ew.  Debian's been trying to phase out P-a-s, not make it more relevant.
<cjwatson> Just the messenger
<infinity> cjwatson: Did someone lose the plot there?
<infinity> Hrmph.
<cjwatson> This was from Mark Hymers but it was at Debconf in Bosnia
<cjwatson> So could be out of date
<infinity> Personally, I think it's information that belongs in debian/control, but meh.
<cjwatson> You may well be right
<infinity> Packages should know what they need to be built, without external infrastructure to supplement that.
<infinity> (Same reason we got rid of the hideous sourcedeps mess, and made porters push changes to packages directly, or not be allowed to play if they couldn't play nicely)
<infinity> I suppose that dates me a bit.  I doubt many people remember that Debian buildds used to patch source packages on the fly for arch-specific madness.
<infinity> Well, and sourcedeps also filled in the missing blanks from Build-Depends, also a thing of the past.
<infinity> So, yeah.  Regressing on that firm "source packages should be self-contained" thing is silly.
<rbasak> So openhackware and forked-daapd both fail on power due to something related to __stack_chk_fail
<rbasak> SO does have solutions for this. But is this expected?
<cjwatson> Without having looked at them, the situations are probably different
<cjwatson> I suspect that openhackware is trying to build code that runs in an environment where libc isn't available (i.e. a firmware image), and the right fix there is probably to build with -ffreestanding
<cjwatson> forked-daapd is probably llvm/clang-related madness of some kind
<cjwatson> it's one of the very few packages in the archive that uses clang to build - indeed it uses features specific to it
<rbasak> OK, thanks
<halfie> hi, does the linker/compiler in ubuntu automatically ignores the "-pie" flag when applied to DSOs ?
<bschaefer> doko, ping
<doko> ?
<bschaefer> doko, hello, I was looking at libgcc1s changelog and saw it was updated recently, and was wondering if there was any chance of ABI breaks from it?
<bschaefer> doko, as Im getting some crashes in libfontconfig and pango and recompiling them seems to fix my problem
<doko> I'm not aware of any
<bschaefer> doko, alright thanks! (didrocks pointed me to talk to you)
<didrocks> bschaefer: so it's something else, and I think, you will to dig on what broke it :)
<bschaefer> didrocks, yeah, I checked through all the dependencies of libfontconfig and libgcc1 gcc-4.7-base were the only things changed recently
<bschaefer> didrocks, but I could have missed something
<CheezeMonkey> xnox: no luck :/
<rbasak> Does anyone else feel that the first two parameters of chdist are the wrong way round? I'm tempted to write a wrapper for myself. Every time I want to change the command I have to step over the dist. And it seems logically wrong, too.
<MrAnderson_> Hi, I just saw that precise comes with GNU make 3.81 (3.82 has been released in 2010). packages.ubuntu.com also shows some 3.81* version number. Is raring really still using a make 3.81 branch? Is this intended?
<sarnold> MrAnderson_: note that debian unstable is still on 3.81 as well: http://packages.debian.org/search?keywords=make
<MrAnderson_> sarnold: So, the real question is: "why is Debian still shipping make 3.81" and should go to the Debian maintainers?
<cjwatson> IIRC there was some incompatibility that was a problem
<sarnold> MrAnderson_: yeah; it's in experimental, so presumably someone is interested in getting 3.82 into newer releases..
<cjwatson> cf. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=618661
<ubottu> Debian bug 618661 in make "make: Please package new upstream version 3.82 in experimental" [Wishlist,Fixed]
<MrAnderson_> cjwatson: indeed, there are quite some incompatibilities. That is why I wondered why some old Makefiles are working fine on Ubuntu while they are failing on Gentoo.
<cjwatson> and a bunch of open problems which you can see at http://bugs.debian.org/cgi-bin/pkgreport.cgi?src=make-dfsg
<cjwatson> We like to keep our development release as working as we can; although I think in this case it's more just that nobody's decided to take ownership of pulling that from experimental and fixing everything up
<sarnold> ouch. that doesn't seem like a .81 to .82 version number bump :(
<xnox> rbasak: I wonder why are you using chdist in the first place =)
<rbasak> xnox: what do you do instead?
<xnox> rbasak: pull-lp-source hello precise-security (gives me hello source package from precise) or pull-debian-source hello 3.2-1 (gives me exactly that version from debian) and vise versa.
<xnox> rbasak: rmadison hello prints all the version across all releases, or just browse http://pad.lv/u/hello
<xnox> rbasak: for builds, I use mk-sbuild and thus it's just "sbuild -d raring foo.dsc" to build in raring's sbuild.
<rbasak> xnox: I use chdist for apt-cache show, search, bin2src and src2bin. rmadison doesn't give me all of that and is painfully slow
<cjwatson> chdist is useful for simulating apt-get install/build-dep against an arbitrary release
<cjwatson> I guess I find the parameter ordering a bit annoying but have got used to it
<xnox> rbasak: ok. My host is raring. Are you on a stable release?
<rbasak> I'm still on quantal :-/
<rbasak> Just haven't got round to upgrading yet
<xnox> rbasak: right so for me it's easy =) apt-cache search works as expected against devel-series, and for past releases everything is static hence one only needs to sru things....
<rbasak> Right. I see now. I really should just upgrade to raring.
<rbasak> I have periods of time when my full disk backup system is unavailable, like right now.
<cjwatson> xnox: I'm not aware of any sane non-chdist substitute for the install/build-dep simulation; it's very useful when working on transitions, and is why we have a bunch of pre-canned chdist environments in lillypilly:~ubuntu-archive/
<rbasak> Or I'm about to travel. I really should just sort it out and upgrade
<cjwatson> (Especially when you want to simulate against raring-proposed or on some arch you don't conveniently have to hand)
<rbasak> Examining sid is handy with chdist too actually. I just used it as a reference in preparing a bug report to Debian
<cjwatson> Yeah
<cjwatson> You can do it with full chroots of course but it's much slower
<rbasak> I'm also planning on cronning chdist apt-get --download-only to prime the cache that I haven't quite got round to setting up yet
<xnox> cjwatson: well none of the ubuntu-dev-tools and things mention chdist, so it's the first time I hear about it. When I need the usecases you list, I tend to just schroot -c sid for example.
 * xnox should look into chdist and what it can do.
<cjwatson> xnox: You know now :)
<rbasak> I've discovered most dev tools by seeing references of them from others over the years
<rbasak> Knowing about dget saved me time copying and pasting three urls all the time for example
<rbasak> I think the dev documentation does lack quite a bit. Most people seem to find debian packaging a black art, whereas I find it really elegant tidy (for the most part).
<rbasak> I think the difference is caused by a shortcoming in the docs
<cjwatson> rbasak: A lot of this is caused by trying to document all the alternatives.
<cjwatson> "Hey look we have this incredibly powerful system that can do anything" vs. "Here is a sane simple way to do what you need"
<rbasak> Agreed. I think some docs dedicated to simple use cases would be useful
<cjwatson> (I share your general feeling, of course)
<GunnarHj> slangasek: Hi Steve, did you see my idea at bug 1155327?
<ubottu> bug 1155327 in skype (Ubuntu Raring) "skype crashed with SIGSEGV in malloc@plt()" [High,In progress] https://launchpad.net/bugs/1155327
<tkamppeter> OdyX, hi
<tkamppeter> OdyX, I have released cups-filters 1.0.32, which should also get into Raring (important fixes for CUPS browsing, bug 1163764 and more). Can you quickly get it into Debian? Thanks.
<ubottu> bug 1163764 in cups-filters (Ubuntu) "BrowseAllow required in cups-browsed.conf for CUPS browsing" [Undecided,In progress] https://launchpad.net/bugs/1163764
<seb128> cjwatson, xnox: not sure if you guys are subscribe to ubiquity-slideshow-ubuntu or who is tracking it, but there is a trademark issue on the skype logo shipped there that would be good to solve for raring: 1163504
<seb128> bug 1163504
<ubottu> bug 1163504 in ubiquity-slideshow-ubuntu (Ubuntu) "Trademarked assets" [High,Confirmed] https://launchpad.net/bugs/1163504
<seb128> it seems to be used by lubuntu only at the moment
<seb128> I checked with John (who reported the bug) and he said it would be good to fix the packages in main at least (we have some others in universe/multiverse like pidgin-skype)
<xnox> seb128: we are not going to respin quantal CDs, so the quantal bug task is a bit moot for ubiquity-slideshow-ubuntu.
<seb128> xnox, yeah, feel free to wontfix that one
<seb128> xnox, it would still be good to fix for raring
<seb128> xnox, we didn't get a specific request about the slideshow, but the email they sent suggested it would be better to just stop using their logo without permission
<xnox> seb128: I can tweak and commit the change in the slideshow.
<seb128> xnox, thanks
<rbasak> infinity: http://people.canonical.com/~rbasak/upload/openhackware/ please
<infinity> rbasak: Cool, I'll poke it after I lunch.
<rbasak> Thanks. Lunch away! I'm EOD now.
<xnox> seb128: done. "* Drop references to Skypeâ¢ and its logo. (LP: #1163504)" assigned stgraber to actually upload the change.
<ubottu> Launchpad bug 1163504 in unity-asset-pool (Ubuntu Raring) "Trademarked assets" [Undecided,New] https://launchpad.net/bugs/1163504
<infinity> rbasak: Diff looks plausibly sane though, thanks.
<seb128> xnox, \o/, thanks for the quick fix
<rbasak> infinity: I didn't bother with the case of a powerpc host buildling it. Then we'd want CROSS_PREFIX to be empty. I assumed that it's not worth it since we use i386.
<rbasak> (also it's a pain for me to test that)
<infinity> rbasak: You could have made the build-dep be [!powerpc] and left the ifeq logic in (though, they reversed BUILD and HOST, so that would have still needed fixing), but meh.
<rbasak> Right
<rbasak> I followed cjwatson's lead with slof there
<infinity> Yeah, I didn't make openbios-ppc buildable on powerpc either.
<infinity> I'm now considering revisiting that, so I can push the change to Debian, but carefactor's low.
<rbasak> I sent the -ffreestanding to Debian, but not the cross compile stuff
<infinity> rbasak: *nod*
<infinity> Right, lunch time.
<rbasak> Dinner time for me. I'll actually leave now. Enjoy lunch!
<seb128> bdmurray, ev, slangasek: do you know why https://errors.ubuntu.com/ just got a spike in 13.04 reports?
<infinity> seb128: Beta testing?
<seb128> infinity, that should increase the frequency?
<seb128> if 1% of users hit a but, having 10 times users should still give you 1%
<seb128> but->bug
<infinity> Except that every fresh install is a new "user".
<infinity> So, if one person has problematic hardware or something they specifically always do differently from others that triggers a bug, and then reinstall 10 times, that would skew things.
<seb128> do we have any idea what issue those users are hitting?
<slangasek> seb128: also, installs that never see any bugs don't get included in the count because we don't phone home, so new installs (beta testing or otherwise) increase the overall percentage of users hitting bugs
<seb128> like what bug is contributing most to the increasE?
<infinity> Yeah, that I don't know.  I'm just throwing out wild guesses for the spike.
<seb128> k
<seb128> so we don't really know if that means that we let a new bug slip through
<seb128> or if there is an issue we should focus on
<slangasek> seb128: if there is a new bug that's slipped through, it should show up in the crash rankings
<seb128> slangasek, nothing "new" in there
<ev> so https://errors.ubuntu.com/bucket/?id=%2Fusr%2Fbin%2Fupdate-manager%3Aaptdaemon.errors.AptDaemonError%3A_convert_dbus_exception%3Acancel%3A__call__%3Acall_blocking%3A_on_clicked%3A_deferable%3A_convert_dbus_exception has spiked
<ev> but following the beta testing theory, https://bugs.launchpad.net/errors/+bug/1069827
<ubottu> Launchpad bug 1069827 in Errors "Error rate incorrectly spikes with any influx of machines" [High,Confirmed]
<seb128> bug #1026149 is by far the most ranked
<ubottu> bug 1026149 in update-manager (Ubuntu) "update-manager crashed with aptdaemon.errors.AptDaemonError in _convert_dbus_exception(): org.debian.apt: Could not cancel transaction" [Medium,New] https://launchpad.net/bugs/1026149
<seb128> but it's not "new"
<ev> https://bugs.launchpad.net/errors/+bug/1077122 is one attempt at fixing this, and it's waiting on a deployment from webops
<ubottu> Launchpad bug 1077122 in Errors "Machine weighted at 100% 89 days after last report, 0% 90 days after" [High,Confirmed]
<ev> seb128: it's not new, but it's showing more instances than in recent days prior
 * ev goes back to his tea
<seb128> ev, thanks
<slangasek> this one shows a sudden spike, not sure why that would be except for the beta testing. https://errors.ubuntu.com/bucket/?id=%2Fusr%2Fbin%2Findicator-weather%3AAttributeError%3Aon_apply%3Aexport_location_details
<seb128> slangasek, do you have anyone who could look at this one?
<seb128> "this one" being the update-manager one
<seb128> not indicator-weather
<slangasek> seb128: hmm, the indicator-weather one looks *much* more frequent than the update-manager one, but doesn't rank when looking just at 13.04, strange
<seb128> slangasek, the indicator-weather was also much more frequent in december-january
<seb128> that's weird as well
<slangasek> ev: there seems to be an inconsistency between https://errors.ubuntu.com/bucket/?id=%2Fusr%2Fbin%2Findicator-weather%3AAttributeError%3Aon_apply%3Aexport_location_details and the main page regarding this crash's frequency in 13.04
<slangasek> ev: the per-crash graph shows a clear spike on the 13.04 line, but when viewing crashes for 13.04 on the main page, it claims there've only been 9 reports today
<seb128> slangasek, the "by version" table seems to suggest very low raring reports as well
<seb128> >= 12.07.30-0ubuntu2 is = 5+1+18=24
<seb128> 12.07.30-0ubuntu5 has 18 reports total
<seb128> which is the current version for some weeks
<seb128> the spike is a 0.00 to 0.04 increase on the graph
<seb128> seems like it's a "we had no report and just got 9", which is an big increase...
<seb128> but I'm not sure how useful the raring stats are for "common issues", it seems we don't have enough raring users for that
<seb128> we were just looking at a compiz bug with the unity guys and the most frequent issue got 11 reports, then we fall to 2
<seb128> in a day
<seb128> compared to 12.10 which scores 6 issues over 100
<xnox> part of the problem the small % of users running raring at the moment. There will be a spike on the release day =/
<slangasek> seb128: looks like that u-m bug is a repeat of bug #628104; so it's already on our list
<ubottu> bug 628104 in update-manager (Ubuntu) "update-manager crashes: AptDaemonError: org.debian.apt: Could not cancel transaction" [High,Triaged] https://launchpad.net/bugs/628104
<seb128> slangasek, ok, thanks
<slangasek> GunnarHj: I'm with jdstrand on this one; we need to get to the bottom of the qtwebkit regression
<GunnarHj> slangasek: I'm not of another opinion. Just think a temporary fix would be good for the case the root fix doesn't make it before the release.
<GunnarHj> slangasek: But I noticed an issue with my hack, probably because I rename the binary. I'd be happy to modify the fix, but it would be pointless if nobody uploads it anyway...
<smoser> slangasek, i added lxc recreate instructions at https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1124384
<ubottu> Launchpad bug 1124384 in cloud-init (Ubuntu) "reload-configuration can confuse upstart" [High,Confirmed]
<slangasek> smoser: thanks
<smoser> which should be very straight forward.
#ubuntu-devel 2013-04-04
<Bonez> do any of you folks manage the actual ubuntu repositories?
<sarnold> some people here are archive admins..
<Bonez> i'm assuming ubuntu uses dak to manage its repositories?
<StevenK> We do not.
<pitti> Good morning
<Bonez> well that sucks. thanks anyways then.
<StevenK> ...
<ion> â¦ indeed
<dholbach> good morning
<didrocks> good morning Mr Holbach :)
<dholbach> salut didrocks
<doko> cjwatson, is there light at the end of the haskell tunnel?
<ev> slangasek: due to a bug (https://bugs.launchpad.net/errors/+bug/1154189) I cannot see the graph for that bucket.
<ubottu> Launchpad bug 1154189 in Errors "Short URLs for buckets" [High,Triaged]
<leagris> Hello
<ev> I have a branch to fix the URL issue. Please feel free to file a bug for anything amiss you find in the data (http://launchpad.net/errors/+filebug)
<cjwatson> doko: it's some way off yet, but I think so.  Definitely making progress
<doko> jodh, should upstart-monitor be kept in main?
<doko> Daviey, zul: should cinder-backup, python-pybabel, quantum-lbaas-agent quantum-plugin-midonet  be kept in main?
<Daviey> doko: I believe so
<doko> seb128, didrocks: should gwibber, gcalctool be kept in main?
<doko> Daviey, could you seed these?
<seb128> doko, no to both
<jodh> doko: it's not essential, so maybe not. But would it be odd to have a single source package with binary packages in different repos?
<seb128> doko, gcalctool is a dummy transitional package (got renamed gnome-calculator)
<doko> jodh, it's your call
<soren> jodh: No, that's not odd at all. It's quite common.
<soren> jodh: So don't let that affect your decision.
<Daviey> doko: ack
<doko> cjwatson, should libdrm2-udeb be kept in main?
<doko> seb128, can you help with account-plugin-icons?
<seb128> doko, what about it?
<doko> should it be kept in main?
<jodh> doko/soren: I'm easy where it lives then :) It just ended up in main by default.
<seb128> doko, probably not, it's a dummy transitional package
<doko> seb128, ok, demoting
<seb128> thanks
<doko> jodh, could you seed it?
<cjwatson> doko: No.  Moved to universe
<cjwatson> seed upstart-monitor> I would suggest lp:~ubuntu-core-dev/ubuntu-seeds/platform.raring supported-sysadmin-common
<cjwatson> Or perhaps supported-sysadmin-desktop since it includes GUI support
<cjwatson> (Doesn't matter that much, it's support lifetime pedantry)
<jodh> cjwatson: thanks
<doko> seb128, should ubuntu-system-service be demoted?
<doko> or maybe removed?
<pitti> seb128: ^ is that actually completely replaced by other things? didn't that set the apt proxy in the past?
<seb128> doko, pitti: no, it's still useful and should still be installed by default
<seb128> let me find the right place to add back a depends/recommends
<seb128> what pitti said
<pitti> seb128: did we switch over to system-services now?
<pitti> ah, so we did
<seb128> pitti, we did, and I dropped the u-s-s systemd compat parts
<seb128> but as you said it still does stuff useful for us
<seb128> we didn't get to move those bits somewhere else yet
<pitti> seb128: what's left except the apt proxy stuff?
<seb128> pitti, some keyboard stuff
<seb128> pitti, but I'm not sure where/if we still use that
<pitti> isn't that being done by accountsservice now?
<pitti> another instance where I'd love to have codesearch.ubuntu.com :)
<seb128> pitti, is has "is_reboot_required" as well
<seb128> pitti, yeah, would be useful to have a codesearch, I'm wondering if we have anything left using those inferfaces
<pitti> seb128: I guess apt proxy is g-c-c ?
<seb128> pitti, it was, but we didn't port that feature to the new network panel afaik
<seb128> so I'm not even sure it's used atm
<pitti> uh
<pitti> gnome-control-center-3.6.3/debian/patches/50_ubuntu_systemwide_proxy.patch:+                                       "com.ubuntu.SystemService",
<pitti> we still have that
<pitti> apparently upstream doesn't have a system-wide proxy config
<seb128> pitti, series: "#50_ubuntu_systemwide_proxy.patch needs-rewrite"
<pitti> it's not used at all in software-properties
<seb128> pitti, right, one of the blueprint mention that it's planned to add to n-m
<pitti> so I suppose the keyboard stuff can go as well
<seb128> pitti, what's the right thing to grep for? com.ubuntu.SystemService I guess?
<pitti> update-notifier and software-properties also don't use u-s-s
<seb128> pitti, I will ask jdstrand if he can archive grep for it
<pitti> seb128: *nod*
<seb128> jdstrand, hey, is there any chance you could archive grep for com.ubuntu.SystemService in raring?
<seb128> pitti, the only match in my local packaging dir is g-c-c and the patch is commented of the serie
<pitti> so I suppose there's no need to add a dependency right now
<pitti> i. e. raring just can't set system-wide proxy with a GUI
<seb128> right, we might want to try to fix that before release though
<seb128> not sure how important the feature is
 * xnox had multiple reports from people not managing to get proxy settings right globally. E.g. apt-get works, yet downloading flash in the flashplugin-installer times-out and doesn't have the right proxy settings =(
<xnox> is_reboot_required - shouldn't that now be handled by the upstart file bridge? or do we need to enable user sessions as well (not enabled by default for raring) ?
<seb128> xnox, well, that code gives a dbus interface to query to know if a reboot is required
<seb128> not sure what uses it, seems like that should be an info available in aptd though
<seb128> that's useful for e.g update-manager or the indicator-session to turn the icon red
<xnox> seb128: /me thought that we emit a dbus broadcast event upon flaggin up "reboot required" for the indicators and the like. They don't poll the status.
<xnox> oh, they might on startup/first login.
<seb128> right
<seb128> stuff like update-manager are not running all the time
<xnox> seb128: we can totally add that dbus interface to upstart, which has everything on dbus already.
<xnox> seb128: e.g. a file-bridge dbus interface to check reboot_required file, wherever that file is.
<seb128> wouldn't it make sense to have that interface provided by aptd rather?
<seb128> that seems like the appropriate service for package management related apis
<pitti> seb128: preferably we don't want to trigger aptd on every boot each time, though
<pitti> it's really heavy
<seb128> that's a good point
<pitti> programs could just look for the stamp file
<pitti> this is all heavily ubuntu specific anyway, so if we hardcode the ubuntu specific path or the ubuntu specific dbus name doesn't make much of a difference from a maintenance POV
<pitti> but a huge one for performance
<pitti> the same is true for u-s-s, of course (being written in python)
<vrodic> hey guys, i've just upgraded to 13.04 from 12.04, and now my single ext4 root filesystem doesn't unmount cleanly on reboot. a known bug?
<xnox> pitti: looking at the code for bug 1103024 the __gsignal__ only specifies 3 parameters. Unless action-done is name clashing with some other "action-done" with 5 parameters?
<ubottu> bug 1103024 in apturl (Ubuntu Raring) "apturl-gtk crashed with TypeError in _on_finished(): 5 parameters needed for signal action-done; 3 given" [High,Confirmed] https://launchpad.net/bugs/1103024
<OdyX> tkamppeter: build in the pipes
<jdstrand> seb128: re archive grep> started
<xnox> doko: some of the underlinking is reported during gtk-doc builds, which frankly we don't care about underlinking as it does build a scanner only to find relevant/wanted symbols.
<xnox> can it be somehow disabled in gtk-doc?
<seb128> jdstrand, hey, thanks!
<tkamppeter> OdyX, OK. I am assuming that you are based on today's BZR commit (including the cups-browsed.postinst to overtake cupsd.conf entries).
<jibel> jtaylor, I proposed a patch for bug 1164362, if it is accepted you can keep the versions in ipython's test control file.
<ubottu> bug 1164362 in autopkgtest (Ubuntu) " autopkgtest: doesn't support versioned dependencies" [Medium,Triaged] https://launchpad.net/bugs/1164362
<jibel> jtaylor, just fix the deps for the test 'incomplete-install', there is a comma missing, and add python-lxml and python3-lxml to tools2 and tools3 dependencies respectively
<OdyX> tkamppeter: saw them later on; yes.
<OdyX> tkamppeter: uploaded to experimental right now.
<tkamppeter> OdyX, thanks.
<OdyX> tkamppeter: I have pushed my changes to the repository.
<OdyX> tkamppeter: can you tag the repository for me. I'm done with fighting with bzrâ¦
<doko> xnox, sorry, failing to parse that ...
<Mirv> didrocks: hi. upstream has approved my patch to Qt Creator fixing bug #1135336 , at  lp:~kubuntu-packagers/kubuntu-packaging/qtcreator
<ubottu> bug 1135336 in qtcreator (Ubuntu) "Qt Creator misconfigures itself on first run if qt4-qmake is installed (does not respect qt5-default)" [Undecided,In progress] https://launchpad.net/bugs/1135336
<Mirv> if you're willing to sponsor
<xnox> doko: https://launchpadlibrarian.net/136066048/buildlog_ubuntu-raring-i386.glade-3_3.8.0-0ubuntu5_FAILEDTOBUILD.txt.gz fails during scanning docs. Can that "undefined reference to symbol" be optional at gtk-doc stage?
<didrocks> Mirv: oh, excellent news! do you mind summing that up for me on how this is fixed?
<didrocks> Mirv: like, I never lauchad qtcreator and installed qt4-qmake
<didrocks> what happens? :)
<Mirv> didrocks: it configures the Qt for you that is the default (Qt 5 in case of qt5-default)
<didrocks> Mirv: the fact to prefer qmake will should both qt5 and qt4 projects?
<didrocks> s/should/show/
<didrocks> in the new project window?
<Mirv> didrocks: it will show both qt quick 1 and quick 2, if that's the question, yes
<Mirv> (Qt 5 supports qt quick 1 as well)
<didrocks> Mirv: exactly, thanks! :)
<didrocks> ah, that was what I meant, didn't realize the qt quick1 was coming from qt5
<didrocks> but yeah, makes sense
<didrocks> Mirv: building and sponsoring :)
<doko> xnox, I don't think so. so is this gtk-doc which needs the fix? apparently something is linked during the doc build
<doko> seb128, ^^^
<seb128> no idea about gtk-doc
<Mirv> didrocks: Qt Quick of Qt 4 was renamed to Qt Quick 1 when Qt 5 / Qt Quick 2 came out
<didrocks> Mirv: right right, I just didn't think about it when looking at the dialog that even qt quick 1 was indeed still coming from qt5 ;)
<didrocks> Mirv: nice work, the patch makes sense :)
<Mirv> thanks. nice that upstream agreed, I was wondering if they had some other logic on mind.
<didrocks> Mirv: yeah, it seems too obvious and tricky. Great that you get them reviewed first, I was afraid of side-effects :)
<xnox> doko: so to generate gobject like API docs, a scanner is compiled and linked against a library one have just built. And like a lot of ugly things, it only links that .so and nothing else. As well frankly it doesn't care about linking in the dependencies.
<xnox> doko: anyway I uploaded a fix in glade-3, but I wonder how many more of "failed to build gtk api docs" we have in that test rebuild.
<doko> xnox, seb128: well, you could patch gtk-doc to explicitly pass --copy-dt-needed-entries
<doko> -Wl,--copy-dt-needed-entries
<xnox> doko: nice. well just patch the gtk-doc included makefile snippet to do that in the correct target.
<xnox> (that snippet is used by all gtk-doc packages, as that's the way to build gtk-docs)
<xnox> via include.
<doko> lamont, do you have a complete log for bug 1157687?
<ubottu> bug 1157687 in python2.7 (Ubuntu) "Upgrade to raring fails in prerm" [Undecided,Incomplete] https://launchpad.net/bugs/1157687
<doko> jibel, did you see this upgrade issue? ^^^ (or aren't you involved anymore with upgrade testing?)
<jibel> doko, psivaa and plars are doing upgrade testing now. psivaa plars did you see this issue^
<lamont> doko: looking
<psivaa> jibel: no i did not see this issue, i normally update quantal before upgrading to raring and not sure if thats the reason why we do not see that.
<doko> xnox, are you working on the gtk-doc patch?
<ev> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Ubuntu 12.10 released | Archive: Final Beta Freeze | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of hardy -> quantal | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: ev
<xnox> doko: well back from lunch. Will quickly check how many other things failed at gtk-doc, and whether it's worthwhile to do in gtk-doc.,
<tkamppeter> OdyX, why have you added your own init script for cups-browsed? there is an upstream one in utils/cups-browsed.in.
<plars> jibel, psivaa: no doesn't look like anything I saw either
<xnox> doko: couldn't find another instance so far.
<nigelb> pitti: Do you know if/when there will be an update for postgres in the ubuntu repos for today's sec release?
<xnox> nigelb: > #ubuntu-hardened maybe?
<xnox> for security team.
<nigelb> xnox: Aha, thanks!
<plars> jibel, psivaa: only thing I had problems with was compiz (shocker!) :)
<pitti> nigelb: way ahead of you :)
<nigelb> pitti: already building?
<pitti> nigelb: it was built two days ago, mdeslaur is pushing out the announcements and packages right now
<nigelb> or already *built*
<nigelb> hah!
<nigelb> Good job you guys! :)
<pitti> nigelb: upstream, debian security, ubuntu security and me are currently doing live coordination
 * pitti currently feeding his backport PPA
<nigelb> \o/
<pmcgowan> jdstrand: re the app launcher how is the app actually invoked such that this launcher is used
<tvoss> pmcgowan, the shell needs to make sure that the launcher is invoked as I understand it
<barry> doko: are you going to give back pycurl?
<jdstrand> pmcgowan: that is TBD. we are going to write a prototype that is just an executable that can do 'applaunch /opt/../bin/foo' (or something)
<jdstrand> pmcgowan: but we figured this would be more closely integrated with Unity
<pmcgowan> ok makes sense
<jdstrand> pmcgowan: hence the 'handoff' portion
<pitti> oh dear, the PPA autobuilders are totally blocked at a bad time
<cjwatson> pitti: asking for score bumps would be justified
<ricmm_> jdstrand: is the invocation just a middle-exec ?
<pitti> cjwatson: I did bump them (psql security updates)
<tvoss> jdstrand, is there a work item for the apparmor definition step (leaving aside how to do it)?
<ricmm_> or is it a service that exposes an API
<jdstrand> tvoss: in that same blueprint, there is work for the apparmor definition. next month (iirc) we start looking at making it integrate with the SDK
<tvoss> jdstrand, cool
<OdyX> tkamppeter: which is too generic as far as I'm concerned. Also $cups and $alioth don't work.
<tvoss> jdstrand, we were initially thinking about an executor approach that allows for more fine-grained entry points to an application than just int main(...)
<jdstrand> ricmm: my team is concerned really on with making sure the sandbox is setup properly. I think the Unity team is in the best position to define (with our review) how to execute a sandboxed app
<ricmm> I mean in terms of the launcher, just wondering what your planned implementation for it is in terms of consumers
<mitya57> pitti: hi, did you see debian bug 700838? do you want me to write a patch for it? :)
<ricmm> not just the definition of the sandbox itself
<ubottu> Debian bug 700838 in calibre "calibre: embedded copy of libjs-mathjax" [Normal,Open] http://bugs.debian.org/700838
<pitti> mitya57: oh, please
<mitya57> ok
<ricmm> or maybe I'm reading this wrong and the launcher is actually a work item on someone elses plate, to match your sandbox definition
<jdstrand> tvoss: sure. do you have existing code for this?
<OdyX> tkamppeter: also, it would be ideal if cups-browsed could 1) fork itself; 2) write its pidfile somewhere on his own.
<tvoss> jdstrand, nope, it was more an initial idea that would allow us to offer test executors and the like
<jdstrand> ricmm: well that's just it. we don't have a planned implementation for consumers. we have a plan for the sandbox setup. we want to plugin to your (I'm assuming you are on the Unity team) plan for executing things
<tvoss> jdstrand, however, people vetoed the idea for multiple reasons, among them the lack of protection of the executor, and the argument that not every app will be an executable/shared library
<jdstrand> which is why we are just doing a super simple prototype at first
<jdstrand> tvoss: I'm not sure I understand that comment. can you rephrase? for an app to be confined properly, it needs to have its own pid for attachment such that we can attach a profile to it for that application
<jdstrand> ie, multiple tabs for different HTML5 apps won't do
<jdstrand> s/ie/eg/
<tvoss> jdstrand, okay, the idea was that the executor is an executable that loads an app from a shared-object by resolving some pre-defined entry points, obviously, we could run the executor in your sandboxed env
<jdstrand> (well, unless each tab is a separate process-- it gets slightly more complicated there, but it is technically doiable)
<jdstrand> tvoss: this executor you refer to-- is that for the entire supported set of apps? (HTML5, QML, etc)
<tvoss> jdstrand, yup, that was the idea, although we didn't explore it any deeper tbh
<mitya57> pitti: unrar in dfsg tarball?
<jdstrand> tvoss: ok, so your executor could be our app launcher (ie, we plugin to it to setup the sandboxed env)
<jdstrand> tvoss: we have the aa_change_profile() library call that we can use in the executor to change into the apparmor profile at an appropriate time (eg, just before fork())
<tvoss> jdstrand, interesting .. perhaps we stick to your first cut of main as an entry point and see how we can evolve things over time?
<jdstrand> tvoss: I'm fine with proceeding how it makes sense. the prototype we want to have is really about showing how to setup the sandbox. that code can be pulled in to Unity in your executor or in some other fashion however it works best for Unity
<ScottK> pitti: If you have postgresql-9.1 ready for raring, go ahead and upload (or when you do).  I'm happy to go ahead and accept it, freeze or no.
<tvoss> jdstrand, cool :) that sounds like a really good idea
<pitti> ScottK: ah, can do; I was going to sync it in about two hours or so, as dinstall is just running
<tvoss> jdstrand, can you point ricmm and me to the branch (under the assumption there is one already?)
<lool> tvoss: It seems practical to me to combine default handlers and apparmor setup in the same wrapper
<ScottK> pitti: OK.  That should be fine.
<pitti> ScottK: but I can upload a fakesync now of course
<lool> tvoss: e.g. empty event handlers if the shared object doesn't provide this or that callback
<pmcgowan> tvoss: does this have any impact on making a qmlscene replacement for qml apps?
<jdstrand> tvoss: cool :) so, we'd like to watch the executor work (coordinate, review, get involved), so if that is turning up on BPs, can you ping me and sbeattie (sbeattie will be working on the launcher)
<pitti> ScottK: I'm going to do just that; let's cover all our bases
<ScottK> pitti: I'll trust you assessment of the urgency.  I mostly wanted to make sure you weren't waiting on beta 2 to release.
<lool> pmcgowan: We need one to set some env vars in any case
<ScottK> OK
<lool> albeit I'm not we have a list
<lool> *sure
<jdstrand> tvoss: there is not one already
<tvoss> pmcgowan, totally not
<pmcgowan> vg
<tvoss> pmcgowan, think about it like a helper that just bootstraps a sandboxed env
<jdstrand> sbeattie: ^ when you have something, can you point to tvoss and ricmm
<ricmm> jdstrand: tvoss lets entwine our names in single blueprint that contains the launcher/apparmor and executor story
<ricmm> from the point of view of the extended app lifecycle
<ricmm> not just shell->desktop
<tvoss> ricmm, +1
<pitti> ScottK: oh, it's a merge anyway, darn; I didn't notice that we got ubuntu changes; uploading
<ScottK> Great.  Thanks.
<jdstrand> ricmm: sure, we can move our prototype work items over to you-- we just did it where we did since we don't have anything yet :)
<ricmm> jdstrand: can we maybe have a call to explain how our lifecycle works right now? theres one thing that I deem important for this apparmor story and that is the resuming of previously-running applications after a power cycle and so on
<ricmm> we need to retore certain things, so all in all restore the sandbox... etc
<ricmm> anyways, would be cool to have a voice call about it as sometimes chat can be slow
<ricmm> jdstrand: no I'm fine with confinement being handled by your team, I find it awesome
<tvoss> ricmm, do you think the app lifecycle bp makes sense?
<ricmm> great work indeed
<ricmm> tvoss: yes
<jdstrand> ricmm: there shouldn't really be any concerns there-- apparmor policy is loaded into the kernel. any env variables are in memory and other stuff is filesystem, so a suspend/resume shouldn't need any particular attention
<jdstrand> ricmm: but maybe I misunderstand your question
<ricmm> jdstrand: this is a power cycle scenario, apps exit memory
<ricmm> and we restore from saved states
<ricmm> I'd like to discuss the security concerns about it
<ricmm> and update our lifecycle drafts
<jdstrand> ricmm: ok, please ask mdeslaur and jjohansen to attend the meeting
<jdstrand> (I can also be there)
<jdstrand> (mdeslaur is my techlead and jjohansen the apparmor lead)
<ricmm> awesome, thanks
<pitti> ScottK: uploaded
<ricmm> tvoss: jdstrand any date preference?
<tvoss> ricmm, not on a weekend :)
<ricmm> jdstrand: is there a blueprint for your work somewhere?
<ricmm> so we can kind of bridge between our relevant ones and add them to the call
<jdstrand> ricmm: this particular work item is in https://blueprints.launchpad.net/ubuntu/+spec/security-1304-appisolation-example
<ricmm> thanks
<ScottK> pitti: Thanks.  Accepted.
<pitti> infinity, Daviey: ^ if you need to rebuild the server ISOs for beta 2 for some reason, including postgresql-9.1 9.1.9 would be a very good idea; I'll warn about this in my blog post
<jdstrand> ricmm: re date preference> none on my end other than what tvoss said :)
<dholbach> didrocks, ready? :)
<didrocks> dholbach: seems that rickspencer3 abandonned my hangout, so yeah ;)
<rickspencer3> hi didrocks
<rickspencer3> sorry
<rickspencer3> otp
<rickspencer3> :/
<didrocks> no worry rickspencer3 :)
<dholbach> didrocks, we still have 20m - it's all good :)
<BigWhale> Greetings.
<BigWhale> ev: I was tolk I could bug you for an upload... :)
<ev> BigWhale: sure
<ev> well, depends on what you want to upload :)
<BigWhale> ev: a new release of Kazam. This one, to be more preceise: https://launchpad.net/kazam/stable/1.4.2
<BigWhale> 1.4.1 is already in raring, this is just a minor bugfix release.
 * ev looks
<pitti> xnox: I'll look at that tomorrow; too much psql troubles this afternoon
<tkamppeter> OdyX, I had to release cups-filters 1.0.33, there was a NULL check needed. I have updated also the BZR for Debian.
<ev> BigWhale: is there a bug for this?
<xnox> pitti: ack.
<BigWhale> ev: yes, there were two...
<BigWhale> They were targeted
<ev> BigWhale: numbers please :)
<BigWhale> #1100626 #1085438
<ev> BigWhale: ah, I meant targeted against the Ubuntu source package
<ev> for the upload
<ev> since it will require freeze exceptions
<ev> BigWhale: see: https://wiki.ubuntu.com/FreezeExceptionProcess
<BigWhale> Oh, none of them are.
<ev> BigWhale: would you mind creating one http://launchpad.net/ubuntu/+source/kazam/+filebug that requests the new version?
<ev> I'll then attach the debdiff to that
<BigWhale> ev: https://bugs.launchpad.net/ubuntu/+source/kazam/+bug/1164584
<ubottu> Launchpad bug 1164584 in kazam (Ubuntu) "New version request - 1.4.2" [Undecided,New]
<ev> thanks!
 * ev moves quick in his remaining 10% of battery
<BigWhale> Oh, thank you. :)
<ev> on*
<ev> BigWhale: I've updated the bug with the debdiff and some follow-up instructions
<BigWhale> ev: great, thanks!
<ev> once you have approval from the release team, let whomever is patch piloting know and they can shepherd the upload through
<ev> good luck! :)
<ev> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Ubuntu 12.10 released | Archive: Final Beta Freeze | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of hardy -> quantal | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<BigWhale> I just subscribed to a bunch of mailing lists... :>
<mdeslaur> ricmm: whoops, just got your invite...
<mdeslaur> ricmm: are you rescheduling it?
<OdyX> tkamppeter: ah, great, thanks.
<ricmm> mdeslaur: yes, rescheduling
<roadmr> Hey folks! I'm backporting a couple of python packages, A depends on B. I successfully backported B, but since it's only available in a PPA, I'm wondering how to indicate that the build for A should use that PPA to install B as a build-depends
<xnox> roadmr: > better ask similar questions on #ubuntu-packaginging. But simply uploading into the same ppa will use depends from that ppa during build.
<xnox> roadmr: well "biggest version wins", so packageB in ppa should be >> version number than in ubuntu archive proper.
<roadmr> xnox: oh perfect! thanks! and OK, I'll ask there next time, didn't know that channel existed :)
<zyga> hey
<zyga> xnox: so let's talk about command-not-found here
<xnox> zyga: \o/
<zyga> xnox: so there are a few pieces
<zyga> xnox: how to rebuild the data
<zyga> xnox: when to rebuild it
<zyga> xnox: when it should be documented
<zyga> xnox: er, where
<xnox> <roadmr> Hey folks! I'm backporting a couple of python packages, A depends on B. I successfully backported B, but si
<zyga> xnox: and where it should be running
<xnox> https://wiki.ubuntu.com/CommandNotFoundMagic
<zyga> xnox: that's the original spec IIRC
<xnox> with some *.pl URLs =))) ;-)
<xnox> both are 404 though.
<zyga> re
<zyga> sorry
<zyga> xnox: haah, I guess that's suxx.pl
<zyga> xnox: sorry, need to move networks, brb
<zyga_> re
<zyga_> xnox: so let me see that page again
<zyga_> xnox: so the code is on launchpad which mirros github (or should, I'll update that)
<zyga_> xnox: the code is on github.com/zyga/command-not-found
<zyga_> xnox: inside the code there are a bunch of readme files
<zyga_> xnox: I should probably update the layout a bit to look less sucky
<zyga_> xnox: what do you expect in terms of automation
<xnox> zyga_: at the moment, all I want is to run and update command-not-found-data.
<xnox> zyga_: later i want instructions on a wiki page how to do that.
<zyga_> xnox: ok
<zyga_> xnox: so assuming you have the archive
<zyga_> xnox: you need to look at https://github.com/zyga/command-not-found/tree/master/UnifiedDataExtractor
<zyga_> xnox: and run ...
<zyga_> xnox: probably create-binary-database
<zyga_> xnox: let me check that in practice
<zyga> xnox: heh, it's been a while, let me do some basic cleanups to use it
<mitya57> pitti: I have a huge patch for you @ lp:~mitya57/debian/sid/calibre/remove-embedded-libraries
<mitya57> it removes bundled copies of mathjax, python-markdown and unrar
<mitya57> and also fixes some minor issues such as not working clean target
<mitya57> known issues: (1) it still has embedded jQuery
<mitya57> (2) it tries to write to /usr/share/applications/defaults.list during build
<mitya57> (3) the mime file is not installed
<mitya57> none of these seems to be caused by my changes though :)
 * zyga cannot believe how crappy was his code just 8 years ago
<xnox> zyga: to be honest python2.4 was a different kind of animal.
<mitya57> note that embedded unrar is a "Severity: serious" bug, but it doesn't affect wheezy
<zyga> xnox: yeah but so were my python skills back then I guess :)
<zyga> xnox: I think this was my first python program as well
<zyga> xnox: and preinstalled on ubuntu, how cool is that :)
<zyga> xnox: I didn't stress that much back then
<zyga> xnox: the first commit is from 2006 though, I guess it's an import from something other than bzr, probably darcs
<zyga> xnox: ok, so to run it
<zyga> xnox: you need to run the scan script on the archive
<zyga> xnox: basically on any debs you may have around
<zyga> xnox: I've pushed a cleanup branch to git://github.com/zyga/command-not-found
<zyga> xnox: I'll make usability nice
<zyga> (enough)
<zyga> xnox: do you think this should be a native package?
<zyga> omg
<zyga> whoever ran this
<zyga> scan is still using /usr/bin/env python2.4
<zyga> :DDD
<roadmr> haha :)
<zyga> well, it probably runs on some arcane 10.04 systen
<zyga> system
<zyga> does 10.04 have python2.4?
<zyga> xnox: perhaps there is a branch that is used by cannonical that is not in trunk somewhere?
<maxb> Even 8.04 had python 2.5
<zyga> wooow
<zyga> I wonder when I really wrote that
<zyga> did 4.04 had python2.4?
<zyga> (times when python2.4 was new, OMG :)
<zyga> plars: hey
<zyga> roadmr: I kept making logging.debug("..." % (...)) mistakes back then :)
<roadmr> zyga: haha well the old you didn't have the present you to help with that ;)
<zyga> haha
<zyga> roadmr: anyway, even today, the code that implements get_alternatives in both crazy and amazing https://github.com/zyga/command-not-found/blob/master/UnifiedDataExtractor/scan#L41
<zyga> roadmr: it actually tries to interpolate for loops and keep track of shell variable values
<roadmr> wow! reading
<zyga> roadmr: it's not even close to correct but it improves results from 0% to something rather large
<zyga> roadmr: I don't have the raw data to compare but when I wrote that, cnf is only usable with that hack
<zyga> without it most of the things that people mistype/don't have around is not found as it is actually installed via alternatives system
<zyga> well
<zyga> back then mirroring the archive was hard
<zyga> I remember it filled my _spare_ disk
<zyga> and I took a week to download all the packages
<zyga> I guess I can start the mirror now, put my kids to bed and have the full archive after that
<dobey> it was a different time, before fiber was available everywhere
<zyga> dobey: yeah
<zyga> dobey: note: I'm still on ADSL, no fiber around where I live
<zyga> dobey: but it's 25MBit, not 0.1
<roadmr> wow heh
<zyga> I guess I can make it a bit better now
<zyga> like scanning partner repo
<zyga> and getting skype :)
<zyga> and scanning arm
<zyga> wow
<zyga> that's really old stuff there
<zyga> xnox: I'll get you the data for raring in a few hours
<zyga> xnox: what's the total deadline for this?
<xnox> zyga: between now and 18th of April.
<xnox> the updated command-not-found should be uploaded.
<jdstrand> ricmm: hey, I'd like to attend the meeting you scheduled for tomorrow, but I have a conflict. it is possible to move it a half an hour earlier?
<jdstrand> s/it is/is it/
<zyga> xnox: ok
<zyga> xnox: while I'll clean the code a bit we can just upload the data file
<zyga> xnox: do you know where are the armhf files in the archive?
<zyga> xnox: http://archive.ubuntu.com/ubuntu/dists/raring/ looking there I can only see i386 and amd64
<sarnold> zyga: ports
<sarnold> zyga: http://ports.ubuntu.com/dists/<release>/main/
<zyga> ah
<zyga> ok
<sarnold> zyga: https://wiki.ubuntu.com/SecurityTeam/FAQ#Architectures
<zyga> thanks
<mitya57> pitti: filed a MP (https://code.launchpad.net/~mitya57/debian/sid/calibre/remove-embedded-libraries/+merge/157195), have to go now
 * zyga starts mirroring the archive, I'll be back later when that is finished
<t1mp> rickspencer3_: ping
<zyga> xnox: ping
<zyga> xnox: quick question, let's say I'm going to build a manually-verified database that annotates _all_ ubuntu packages with the update-alternative targets that each particular package might or does use; I could then automatically annotate the control files of all of those source packages with the appropriate meta-data, could we then merge this (big) delta back into debian so that we don't have to maintain it and so that command-not-found gets reliable, perfect 
<zyga> slangasek: ^^ (maybe you can also say how crazy I am :)
<zyga> xnox: I'll start with a standalone database (text, editable) that keeps each package-version -> mapping of update-alternatives used in version control
<zyga> xnox: then try to get the latest version of all those packages in source form, patch the control file, generate a diff from that
<zyga> xnox: do you think that's the right approch to getting that information back to debian?
<xnox> zyga: I'm slightly confused by above. In general we already have debtags on debian side for "annotating" packages. As all of this data gets volatile very quickly.
<zyga> xnox: could you quickly describe those debtags?
<zyga> xnox: are they in the source package or somewhere on the side?
<zyga> xnox: (I remember this discussion years ago, I remember someone said 'ah yes, debtags can solve that', but debtags were still under discussion back then)
<zyga> xnox: my goal is to have _reliable_ meta-data as to what update-alternatives targets each package uses
<zyga> xnox: that data is required for command-not-found
<xnox> zyga: the general ideas about such things tends to end up in "AppStream" proposals (multiple incompatible with same name but different implementations) such that package self annotate a bit, but archive publishing software (dak in debian, launchpad in ubuntu) further scans source/binary packages and publishes one co-herent all-purpose index.
<zyga> xnox: instead of mainitaining this data separately I'd like to get it back to debian
<xnox> neither of which are at a usable state at the moment.
<xnox> zyga: http://debtags.debian.net/search/?q=game
<zyga> xnox: this cannot be automated
<zyga> xnox: it's the same kind of data as Depends or Build-Depends
<xnox> zyga: sure. with AppStream proposal parts that cannot be automated live inside the package (source or binary as appropriate) other parts which can be automated live in archive software which merges the two together.
<zyga> xnox: I see that, quickly and ugily as X-Update-Alternatives-Targets: /usr/bin/vim.real=/usr/bin/vim
<zyga> xnox: so I don't care about the automated part simply because it's not automated in any way at all
<zyga> xnox: how does one express the non-automated variant of that in the control file?
<xnox> zyga: the beauty of update-alternatives is that we have packages from 3rd parties hooking into that, e.g. like google-chrome web-browser and packages comming from outside of the archive (e.g. things like extra/new versions of emacs, postgresql etc)
<zyga> xnox: great
<zyga> xnox: so what?
<zyga> xnox: for high-profile packages we can keep side-data in command-not-found itself
<zyga> xnox: for the archive, I'd like to keep this _in_ the archive, otherwise it's something that's forever broken
<zyga> xnox: it's something that packages would have to maintain
<zyga> xnox: the benefit is accurate hit database from commmand-not-found
<zyga> xnox: hint
<zyga> xnox: I'm willing to do the initial scan myself, manually
<xnox> zyga: i think packages will ok self declaring "i update-alternative emacs with vim.real binary I provide", and then one can quickly scan and collate all those that declare "i update-alternative emacs"
<zyga> xnox: I'm just looking for a way to contribute this back
<zyga> xnox: packages or packages?
<xnox> zyga: it's best to raise that on debian-devel with a sample scan results & carefully explaining what you are trying to achieve. Prepare for a flamewar of being shot down with "apt-archive Package index is too big already" and "we don't need this" and "one day when dak supports this we may consider it"
<xnox> zyga: but hey maybe there are other people who where looking to achieve this as well.
<zyga> xnox: the last item is exactly what I want to avoid
<xnox> zyga: plan your email well =)
<zyga> xnox: I want to get this done done for ubuntu
<zyga> xnox: getting this to debian is a bonus
<zyga> xnox: sure
<xnox> zyga: ubuntu-devel then =)
<zyga> xnox: I'll get the initial database today/tomorrow
<zyga> xnox: do you think I should discuss this in ubuntu over debian first?
<zyga> xnox: given my history of collaboration with debian, I'd rather not start wrong again
<xnox> zyga: the amount of overlap between the two mailing list is ever increasing =) no harm imho to start it on either lists & bounce to the other mailing list after initial rough corners are considered.
<zyga> ok
<zyga> xnox: I'll start with ubuntu-devel to get the c-n-f goal done
<ausxxh_> ubuntu/debian defaults to IET while Redhat defaults TGT, openstack/cinder now defaults to TGT due to ubuntu's efforts, confused
<rickspencer3> t1mp, hi
<t1mp> rickspencer3: hi, I saw your bug report https://bugs.launchpad.net/ubuntu-qtcreator-plugins/+bug/1161910 and created an MR that should fix it.
<ubottu> Launchpad bug 1161910 in Ubuntu QtCreator Plugins "creating a single page app adds a weird bar to the top of the screen" [High,Confirmed]
<t1mp> rickspencer3: it is eod for me, but feel free to try out my changes and comment on the MR
<rickspencer3> thanks t1mp, let me know if you want me to test it in some way
<rickspencer3> t1mp, will do
<t1mp> rickspencer3: thanks. You didn't include code with the bug, but if there is still some weird positioning happening, make sure that you do not set the anchors of the Page (that should be automatic)
<rickspencer3> t1mp, well, it was a defualt app
<rickspencer3> so, it should be easy for me to test it out
<doko> ogasawara, the gcc-4.7.3 release candidate is currently building in raring. the version is now set to 4.7.3, just in case that you still depend on that
<doko> jtaylor, why the syncs of the new java lib packages?
<jtaylor> doko: bugfix releases
<doko> 1.1.0?
<jtaylor> yes I was confused to
<jtaylor> but the changes lists only bugfixes, diff is also small
<jtaylor> I was asked by the debian maintainer to sync them
#ubuntu-devel 2013-04-05
<zyga> xnox: ping
<zyga> xnox: I think I solved update-alternatives pretty much once and for all https://github.com/zyga/command-not-found/commit/2ee281a9750c1240c33af99b9ea4f3b84d6b44f1
<zyga> xnox: I have a large database, I'll find a new home for it soon
<zyga> xnox: using that db, we can build 100% reliable c-n-f and rebulild it against new packages without much difficulty
<zyga> xnox: http://screencloud.net/v/7uOD
<saiarcot895> Before merging a branch into Ubuntu universe, do I need to sign an agreement with Canoical?
<RAOF> saiarcot895: No, but the question probably betrays a misunderstanding off how uploading to Ubuntu works.
<RAOF> Let's see if we can sort that out...
<RAOF> saiarcot895: Canonical requires a CLA for non-trivial patches to Canonical projects - these being things like Upstart, Unity, LightDM, etc.
<RAOF> saiarcot895: Ubuntu is not a Canonical project :)
<saiarcot895> ok
<saiarcot895> I saw that link in a Ubuntu doc and worried if I was missing something
<ion> Huh, LightDM is a Canonical project? Didnât know that.
<RAOF> ion: Yeah, it got adopted around... Precise?
<RAOF> More generally, Ubuntu is quite a different thing to Upstart, LightDM, etc; Ubuntu is largely an aggregation of other projects, so it doesn't really make sense to ask for a contributor agreement.
<ion> /usr/share/doc/lightdm/copyright doesnât seem to mention Canonical.
<maslen> Can someone succinctly explain the relationship between existing open-source projects that are integrated into Ubuntu and Ubuntu itself?
<dholbach> good morning
<pitti> Good morning
<zyga> good morning
<cousteau> I'm getting this error on update-manager due to a LibreOffice PPA:  libreoffice-core: Depends: libgcc1 (>= 1:4.1.1) but 1:4.6.3-1ubuntu5 is installed
<cousteau> question:  isn't 1:4.6.3-1ubuntu5 >= 1:4.1.1 ?
<dholbach> Sweetshark, ^ maybe you know what's going on there?
<cousteau> oh, Sweetshark is here...  good
<cousteau> (looks away though)
<cousteau> although my question is more related to why (1:4.6.3-1ubuntu5 >= 1:4.1.1) is false
<ogra_> is that a release upgrade ?
<cousteau> a precise -> quantal?  no
<ogra_> i.e. from one release to the next
<ogra_> ah. k
<cousteau> just regular automatic updates
<cousteau> (from a PPA)
<ogra_> i know we once had a function that kept PPAs at lower prio in such cases ... shouldnt happen in regular updates (and i dont think its still there anyway)
<geser> cousteau: does it happen too when you try to upgrade with apt-get?
 * zyga updated his update-alternatives scan to 25% of the archive https://github.com/zyga/ubuntu-update-alternatives-data/blob/master/update-alternatives-db.ini
<cousteau> apt-get -s install -f didn't say anything weird...  let me try apt-get upgrade
<cousteau> (it's apt-get upgrade, right?)
<geser> yes
<cousteau> apt-get -s upgrade -> You might want to run 'apt-get -f install' to correct these.  The following packages have unmet dependencies:  libreoffice-core : Depends:  libreoffice-common (> 1:4.0.2~rc1) but 1:4.0.1~rc2-0ubuntu1~precise1~ppa1 is installed
<cousteau> now it's complaining about a totally different pkg...  why did it mention libgcc1 before?
<mitya57> because libreoffice-core is unpacked but has unmet dependency
<cousteau> ok, why isn't libreoffice-common getting updated to 1:4.0.2?
<geser> try if "apt-get install libreoffice-core libreoffice-common" gives a better hint (might have to repeat it with additional packages till you see the final error)
<mitya57> what does "apt-get install libreoffice-common" say for you?
<cousteau> hmm, it's update-manager the one that doesn't let me install libreoffice-common...  let me see
<geser> which PPA is that?
<cousteau> apt-get -s install libreoffice-common  ->  [...] The following packages will be upgraded:  libreoffice-common   1 upgraded, 0 newly installed, 0 to remove and 14 not upgraded.  12 not fully installed or removed.   Inst libreoffice-common [1:4.0.1~rc2-0ubuntu1~precise1~ppa1] (1:4.0.2~rc1-0ubuntu1~precise2 LibreOffice PPA:12.04/precise [all])  [...]
<mitya57> I see there are 14 not upgraded packages, can you run "apt-get dist-upgrade" and see what happens?
<Sweetshark> dholbach, cousteau: Hmm, I dont understand the issue either.
<Sweetshark> dholbach: Im not aware of other reports wrt -core -> libgcc deps .... strange.
<geser> it would be nice to know if cousteau could resolve this
<Sweetshark> geser: yes, as seen on https://plus.google.com/u/0/101094190333184858950/posts/byfaUDmpYCn there is clearly demand for that update to be in raring.
<Sweetshark> dholbach: ahh, thats in the precise ppa!
<dholbach> I have no idea - I just thought I'd bring the two of you in touch :)
<cousteau> geser, not yet
<cousteau> maybe just installing libreoffice-common fixes the issue
<cousteau> (and then marking it as auto installed...  how is that done in apt-get?)
<geser> with "apt-mark"
<ogra_> did you try dist-upgrade ?
<cousteau> yup, apt-mark
<ogra_> it should tell you about adding/removing
<cousteau> I don't want to try anything that fixes the system until I find out the problem...  how would I be contributing if I just fix my system?
<cousteau> (or am I the only one affected by this problem?)
<ogra_> dist-upgrade will have a y/n question
<ogra_> it never does anything automatically if it actually adds or removes
<Sweetshark> dholbach, cousteau: precise is still at 4.0.2~rc1, which needed a dist-upgrade -- the 4.0.2~rc2 release in raring should have that fixed, backports for quantal/precise with hopefully show up soon ...
<cousteau> apt-get -s dist-upgrade   ->  The following packages have unmet dependencies:   libreoffice-core : Depends: libreoffice-common (> 1:4.0.2~rc1) but 1:4.0.1~rc2-0ubuntu1~precise1~ppa1 is installed   libreoffice-emailmerge : Depends: libreoffice-common (>= 1:4.0.2~rc1) but 1:4.0.1~rc2-0ubuntu1~precise1~ppa1 is installed   You might want to run 'apt-get -f install' to correct these.
<ogra_> theer you go
<Sweetshark> cousteau: yep, should be fixed
<cousteau> (on an unrelated note, I'm actually getting "You might want to run 'apt-get -f install' to correct these" BEFORE the list of packages to be fixed)
<geser> did you try to install a deb with dpkg? I'm wondering why apt suggests to run "apt-get -f install"
<Sweetshark> cousteau: should be fixed http://anonscm.debian.org/gitweb/?p=pkg-openoffice/libreoffice.git;a=commit;h=cbb64e23f4023b16d449d33ac94c75f0c7933fce
<cousteau> The problem seems to be that, for some reason, libreoffice-core 1:4.0.2 has been installed but libreoffice-common hasn't (still at 1:4.0.1).  This has broken apt-get, which will refuse to install libreoffice-common 4.0.2 because there are unmet dependencies in the system.
<cousteau> Silly apt-get doesn't realize that the solution is precisely to install this package it refuses to install.  I guess I'll have to -f
<geser> how did you manage to install this version and not the other packages from libreoffice as they get all build from the same source package
<cousteau> ok, running `sudo apt-get install -f`; I guess that'll fix the problem.  (running it with -s said it would install/upgrade libreoffice-common)
<cousteau> geser, no idea.  Aliens?
<cousteau> I remember that yesterday I had a problem with upgrades, but I think it was just the broken dependency thing
<cousteau> I hope this didn't have to do with a pre/post install config
<geser> cousteau: which arch are you using? i386 or amd64? and which PPA is that?
<cousteau> ok, apt-get install -f seems to have fixed the problem
<cousteau> amd64,  http://ppa.launchpad.net/libreoffice/ppa/ubuntu precise main
<cousteau> (using xubuntu, if that's relevant, but I guess it isn't)
<Sweetshark> ricotz: ping? could you update the precise/quantal backports?
<Sweetshark> ah, not here.
<geser> cousteau: when did you last run "apt-get update"? you might have updated the Packages files in the time window where amd64 was finished building but not i386 (incl libreoffice-common)
<geser> this would explain why you could update some libreoffice packages but not all
<cousteau> geser, how can I know that?  is there an apt-get update history or something?
<geser> in that case try updating the package lists and see if your problem is gone (amd64 and i386 are both build now)
<cousteau> I opened the update manager at approx 19:45+0200 (i.e. 17:45 Z)
<cousteau> geser, I tried that and it didn't.  I fixed it by running `sudo apt-get install -f`
<geser> good that it's fixed now, but I don't understand what went wrong in the first place
<cousteau> me neither
<cousteau> geser, probably what you said.  -core 4.0.2 was updated before -common 4.0.2 was available, and installing -core 4.0.2 broke apt-get, so when -common was available it couldn't be installed
<cousteau> or maybe -core 4.0.2 and -common 4.0.2 were made available at the same time but -core was installed before -common and that immediately broke -core
<cousteau> libreoffice-core depends libreoffice-common (> 1:4.0.2~rc1), but libreoffice-common doesn't depend on libreoffice-core.  So none of this mess would have happened if the update for -core had been held until -common were available.
<geser> apt usually takes care of that marks such packages on hold during an upgrade till the dependencies are available
<Sweetshark> cousteau: i would assume you hit https://bugs.freedesktop.org/show_bug.cgi?id=62972 and did not notice
<ubottu> Freedesktop bug 62972 in Libreoffice "Cannot upgrade from Ubuntu 12.04.2" [Major,Resolved: notourbug]
<geser> ah, that might explain the "apt-get -f install" call to let dpkg finish the configure of some packages
<cousteau> I haven't tried to open LibreOffice; I wouldn't know
<cousteau> so, ubuntu bug or LO bug?
<cousteau> actually, why do I care?  it's already fixed
<cousteau> ...well, there's always the curiosity thing
<geser> if you got hit by this bug then it's a packaging bug in the LO package (don't know if you count this as ubuntu bug or LO bug)
<Sweetshark> cousteau: it was a ubuntu bug (well, actually a debian bug that we merged in ;) ) -- the contents of the mailmerge package got move to -core and making sure that the old -mailmerge and the new -core package are not installed at the same time was fumbled.
<dbarth> xnox: ping? is there a problem with the package upload for thin client? can i do something to help?
<cousteau> so it was a bug in the ubuntu build system?
<cousteau> i.e. not in the ubuntu installer, but in the thing that builds packages and distributes them to ubuntu users
<xnox> dbarth: no problems. the archive is frozen and it's pending review & accept.
<dbarth> ah ok
<Sweetshark> cousteau: not in the build system, in the package description -- the debian/control file to be exact: http://www.debian.org/doc/debian-policy/ch-controlfields.html
<xnox> dbarth: we just have to wait =)
<cousteau> so DEBIAN/control was incorrectly generated, or incorrectly read by apt-get?
<geser> correctly generated but with the wrong data (error of the package maintainer)
<Sweetshark> cousteau: incorrectly generated
<cousteau> so a server-side problem
<cousteau> i.e. "an ubuntu bug" where "ubuntu" is the package build system, not the ubuntu installer
<zyga> xnox: hi
<zyga> xnox: I've sent an email to ubuntu-devel last night
<doko> pitti, would it be ok to discard/hold the language pack uploads? the test rebuild should finish first, and afaiu, these will be re-uploaded next week anyway?
<seb128> doko, it would be useful for translators to have those so they can verify what translations are incomplete or buggy
<seb128> so they can fix things for the update next week
<pitti> doko: no problem from my side, Monday will be the next cronjob anyway
<pitti> doko: but I thought infinity already mass-rejected them
<tvoss> pitti, ping
<pitti> hello tvoss
<tvoss> hey pitti :) I'm looking into fanotify right now. Does it work in 13.04/12.10?
<pitti> tvoss: I haven't used it in ages, but I don't see why it shouldn't work
<tvoss> pitti, cool :) I was just curious and wanted to check it out, if file moving/renaming is delivered to userspace in its current version or not
<rbasak> distutils.sysconfig.get_python_lib(True, True) gives me /usr/lib/python2.7 in raring. But libpython2.7.a is in /usr/lib/python2.7/config-x86_64-linux-gnu. What's the general way of getting this latter path? I know python-config --ldflags will give me the right thing, but this particular acinclude.m4 isn't using it and I think it would be a more trivial patch if I could extract just the right path where libpython2.7.a can be found.
<smb> doko, https://launchpad.net/ubuntu/+source/xen/4.2.1-0ubuntu2/+build/4469971 <-- Internal compiler error. I am currently trying a local sbuild so I could pull things off...
<doko> smb, please wait until -23ubuntu2 is available
<smb> doko, Ah ok.
<pitti> doko: mass-rejecting the langpacks, FYI
<doko> pitti, thanks!
<pitti> doko: however, with the projected 8 days of ETA there will be new cronned uploads
<doko> I know ...
<pitti> if only we had some way of temporarily spawning more servers in the internet out there to help with mass rebuilds...
<pitti> we could call this "sky"
<doko> pitti, I assume policykit-desktop-privileges is targeted for raring?
<pitti> yes
<pitti> BigWhale pointed out that inconsistency
<pitti> it doesn't change the default install behaviour, though
<smb> doko, Hm, maybe dumb question -23ubuntu2 or *what*?
<doko> smb, https://launchpad.net/ubuntu/+source/gcc-4.7/4.7.2-23ubuntu2
<smb> Ah ok. I was confused by the dependency gcc package version
<smb> Daviey, ^ I try to remember we probably need to kick the build again later... maybe next week... :)
<Daviey> smb: super
<doko> smb, will be finished in 1h
<smb> doko, okok, maybe this week still. ;)
<jdstrand> seb128: fyi, http://people.canonical.com/~jamie/archive-grep/seb128-com.ubuntu.SystemService.log
<seb128> jdstrand, hey, happy friday!
<seb128> jdstrand, thanks
<jdstrand> seb128: hi! you too and you're welcome :)
<seb128> pitti, ^
<ogra_> oh, do we rename the system service to be seb128.system.service ?
<ogra_> cool !
<seb128> lol
<ogra_> :)
<seb128> ogra_, with french strings included by default ;-)
<ogra_> haha
<seb128> pitti, so it seems it's only update-notifier to fix
<xnox> ogra_: systÃ¨me.de.service.seb128
<ogra_> oh, indeed, i forgot ... french now
<rbasak> distutils.sysconfig.get_python_lib(True, True) gives me /usr/lib/python2.7 in raring. But libpython2.7.a is in /usr/lib/python2.7/config-x86_64-linux-gnu. What's the general way of getting this latter path? I know python-config --ldflags will give me the right thing, but this particular acinclude.m4 isn't using it and I think it would be a more trivial patch if I could extract just the right path where libpython2.7.a can be found.
<pitti> seb128: alors qui semble trÃ¨s facile
<pitti> seb128: (excusez-moi, j'ai Ã©tÃ© Ã  une rÃ©union
<seb128> pitti, il n'y a pas de problÃ¨me
<pitti> seb128: AFAICS it only calls is_package_system_locked
<kapat> Hello, just upgraded to raring beta and X won't start. Ideas? where (and how) should I submit bug reports?
<pitti> which is basically a set of lock file existence tests
<seb128> pitti, should be easy to replace
<pitti> so we should completely drop that and just test for those locks
<seb128> right
<pitti> and then, python daemons -= 1
<seb128> the proxy thing is still annoying
<seb128> I need to talk to cyphermox to see if there is a plan to get that done in nm
<cyphermox> proxy?
<cyphermox> upstream wants to integrate it, I had a WI but since it's not priority... and there has been some interest from someone to do the work on the ML
<xnox> kapat: raring suport at > #ubuntu+1
<doko> smb: xen fails now correctly ;-p with:
<doko> intr.c: In function 'vmx_intr_assist':
<doko> intr.c:305:17: error: request for member 'arch' in something not a structure or union
<doko> intr.c:306:17: error: request for member 'arch' in something not a structure or union
<doko> intr.c:307:17: error: request for member 'arch' in something not a structure or union
<doko> intr.c:308:17: error: request for member 'arch' in something not a structure or union
<doko> make[8]: *** [intr.o] Error 1
<smb> doko, Hm, ok. Apparently something only working on 64bit... But at least a more helpful failure
<barry> doko: any feedback on my email from last night?
<doko> barry, on the bug report
<barry> doko: thanks
<doko> barry, the python builds are still configued with --enable-fpectl. I don't think that makes any difference
<barry> doko: ack.  i'm inclined to just apply the hack and be done with it
<zyga> xnox: ping
<xnox> zyga: hola.
<zyga> xnox: I got some progress since yesterday
<zyga> xnox: first, I solved the problem with flaky update-alternatives data, it's now almost perfect and the small percentage of mistakes are tagged and can be corrected (so far I have < 200 cases but after fixing one the system learns and can cascade the solution to similar packages)
<zyga> xnox: I've also mirrored half of the archive and rewrote/improved the scanning tools
<zyga> xnox: by Monday I should have a new, pratically perfect database for precise, quantal and raring
<zyga> xnox: then we can issue an update to the source package with the new database
<zyga> xnox: does that sound okay?
<pitti> awe: hey Tony, how are you?
<zyga> xnox: I've tweeted about the progress, there is a new project that holds the database and I've sent an email to ubuntu-devel
<zyga> xnox: (sadly no response so far)
<pitti> awe: I'm currently writing network tests, and stumbled over a CRDA problem that you might know about
<xnox> zyga: yes. I can upload the updates to raring/quantal/precise.
<zyga> xnox: great
<zyga> xnox: the data is text and I can also produce some diffs so that we can do some level of validation
<awe> pitti, hey
<awe> tests are good
<awe> as for crda, be ready for a world of confusion... ;)-
<awe> what's troubling you right now?
<awe> maybe do a quick mumble?
<pitti> awe: so, b/g test cases work fine; for A I chose channel 36, as it shoudl be available in most parts of the world
<awe> ok
<pitti> awe: if I run my tests locally, they always work; but if I run them in a fresh KVM instance, they fail with "channel [0] (36) is disabled for use in AP mode, flags: 0x57"
<pitti> awe: so my question is: do you know how we set the domain for devices? I know of /lib/udev/rules.d/40-crda.rules which is supposed to set it through that helper
<awe> why are you running in a container?
<pitti> awe: but /etc/default/crda has nothing set on my workstation either, so I suppose it uses something else to determine the domain?
<awe> pitti, we actually don't set the domain for devices
<pitti> awe: we want this as autopkgtest, don't we?
<awe> the drivers handle it
<pitti> awe: so I'm trying to understand why it works on my workstation but not in kvm
<pitti> awe: I actually got it to work in kvm if I add a country_code=EU to hostapd's config
<awe> pitti, I'm not that familiar with the autopkgtest framework....  but I do know that networking inside containers/vms is not trivial
<pitti> but apparently that only works teh second time, so there's something async going on
<awe> especially when you need to work with wifi drivers
<pitti> awe: no worries, I got those parts covered
<awe> pitti, ubuntu doesn't set a default regdomain
<pitti> awe: I now have A/B/G networks, open and wpa2, and IPv4/6 coverage
<awe> pitti, are you running against real drivers, or using the passthru code?
<awe> ( ie. driver passthru )
<pitti> awe: just mac80211_hwsim
<awe> right
<pitti> so real driver, but no real hw
<awe> well, some might take issue with "real" driver
<pitti> awe: but with the same hwsim driver it works on my workstation
<awe> ie. real being non-sim
<pitti> awe: ok, I guess I'll have to dissect that a little further then
<pitti> awe: I just thought you might have some idea how that can happen
<awe> can we do a quick mumble?
<pitti> sure
<pitti> awe: ok, apparently hwsim doesn't support setting crda; "sudo COUNTRY=DE crda" works on my workstation, but fails in kwm; I guess that depends on the loaded drivers
<doko> pitti, seb128, didrocks: could somebody of you look at the rhythmbox ftbfs? https://launchpad.net/ubuntu/+archive/test-rebuild-20130329/+build/4443117 all archs
<seb128> doko, it's on my list, sorry I didn't go to it today, I might still manage to do that before calling it a day, otherwise will do on monday
<doko> np
<pitti> awe: ah, so "sudo iw reg get" and "sudo iw reg set EU" are the magic commands; http://wireless.kernel.org/en/users/Documentation/iw#Updating_your_regulatory_domain and http://wireless.kernel.org/en/developers/Regulatory are quite helpful
<pitti> awe: that works very well now
<pitti> awe: I'll also change the tests to look at "iw" instead of "iwconfig" to verify connection, etc. :)
<pitti> so, good night everyone, enjoy your weekend
<awe> yes, although they're only magic, when the driver supports the incantation!  ;D
<pitti> awe: why? that's set by cfg80211, not by the hw driver
<pitti> awe: or you mean it won't work for drivers which don't use the cfg80211 framework?
<awe> yes, but cfg80211 has to talk to the driver at some point
<awe> it's just the messenger
<awe> ack
<awe> ( re: drivers that don't use cfg80211 )
<pitti> awe: I think what happens here is that hostapd asks the wireless stack (i. e. the equivalent of iw reg get) about the country
<pitti> awe: I guess the hwsim kmod doesn't care, as it doesn't actually emit anything
<awe> yea, definitely... wpa_suppl has similar code
<pitti> anyway, seems I have all pieces together now \o/
<awe> cool
<awe> glad I could help
<doko> jtaylor, is there a FFe for scilab?
<jtaylor> doko: its essentially translation update
<jtaylor> the diff is only large as its a normal dist tarball instead of git archive
<jtaylor> if you drop translations and the missing makefiles the diff is almost zero
<jtaylor> raring currently has git20130321, only ~two weeks old
<jtaylor> (and I got an ffe for that when it when in before you ask)
<CheezeMonkey> Just to let you guys know, ubuntu finally installed after i unplugged two of my three harddrives, probably had something to do with the many partitions i have
<CheezeMonkey> thanks for your help, especially xnox for the link
<jtaylor> CheezeMonkey: you have the installer hanging on the second screen issue?
<CheezeMonkey> jtaylor: yep
<jtaylor> CheezeMonkey: which link? have that issue too :(
<jtaylor> did you unplug internal disks?
<jtaylor> I tried unplugging my external ones with no success
<CheezeMonkey> jtaylor: https://launchpad.net/bugs/1080701
<ubottu> Launchpad bug 1080701 in ubiquity (Ubuntu Raring) "After 'Preparing to install Ubuntu' screen, raring installation hangs" [High,Confirmed]
<CheezeMonkey> For me, i have three internal harddrives. Two of them are used, with quite a few (probably excessive) partitioning.
<jtaylor> I have many many partitions too
<jtaylor> seems to be the common factor in this bug
<CheezeMonkey> I took those out, and left the third smaller one inside, which had only two partitions (one being a swap partition for linux).
<CheezeMonkey> then i tried the installer again, and it worked like a charm :)
<jtaylor> hm there is something weird on the arm builders
<jtaylor> scilab failed with a "stray \38" in a source file, the file is fine
<jtaylor> I just retried it and it worked
<jtaylor> how can that happen?
<jtaylor> *armhf
<Laney> keep watching the buildd's history and see if it builds subsequent stuff correctly
#ubuntu-devel 2013-04-06
<halfie> does Ubuntu maintain a list of packages which must be hardened for security reasons?
<kees> halfie: everything hardened by default in Ubuntu
<kees> (though you may have a more specific definition of "hardened")
<doko> kees!
<halfie> kees, are you sure? by hardening I mean stuff like RELO / PIE being enabled.
<halfie> it seems that the Ubuntu compiler doesn't enable hardening by default. so do you enable hardening for every packages on individual basis?
<jtaylor> halfie: since ~quantal or precise yes
<jtaylor> automatic hardening is not enabled anymore
<halfie> but like kees says hardening is enabled for almost all packages? correct?
<halfie> seems hard to believe
<jtaylor> probably almost all in main
<jtaylor> in universe coverage is probably less good
<halfie> cool :)
<halfie> I can use Ubuntu's example to drive hardening in Fedora then
<jtaylor> I think some things may still be enabled by default, like FORTIFY_SOURCE_
<halfie> and same rules apply on both x86 and AMD64, right? if a package is hardened then it is hardened on both?
<jtaylor> yes, though pie is seldom enabled
<jtaylor> on i386 it has a rather large performance impact
<halfie> aha I see. yes on i383 PIE is crap.
<halfie> so do you disable PIE on i386 then ?
<halfie> but enable it for the same package when building for AMD64
<jtaylor> its enabled on per package basis, so far I know its usually all off or all on
<halfie> ok, makes less of a maintenance burden this way I guess.
<jtaylor> you may want to read this: http://wiki.debian.org/Hardening
<halfie> jtaylor, already been there :). I have scanned all Fedora packages using custom written script. Now I am planning to do the same for Ubuntu.
<halfie> I will be using "python-debian" package for doing this
<jtaylor> we already have scripts for checking if hardening is enabled
<jtaylor> hardening-check
<jtaylor> it does have some sisues though
<halfie> jtaylor, does it work on any platform and does it run straight on .deb files without installing them?
<jtaylor> it works on ELF files
<halfie> my script doesn't need packages to be installed and it doesn't touch the disk except for reading. I have "checksec" for running on ELF files.
<jtaylor> what does it do?
<halfie> I will take a look at hardening-check though. Maybe it has some neat ideas :)
<halfie> https://github.com/kholia/checksec <== it scans package repositories and figures out various bits
<halfie> Now I am planning to add .deb support to it.
<halfie> BTW is there a Python / Ruby library for parsing .deb files? "python-debian" is kind of broken.
<jtaylor> broken in what way?
<halfie> jtaylor, debian packages use "xz" compression now I believe? python-debian doesn't work for such files and python 2.x doesn't have lzma module
<halfie> I am porting python-debian to Python 3
<infinity> halfie: You may be interested in http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=506861
<ubottu> Debian bug 506861 in python-debian "python-debian: Please add support for lzma-compressed debs" [Wishlist,Open]
<jtaylor> isn't pylzma support backported to py2?
<halfie> infinity, awesome! :) you saved me hours of work :)
<jtaylor> there is a python-lzmq module
<jtaylor> ah thats also mentioned in the bug :)
<halfie> also "xz" is the recommend scheme?
<infinity> dpkg-deb defaults to gzip, but xz and bz2 are both widely used.
<infinity> dpkg-deb (and python-debian) are meant to abstract that away, so you never need to care.
<infinity> Well, python-debian would do so with the patch in that bug. :P
<halfie> I am giving up porting to Python 3. It is hard :)
<infinity> It's already ported in unstable, quantal, and raring.
<halfie> to Python 3?
<infinity> The patch in that bug applies to said ported version, if I recall.
<infinity> Yes.  Binary package is python3-debian.
<halfie> so the "python2-debian" has no support for "xz" ?
<infinity> Neither one has support for xz, without that patch applied.
<jtaylor> the changelog says it has support
<jtaylor> as the mentioned bug in python is fixed
<infinity> If you read the notes on the patch, it works with both py2 and py3, but cheats with py2 by just forking the xz binaries instead of using a module.
<doko> you give up early ...
<halfie> got disconnected. thanks infinity !
<halfie> yay! success :)
<halfie> now where exactly is metadata like packager's name, checksums stores? in the "control" section?
<jtaylor> doko: I somehow managed to break python installation in a autopkgtest, see line 3429
<jtaylor> doko: I can't seem to create a minimal testcase though :/ maybe you already see the cause
<doko> jtaylor, which line/where?
<jtaylor> the issue is python2.7-minimal is configured before libpython2.7-minimal
<jtaylor> http://paste.ubuntu.com/5682267/
<doko> maybe that should be a Pre-Depends ...
<pjotr> Hello, I encountered a bug in Ubiquity that I've reported on Launchpad:
<pjotr> https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1165344
<ubottu> Launchpad bug 1165344 in ubiquity (Ubuntu) "Ubiquity hangs on disk with many partitions" [Undecided,New]
<pjotr> cjwatson: maybe you could take a look at it (if you have the time, of course....)?
<jtaylor> pjotr: probably a duplicate of bug 1080701
<ubottu> bug 1080701 in ubiquity (Ubuntu Raring) "After 'Preparing to install Ubuntu' screen, raring installation hangs" [High,Confirmed] https://launchpad.net/bugs/1080701
<pjotr> jtaylor: yes, that looks like the same bug.... I'll tag mine as a duplicate. Thanks. :-)
<cjwatson> halfie: Confused as to why you're porting python-debian to Python 3.  I did that port last year or so.
<cjwatson> Oh, yeah, infinity already said that.
<doko> jtaylor, please could you check https://launchpad.net/~doko/+archive/ppa ?
<jtaylor> doko: seems to fix my problem
<jtaylor> does it really need a pre-depends? isn't it the postinst that fails?
<doko> jtaylor, please check it without it
<halfie> cjohnston, thanks for porting python-debian to Python 3.
<cjwatson> yw
<halfie> I am running Fedora and trying to analyze Ubuntu packages. What would be a good way to get all the packages in "main" pool. It would be great if I could only get the latest versions of programs.
<halfie> If there is no "bright" idea, then I will run rsync as the last option.
<siretart> halfie: try 'debmirror'
<siretart> halfie: http://manpages.ubuntu.com/manpages/precise/en/man1/debmirror.1.html
<halfie> siretart, thanks, I am reading about it on https://help.ubuntu.com/community/Debmirror
<halfie> how do I interpret this mode value "493" ? I found it in sudo 's .deb file.
<cjwatson> halfie: on which file?
<halfie> 493 ./usr/sbin/visudo
<cjwatson> halfie: I think you would be less confused if you quoted modes in the conventional octal base, not decimal
<cjwatson> 493 decimal == 755 octal
<cjwatson> i.e. -rwxr-xr-x
<halfie> oh, I could not guess the base earlier :) thanks!
<cjwatson> The oct() builtin in Python may help
<halfie> do you know a package which has a setuid file?
<siretart> su?
<cjwatson> /usr/bin/sudo
<cjwatson> in the sudo package you're already looking at
<halfie> oh right, its right in front of me
<halfie> BTW PIE and  RELRO are disabled for sudo
<cjwatson> Not in the current version
<cjwatson> http://paste.ubuntu.com/5682875/
<cjwatson> that's sudo 1.8.6p3-0ubuntu3 on amd64
<halfie> now where did I get my package from then :S ?
<cjwatson> I don't think that's a recent change either ...
<cjwatson> Well, first you might like to cite which version you're looking at?
<halfie> sudo_1.6.9p10-1ubuntu3.10_amd64.deb <== seems to be old
<halfie> I got it from archive.ubuntu.com
<cjwatson> That's the version in hardy, which is ancient
<halfie> ah okay. I need to find a mirror which has latest packages.
<cjwatson> Either use a mirroring tool to get raring, or parse raring's Packages files
<cjwatson> Don't poke about in the pool directly unless you know exactly what you're doing
<cjwatson> dists/raring/*/binary-*/Packages.gz are the indices
<cjwatson> archive.ubuntu.com has all versions; it is not plausible that it doesn't have the latest ones
<halfie> cjwatson, debmirror seems the way to go. does "python-debian" support parsing of those indices?
<cjwatson> But it also has versions from every still-supported release
<cjwatson> Yes
<halfie> I see. Then I screwed up navigation of the archive.ubuntu.com tree :)
<cjwatson> debian.deb822 specifically
<cjwatson> Or just grep for the Filename fields
<halfie> can I ask debmirror just to get latest "sudo" package? (I don't think so but is there an utility which can do this?). Maybe python-debian can help (parse indices and wget)
<halfie> ahh okay, got it
<cjwatson> That's not a sensible use of debmirror
<halfie> true
<cjwatson> Doesn't Fedora have an apt port?  You could set apt up with a local configuration file and use the apt-get download subcommand
<cjwatson> Or as you say debian.deb822 + urllib or whatever can do it
<cjwatson> Or you could set up an Ubuntu raring chroot with debootstrap and work in that
<cjwatson> Several options :)
<halfie> cjohnston, the first option is quite interesting, giving it a try :)
<cjwatson> (Could you please remember to type more characters before hitting tab to avoid bugging poor cj ohnston all the time?)
<halfie> ohh sorry, sure :)
<halfie> I have gotten used to tabbing so much everywhere
<cjohnston> halfie: 1 + 2 + 3 + tab
<cjohnston> :-)
<halfie> :D
<mdeslaur> hrm, http://utcc.utoronto.ca/~cks/space/blog/linux/UbuntuAccountsServiceProblems
#ubuntu-devel 2013-04-07
<kees> halfie: right, PIE and BIND_NOW aren't default. (relro and all the rest are)
<kees> however, the push in Debian has been to make PIE the default on amd64.
<kees> so packages that have converted to dh(1) in debian are getting PIE on amd64.
<kees> iirc
<kees> I need to check :)
<kees> halfie: ah, no, I lied. that's the plan, but not how it's implemented yet.
<halfie> kees, thanks for the info!
<halfie> selling PIE and BIND_NOW is hard
<kees> see http://outflux.net/debian/hardening/
<kees> and http://outflux.net/ubuntu/hardening/ (though I need to fix the release -- that's showing quantal)
<kees> and note that're using different max values -- ubuntu has more packages, so the graph auto-scaled the y axis
<kees> IMO, selling PIE is easy on amd64 :)
<kees> and selling bind_now is easy too -- there's no measureable perf hit any more since the hashed symbol tables
<ogra_> doko_, gcc did buiold fine for me over nicght, no issues
<ogra_> (oh my ... /me needs coffee and type training)
<infinity> ogra_: Yeah, it eventually completed on sigbin too.
<ogra_> yeah, i noticed he had restartred a build in parallel to calling me
<doko> ogra_, \o/
<ogra_> :)
<doko> infinity, the armel and armhf gcc-4.8 builds on precise did fail, will retry these too
<doko> meh, the gcc-4.8 builds on precise did fail in dh_shlibdeps for the non-default multilib. will just ignore the return code then for precise
<jtaylor> doko: the python configure failures is not fixed without predepends :(
<doko> jtaylor, ok, thanks. good to know
<IDWMaster> I'm not sure if this is the appropriate place for this discussion, but I was wondering if there are plans to implement multitouch support for Unity, and if so, how could I contribute?
<penguin42> IDWMaster: I'm not sure; but there is a https://blueprints.launchpad.net/canonical-multitouch  section in lp, and there are a series of blueprints hung off that, including one or two unity ones
<penguin42> IDWMaster: You might also try #ubntu-unity
<penguin42>  add the missing u ^
<IDWMaster> OK. Thanks
<infinity> apw / BenC: Want to rebase lowlatency and ppc against the shiniest raring upload?
#ubuntu-devel 2014-03-31
<hyperair> does anyone here frequently hotplug monitors into an ivb laptop?
<pitti> slangasek: thanks for the PAM bug analysis!
<pitti> infinity: ah, good to know; I'll fix that
<infinity> pitti: Thanks.
<pitti> infinity: filed bug 1300031 as a reminder
<ubottu> bug 1300031 in autopkgtest (Ubuntu) "ignores build depends after comments" [High,New] https://launchpad.net/bugs/1300031
<pitti> Noskcaj: if there isn't too much difference to g-i-t 3.10, sure
<infinity> pitti: I imagine the easiest way is just to grep -v '^#' before parsing debian/control.
<infinity> pitti: Unless it also has issues with comments at the end of lines (didn't check).
<infinity> pitti: In which case, maybe the equivalent of sed 's/#.*$//'
<pitti> infinity: not sure whether you got my psql comment from Friday; but I guess today we can release the lot?
<pitti> infinity: yep, should be simple
<infinity> pitti: Yeah, we'll release it all today.  Your comment came a bit too late for me to be comfy releasing pre-weekend.
<infinity> I guess we can just let it fly now, there will be enough people (including you) around to deal with something if it explodes.
<infinity> pitti: Do these go to both updates and security, or is the psql-8.4 publishing history special?
<pitti> infinity: no -security this time, just -updates
<infinity> Kay.  For all of them?
<pitti> infinity: yes
<pitti> infinity: back in 30 mins
<RAOF> pitti: Any chance of a umockdev release with the âdon't wait for 48 days when given an evemu trace from a device that doesn't report events in chronological orderâ bug? :)
<dholbach> good morning
<zyga> good morning
<pitti> RAOF: yes, I was going to do that
<pitti> RAOF: sorry, forgot about it on Friday
<pitti> RAOF: dinstall runs in 43 mins, I should catch that; so I can sync around noon
<pitti> RAOF: umockdev 0.8.1 released and uploaded to sid
<doko> tvoss, I think you / the phone team is the biggest user of valgrind (as a build dependency). I want to propose a new valgrind for trusty (having support for AArch64), maybe as a sru after the release. but it would be nice to check the valgrind package in the ubuntu-toolchain-r/test PPA.
<tvoss> doko, cool, thanks for the heads up. I think the Mir team is using it in quite sophisticated ways, also the unity scopes team. I will dispatch your rfc for testing to them
<doko> tvoss, let me file the bug, then the replies can be tested there
<doko> posted ...
<tvoss> doko, got a link for me?
<doko> tvoss, https://bugs.launchpad.net/ubuntu/+source/valgrind/+bug/1300070
<ubottu> Launchpad bug 1300070 in valgrind (Ubuntu Trusty) "valgrind 3.10/trunk update to support AArch64" [Undecided,New]
<doko> so maybe subscribe to the issue
<tvoss> doko, ack
<tvoss> doko, will ask the Mir and unity-scopes-api team for feedback specifically and extend the heads up to ubuntu-phone upstreams
<seb128> shrug
<seb128> update-manager stopped to debconf prompt me about openssh-server configuration
<seb128> it displays a checkbox "disable ssh password authentification for root?"
<darkxst> yeh I saw that too, imported from debian ?
<seb128> cjwatson_, hey, is that ^ known/wanteD?
<darkxst> seems rather odd when we don't have root accounts by default!
<infinity> s/accounts/passwords/
<infinity> cjwatson_: Maybe you could skip the debconf question and JFDI if '$(getent shadow root | cut -d: -f2) = "!"'
<infinity> cjwatson_: That is, if root doesn't currently have a password, you won't be locking me out of my machine by surprise by not allowing password logins.  If I set one later, I can debug why it no workie myself.
<infinity> seb128: ^ That seem like an acceptable compromise between no default prompting and not locking people out on upgrade?
<seb128> infinity, seems fine to me, I'm unsure what changed though/how we were handling things before
<seb128> (e.g why is that prompt showing up today)
<seb128> k, the changelog answers that question :p
<infinity> seb128: Our default config has/had PermitRootLogin yes.  The new default is without-password, which is saner, but automatically upgrading would lock out people who rely on the password auth.
<seb128> right
<infinity> (At least, I assume it used to be yes... Maybe it used to be no, and all of us hitting the prompt manually changed it at some point and forgot...)
<infinity> No, it was definitely yes, I have a fresh precise VM with that setup.
<seb128> I'm sure I didn't change that config
<pitti> smoser, infinity: wolfe-05 and -06 are offline; do you know what happened to them?
<infinity> pitti: I have no idea.  Lemme see if I remember how Scott's setup works.
<infinity> ... and which IP wolfe is.
<infinity> pitti: 06 looks alive to me.  05 is in an rcu_sched hang.
<infinity> Oh, wait.  06 is spewing on the console too.  Whee.
<infinity> pitti: Bouncing both.
<infinity> pitti: Should be back.  I don't have accounts on either, so you'll have to confirm.
<jibel> infinity, thanks, they are both back
<jibel> pitti, I'll bring 3 down, because dpkg segfaults and it cannot provision a new container
<jibel> s/down/offline/
<infinity> jibel: A reboot should fix that.
<infinity> jibel: I've never been able to reproduce that bug to try to figure out WTF is happening. :/
<infinity> jibel: You're seeing that on one of wolfe's VMs?
<jibel> infinity, yes on wolfe-03 but I just rebooted it
<pitti> infinity: thanks for bouncing
<infinity> jibel: Yeah, that's fine, I don't think I can get anything useful out of the VM anyway.  Just odd that you've seen it on another host.  I've only ever seen it on postal, and was close to blaming the machine.
<infinity> (I've seen it on all of postal's VMs, but never on denneed or fisher, which is confusing as heck)
<seb128> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Trusty Final Beta released! | Archive: Gated Review | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> saucy | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: seb128
<jibel> infinity, indeed it's dpkg'ing happily after a reboot.
<infinity> jibel: It might act up again at some point.  It seemed to happen to postal's VMs every few hundred builds or so (couldn't ever identify any specific thing as the trigger, though), which is why those buildds are on manual right now. :/
<infinity> As bugs go, it's pretty much my least favourite kind.  Not enough useful info to report to kernel (or qemu?) people, and no sane way to make it happen to try to get useful info.
<infinity> And it may well just be a bug in the qemu endian-flip madness, which would make it something that really doesn't matter once we get off POWER7 hardware.
<infinity> At least the symptom is so catastrophic that it doesn't cause any subtle bugs elsewhere. :P
<jibel> infinity, yes hard to say, first failure of this type started 2 days ago but without any specific thing done to the VM
 * hyperair wonders if he's the only one experiencing black-screen-on-monitor-plugged-in syndrome.
<GunnarHj> cjwatson_: ping?
<seb128> GunnarHj, you might want to let some context with pings ;-)
<GunnarHj> seb128: Makes sense...
<GunnarHj> cjwatson_: Time to talk about bug 1294858?
<ubottu> bug 1294858 in ubiquity (Ubuntu) "Installer does not install all language support packages" [Undecided,New] https://launchpad.net/bugs/1294858
<GunnarHj> seb128: Do you have time for a package question?
<seb128> GunnarHj, sure
<GunnarHj> seb128: What's the best way to distinguish Ubuntu from Debian in debian/rules?
<GunnarHj> dpkg-vendor --is ubuntu
<GunnarHj> ?
 * apw feels this new ssh message is confusing, and the name of the option it tells you about just fuels that, and i don't feel advised as to the right option; i felt compelled to read the manual for it to decide
<seb128> GunnarHj, yes
<infinity> apw: See backscroll.
<infinity> apw: About an hour ago.
<GunnarHj> seb128: So the builders will always understand?
<apw> infinity, ahh thanks
<infinity> GunnarHj: The buildds have the same dpkg installed that you do.
<seb128> GunnarHj, why wouldn't they? that's what e.g udisks is using
<seb128> (just giving an example of package where we are using that if you want to check it out)
<infinity> GunnarHj: You might want --derives-from though, if you want Ubuntu and all derivatives to get the setup.
<pitti> didrocks: apport with that crash fix uploaded, now waiting in unapproved
<infinity> GunnarHj: (Depends on if it's legitimately Ubuntu-specific, or rather just "not the Debian way")
<didrocks> pitti: ok, I'll keep an eye to kick an image once available
<GunnarHj> infinity, seb128: It's basically 'not the Debian way' in this case. Most important is that it works for Ubuntu Kylin.
<infinity> GunnarHj: Well, kylin is "just Ubuntu", from the POV of them using the same dpkg from the same archive.
<infinity> GunnarHj: But if Ubuntu derivatives should also default to the same setup (eg: because our packaging is forked in other fun ways, and derivatives should inherit that default), then you want --derives-from.
<infinity> Thing, eg: Mint.
<infinity> s/Thing/Think/
<infinity> Not sure if Mint actually bothers to fork dpkg origin, but they should if they don't. :P
<GunnarHj> infinity: Does --derives-from include all the 'normal' *ubuntu flavours?
<infinity> GunnarHj: Flavours are all Ubuntu.
<infinity> GunnarHj: They all use the same dpkg, cause they build from the same archive.
<GunnarHj> infinity, seb128: Ok, think I've got it. Thanks!
<infinity> GunnarHj: It's only derivatives (ie: people with their own archives) who can be different in this case.
<infinity> GunnarHj: So, basically, antyhign built from ftp.debian.org both --is and --derives-from debian.  Anything built from archive.ubuntu.com --is ubuntu and --derives-from both debian and ubuntu.  Other out-of-archive derviatives might derive from debian or both (or, if they're weird, neither).
<cjwatson> seb128: It's wanted in general, but infinity's suggestion seems like a nice option.
<GunnarHj> infinity: Then it's indeed --is in this case (i.e. not Debian). Thanks for the lesson. :)
<cjwatson> GunnarHj: I only work on ubiquity at the moment when it's an emergency and nobody else is available.
<cjwatson> GunnarHj: Too many other plates to juggle.
<GunnarHj> cjwatson: Anybody else I could talk to? (It's not exactly an emergency, but would be nice to have it fixed in 14.04.)
<cjwatson> GunnarHj: Slightly reluctant to unconditionally volunteer him, but maybe xnox has time?
<infinity> GunnarHj: I think I was trying to point out that you want "--derives-from ubuntu" so that both ubuntu and downstreams who use our packages mostly unmodified would get the same thing, but if it's really Ubuntu-specific, you want --is (like, say, Apache server tokens).
<GunnarHj> cjwatson: Can't hurt to ask. :) Thanks!
<GunnarHj> infinity: It's code intended to be added in debian/rules upstream (Debian) but only take effect when built for Ubuntu.
<infinity> GunnarHj: Right, I get that.  But if someone were to build the package on an Ubuntu derivative that is mostly Ubuntu, but with a few tweaks, would they want the Ubuntu rules behaviour, or the Debian?
<infinity> GunnarHj: If you use --is, they'll get the Debian behaviour.  Would that be wrong in the context of all their other packages being Ubuntuish?
<GunnarHj> infinity: Maybe, maybe not. It's not a very Ubuntuish think. It's just that we (unlike Debian) want fcitx to be the default before ibus if fcitix is installed. :)
<caribou_> cjwatson: I saw that you fixed the btmp bug in Debian (Debian bug #341883), thanks
<ubottu> Debian bug 341883 in openssh-server "openssh-server: doesn't log bad login attempts to /var/log/btmp" [Normal,Fixed] http://bugs.debian.org/341883
<GunnarHj> infinity: Still appreciate your clarifications.
<cjwatson> caribou_: you're welcome
<caribou_> cjwatson: now how should I proceed for Ubuntu ? This will not be automatically synced in Trusty
<cjwatson> caribou_: I already synced it.
<caribou> cjwatson: thanks!
<infinity> cjwatson: Hrm.  That btmp thing didn't really address the "might use password as username" issue, though.  I'm still not super keen on root having a log of unhashed passwords in the clear.
<caribou> cjwatson: then looks like I should get going with the SRU work
<infinity> cjwatson: I liked login's solution of logging UNKNOWN for accounts that don't exist.
<cjwatson> infinity: Yeah, that's cute, though really ought to be done upstream
<cjwatson> caribou: Be my guest
<infinity> Though, login fails in other ways, it would seem...
<infinity> UNKNOWN  tty1                          Mon Mar 31 04:14   still logged in
<infinity> test123  ssh:notty    localhost        Mon Mar 31 04:12    gone - no logout
<infinity> Still logged in, my ass. :P
<pitti> Laney: does bug 1278284 sound ok to you? Otherwise I'll need to fork off Ubuntu and upload the other fixes without that new debugging option
<ubottu> bug 1278284 in sessioninstaller (Ubuntu Trusty) "Doesn't find gstreamer1.0 codecs" [High,Fix released] https://launchpad.net/bugs/1278284
<pitti> Laney: (I suppose it's ok, but asking early before I sync it)
<pitti> Laney: sorry, bug 1300092
<ubottu> bug 1300092 in autopkgtest (Ubuntu) "FFE: Add option for running shell in testbed" [Undecided,New] https://launchpad.net/bugs/1300092
<infinity> Oh, fun, it continues to say that until the getty dies (ie: due to a successfuly login)
<infinity> s/successfuly/successful/
<Laney> pitti: Yeah, new feature you have to opt in to use in a QA-ish package sounds fine
<Laney> go wild
<pitti> Laney: thanks
<Laney> thanks for committing that sessioninstaller fix too ;-)
<seb128> dholbach, hey, is https://bugs.launchpad.net/ubuntu/+bug/1294891 ready for upload? ;-)
<ubottu> Launchpad bug 1294891 in Ubuntu "Ubuntu GNOME community wallpapers" [High,Triaged]
<highvoltage> froztbyte/win 13
<highvoltage> (oops)
<Laney> nice password :P
<zyga> heh :)
<tkamppeter> xnox, hi
<xnox> tkamppeter: hello!
<Sweetshark> doko: libreoffice update is in main, -voikko build against it here ...
<Sweetshark> s/build/builds/
<Sweetshark> pls ping me if there are issues remaining.
<dholbach> seb128, I didn't look at it after my pilot shift again
<seb128> dholbach, can you upload it? if I do it I need to find another archive admin to do the NEWing...
<dholbach> seb128, ok, I'll review it again
<seb128> dholbach, danke!
<dholbach> seb128, followed up: https://bugs.launchpad.net/ubuntu/+bug/1294891/comments/8
<ubottu> Launchpad bug 1294891 in Ubuntu "Ubuntu GNOME community wallpapers" [High,Triaged]
<seb128> dholbach, thanks
<tkamppeter> xnox, can you have a look at bug 1276713 and also at https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=742666. It is abot getting equal Upstart support with socket activation in both Debian and Ubuntu.
<ubottu> Debian bug 742666 in cups-daemon "No Upstart support" [Normal,Open]
<ubottu> bug 1276713 in cups (Ubuntu) "upstart socket activation for cups" [Undecided,Fix released] https://launchpad.net/bugs/1276713
<tkamppeter> xnox, can you especially answer Cameron's questions in the Launchpad bug.
<xnox> tkamppeter: ack.
<xnox> tkamppeter: responded
<tkamppeter> xnox, thanks.
<seb128> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Trusty Final Beta released! | Archive: Gated Review | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> saucy | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<seb128> doko, hey, do you have any openjdk upload coming? there is a patch in the sponsoring queue that would be nice to get in trusty, but since openjdk takes ages to build better to batch that with other changes if you have some ;-)
<doko> if this is 937200, then yes
<seb128> oh, seems like pitti is attacking the sponsoring queue from the other side ;-)
<pitti> seb128: sorry, I saw your @pilot out and thought to run through some items
<pitti> seb128: i. e. sorry if I stepped on your toes
<seb128> pitti, no worry, help is welcome ;-)
<mardy> Mirv: hi! Do you think you can add the fix to bug 1299712 as a patch against qt 5.2?
<ubottu> bug 1299712 in qtbase-opensource-src (Ubuntu) "Online accounts for facebook (and google) are missing cursor for sign-in" [Undecided,Confirmed] https://launchpad.net/bugs/1299712
<seb128> pitti, no, I'm glad you got some, I stopped for lunch and I was planning to get a few extras, but I would probably not have reached the most recent ones
<pitti> seb128: grabbing light-locker* and gnome-documents MP, ok?
<pitti> seb128: I try to do the easy syncs and some "5-a-day"ish these days
<seb128> pitti, yes please, I just synced the audiocity ones and tali, sponsored gnome-online-account and I'm doing easytag
<psusi> the ddebs for libparted0debian1 are empty in the last 3 revisions.  anyone have any idea what went wrong? or how to figure it out?
<seb128> pitti, just stating the ones I'm touching so we don't duplicate
<seb128> pitti, 5 a day ftw ;-)
<psusi> cjwatson: re: the loop regression: I think you had some magic in partman to deal with lvm volumes, which parted used to report as having a single partition on them named /dev/mapper/xxxp1.  The patch dropped the incorrect p1 suffix.  Could that have broken partman?
<xnox> psusi: partman used to report /dev/mapper/volume-group-name with volumes under that device name (as if they are partitions)
<pitti> seb128: grabbing https://code.launchpad.net/~noskcaj/ubuntu/trusty/gnome-video-effects/0.4.1/+merge/212248, then finishing
<pitti> RAOF: umockdev 0.8.1 is now in trusty, with the timestamp going backwards fix
<seb128> pitti, danke
<psusi> xnox: not how I remember it... it reported each /dev/mapper/vg-lv as a disk, with a single partition on it named /dev/mapper/vg-lv1
<psusi> partman apparently knew it had to strip off the bogus 1 to refer to the actual device name... I fixed libparted to not add the bogus 1 in the first place
<cjwatson> psusi: None of that rings a bell
<psusi> cjwatson: darn.. was hoping it would.  Guess I'll just have to play around with it tonight.
<pitti> didrocks: the apport cgroup crash fix landed in trusty now, FTR
<cjwatson> psusi: thanks
<seb128> doko, thanks ;-)
 * davmor2 rings his bell to see if helps cjwatson remember
<pitti> stgraber, kirkland: byobu's keys (F2 etc.) don't work in a container, i. e. with "lxc-start"; is there a trick how to get this functionality?
<kirkland> pitti: hmm, interesting, is this screen or tmux backend?
<pitti> kirkland: hm, both screen and tmux are installed (I think I just did "apt-get install byobu"), how do I tell?
<pitti> tmux -f /usr/share/byobu/profiles/tmuxrc new-session -n - /usr/bin/byobu-shell
<pitti> kirkland: ah, tmux
<kirkland> pitti: tmux
<kirkland> pitti: yeah, the easy visual queue is "1 line, or 2 of status at the bottom"
<pitti> kirkland: ah, heh; yes, one line
<kirkland> pitti: otherwise, its ps -ef | grep byobu
<pitti> kirkland: I'm fairly sure it's nothign with gnome-terminal or my unity config etc, I use F2/F3 etc. on ssh sessions all the time
<pitti> kirkland: curiously, F9 works
<kirkland> pitti: right;  oh, now that is weird
<kirkland> pitti: I was thinking something might be wrong with how lxc handles the tty...but if F9 works...
<pitti> kirkland: shift-f2/f3 etc. seem to work, too
<kirkland> pitti: this is latest/greatest trusted?
<pitti> kirkland: yes, trusty du jour on both host and container
<stgraber> pitti: what's F2 supposed to do?
<kirkland> pitti: is this a recent regression in lxc?
<kirkland> stgraber: create a new window in byobu
<stgraber> ok, then it works fine here
<pitti> kirkland: I'm not sure, but it's at least like that for two weeks or longer
<pitti> stgraber: interesting
<stgraber> I'm sshed into a trusty container on a trusty host running byobu and F2 gets me a new window
<stgraber> using terminator as my terminal emulator here
<pitti> stgraber: so maybe ssh sets up the terminal differently in some way than a direct "lxc-start" in gnome-terminal?
<stgraber> pitti: that's entirely possible, yes
<pitti> anyway, it seems this isn't already known
<pitti> I can do lxc-attach to get a second shell in it, it's just way more cumbersome
<stgraber> though both should be pts devices in the end, maybe tmux special-cases devices called /dev/ttyX somehow?
<ochosi> pitti: thanks for sponsoring light-locker* !
<pitti> kirkland: FTR, broken in byobu-screen as well
<pitti> ochosi: yw!
<kirkland> pitti: okay, I'm trying to reproduce this now
<kirkland> pitti: what's your escape key?  the default ctrl-a?
<kirkland> pitti: can you try this... ctrl-a then ":" then type "new-window" and hit enter
<kirkland> pitti: does that create a new window?
<pitti> kirkland: hm, I think I set it to emacs mode, so that ctrl+a = go to beginning of line
<kirkland> pitti: okay, so ctrl-b then
<pitti> kirkland: argh, that's taken by my window manager; can I reset ctrl+a somehow?
<pitti> ah, byobu-ctrl-a :)
<pitti> F12 doesn't work, FTR
<pitti> kirkland: :new-window works fine; F3 doesn't switch
<kirkland> pitti: okay, now, ctrl-b then ":" then "bind-key -n F2 new-window"
<kirkland> pitti: then try pressing F2
<pitti> kirkland: no change
<kirkland> pitti: okay, and you're in a shell on your container using lxc-attach?
<pitti> kirkland: not lxc-attach, lxc-start (not sure if that's any different)
<pitti> sudo lxc-start -n debci
<pitti> and then log into that through the usual getty
<pitti> kirkland: a local byobu on my VT1 works fine, btw
<didrocks> pitti: yeah, we kicked an image as soon as it was promoted (building), thanks for the head's up
<seb128> xnox, hey, could you review https://bugs.launchpad.net/ubuntu/+source/bash-completion/+bug/1298220 ?
<ubottu> Launchpad bug 1298220 in bash-completion (Ubuntu) "Sync bash-completion 1:2.1-4 (main) from Debian unstable (main)" [Wishlist,New]
<seb128> xnox, I'm asking you because I know you had a look at some of the issues with the new bash
<seb128> doko, ^ or maybe that's something you are interested in as well
<xnox> seb128: damn, did I forget to revert bash ?! *sigh*
<seb128> xnox, now I'm unsure if you are trolling me :p
<seb128> xnox, well, doko is back at least, so you can talk to him about fixing it
<xnox> seb128: i think we can sync bash-completion, but it will not solve all the bash problems.
<seb128> :-(
<pitti> xnox: FTR, there's a sync request in the sponsoring queue; but I checked the diff between D and U and it's horribly long, so that would need to be done with some care
<pitti> I found a few fixes/changes which aren't in Debian yet
<pitti> (i. e. maybe better merge/sync that next cycle?)
 * dholbach hugs seb128 and pitti
<xnox> pitti: yeah, i also see that some things need to be merged.
 * seb128 hugs dholbach and pitti
<xnox> pitti: agree, that it's better to post-pone this.
<cjwatson> slangasek: Can you advise on where bug 1298653 should be reassigned?
<ubottu> bug 1298653 in grub2 (Ubuntu) "mokmanager typo "Start MOK utility utility at EFI\ubuntu\MokManager.efi on EFI"" [Undecided,Confirmed] https://launchpad.net/bugs/1298653
<xnox> seb128: hm, although doko did upload two bugfixes.
<seb128> xnox, right
<bdmurray> pitti: did you see I updated my apport-retrace package versions merge proposal?
<xnox> seb128: i think we are all good. major bugs in bash-completion and bash are fixed.
<pitti> bdmurray: ah no, I didn't; thanks! (LP doesn't send out notifications for new commits)
<seb128> xnox, if you say so
<pitti> at least ~/... completion shows files again
<kirkland> pitti: okay, I've reproduced your issue
<kirkland> pitti: I'm checking saucy now
<pitti> kirkland: I can't say whether this is a regression at all; I never used byobu with lxc before
<kirkland> pitti: k
<kirkland> pitti: I do see this error, "<4>init: setvtrgb main process (409) terminated with status 1"
<kirkland> pitti: just before the login prompt
<pitti> kirkland: yes, me too
<kirkland> pitti: confirmed on saucy too
<bdmurray> infinity: could you have a look at bug 1298393?
<ubottu> bug 1298393 in debian-installer (Ubuntu) "please provide boot files for x-gene platforms" [Undecided,New] https://launchpad.net/bugs/1298393
<ogra_> cjwatson, hmm, i just noticed that i can start sshd even if there are no existing host keys, is that wanted (i remember the old sysv init script had a check and created keys on demand)
<cjwatson> ogra_: I'm afraid your memory is faulty.
<ogra_> was that always a postinst thing ?
<cjwatson> We've never created host keys in the init script, and if it ever checked it would only have been by way of sshd -t.
<cjwatson> Yes.
<ogra_> hmm, kay
<cjwatson> I would expect sshd to exit early if it has no host keys.
<bdmurray> barry: were you looking at gdebi recently?
<barry> bdmurray: yes, i have a branch wip for switching it to py3
<bdmurray> barry: might that fix bug 1295872?
<ubottu> bug 1295872 in gdebi (Ubuntu) "gdebi-gtk crashed with UnicodeDecodeError in decode(): 'utf8' codec can't decode byte 0xc3 in position 0: unexpected end of data" [High,Triaged] https://launchpad.net/bugs/1295872
<barry> bdmurray: not directly
<bdmurray> barry: okay, looking at the errors bucket it seems to occur pretty frequently
<barry> bdmurray: i'll try to take a look when i'm working on the new branch
<bdmurray> barry: thanks
<hallyn> holy cow.  unity is just losing windows left and right...  they're still running, but they don't show up in the switcher
<rbasak> cjwatson: triaging bug 1300133: Won't Fix?
<ubottu> bug 1300133 in openssh (Ubuntu) "Generate ED25519 host keys on upgrade" [Undecided,New] https://launchpad.net/bugs/1300133
<cjwatson> rbasak: I've left it in the state I intend
<cjwatson> rbasak: (i.e. it's OK for there to be discussion)
<cjwatson> rbasak: (I don't understand this thing where the server team feels obliged to triage openssh bugs but doesn't contribute to maintenance, TBH)
<cjwatson> seems weird :)
<balloons> ping xnox
<rbasak> cjwatson: to try and keep a handle on bugs, I end up triaging far more bugs than I do deep dives into.
<xnox> balloons: hey
<rbasak> cjwatson: for some reason our triage process involves handling New/Undecided bugs, but IMHO that's never really been right. It's just on the queue, and I thought we could do something about it.
<rbasak> I suppose set the Importance at least, since then it doesn't appear on the first triage report we have.
<balloons> xnox, hey. So a couple things to discuss with you.
<xnox> balloons: shoot! =)
<balloons> xnox, first, can you push stuff to the store now? Can you build clicks on s-jenkins? did that get sorted out?
<cjwatson> rbasak: importance something less than high would be fine, yeah
<rbasak> thanks
<xnox> balloons: i have access to upload clicks into the store, i can download them from s-jenkins. I don't have any special privilidges on s-jenkins (e.g. triggering/controlling jobs etc)
<xnox> balloons: e.g. i was the one who uploaded gallery app click fetched from s-jenkins for the last upload.
<balloons> xnox, good enough. Ok, would you be willing to work with fginther this week on having those builds be autotested after building?
<balloons> xnox, I'll be out and he wants to get it in ;-)
<xnox> balloons: sure. All I do locally is: $ click-run-checks on the generated .click.
<balloons> xnox, secondly, I'd think your opinion on this issue popey is seeing. https://bugs.launchpad.net/music-app/+bug/1300230
<ubottu> Launchpad bug 1300230 in Ubuntu Music App "UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position 33484: ordinal not in range(128)" [Undecided,Confirmed]
<xnox> fginther: can we integrate "click-run-checks" on the generated .click? it's about equivalent to running "lintian" against a deb.
<xnox> balloons: right, let me look into that music-app error.
<balloons> xnox, I'm wondering if the new phablet-tools release might have impacted the bug I linked from popey. The tldr is, there are now unicode errors running tests that used to work
<xnox> balloons: if a click declares autopilot directory in the manifest, it must be python3 compliant tests.
<xnox> balloons: one way to solve this is to remove that stanza from the manifest, and then the tests will revert to using python2.
<balloons> did we miss music in the conversion?
<xnox> balloons: or I'll look into fixing this.
<balloons> xnox, ahh.. kk..
<xnox> balloons: to make it python3 compatible again.
<balloons> xnox, I'd prefer the latter if you are willing
<xnox> balloons: it did pass under python3 a week ago =)
<balloons> xnox, wild.. I haven't checked the revision history to see what all got changed
<balloons> let's look
<fginther> xnox, adding click-run-checks is do-able
<xnox> fginther: having that output as artifact should be sufficient. Possibly bail/fail the job if that has errors. Warnings are harder, as some of them are expected.
<balloons> fginther, xnox please just keep me in the loop on what's implemented. I'll be back at the end of next week
<fginther> xnox, I'll let you know once I have something started so you can have a peek at the results
<xnox> fginther: thanks!
<Laney> bah
<Laney> keeping build-deps cross-installable is a right pain, isn't it?
<tarpman> doko, seb128: thanks very much for uploading 937200 :) super pleased to have that in trusty.
<seb128> tarpman, yw!
<xnox> balloons: commented on the bug report about music-app. It works and passes correctly on the current trusty-proposed channel, with current 389 music-app, latest phablet-tools, under python3.
<xnox> balloons: how is popey running that music-app tests that shows errors?
<popey> xnox: phablet-test-run -v  music_app
<balloons> xnox, I'll leave you to popey as it works for me too :-)
<popey> thanks â»
<balloons> popey, well, which version are we running
<balloons> xnox answered that v369 or earlier don't work
<popey> 369 of what?
<balloons> I see 389 right?
 * balloons opens myapps
<popey> i have tried 389 and 403
<balloons> popey, ahh right then. indeed
<popey> xnox: feel free to ping if you need me to test anything, or need more detail.
<balloons> biab
<psusi> cjwatson: so do you have any idea why the ddebs for the last 2-3 releases of parted are broken?
<xnox> popey: 389 works fine.
<xnox> popey: how do you build, install and test 403?
<slangasek> cjwatson: bug #1298653> err, I honestly have no idea, it's not supposed to be a boot menu option
<ubottu> bug 1298653 in grub2 (Ubuntu) "mokmanager typo "Start MOK utility utility at EFI\ubuntu\MokManager.efi on EFI"" [Undecided,Confirmed] https://launchpad.net/bugs/1298653
<popey> xnox: i got 403 from the store,  uploaded by balloons, installed using "pkcon install-local foo.click"
<popey> xnox: I test using 4 lines... phablet-config autopilot --dbus-probe enable, phablet-click-test-setup --click  com.ubuntu.music, adb reboot, then phablet-test-run -v music_app
<popey> xnox: which is what I've been doing for all apps. I ran the tests on gallery earlier on the same device and it was fine.
<cjwatson> psusi: hm, broken how?
<xnox> popey: right, let me wipe my device clean, to make sure i'm clean.
<psusi> cjwatson: it's empty
<cjwatson> psusi: there are -dbg packages
<psusi> for libparted that is...
<cjwatson> psusi: IIRC pkg-create-dbgsym doesn't bother to create contentful -dbgsym packages if -dbg is meaningful
<psusi> ohh... didn't realize -dbg got added... and that makes the ddebs still there, just empty?
<cjwatson> think so, they should have a dependency?
<Laney> dbgsym should have a dependency
<psusi> I would have thought it wouldn't create them at all... weird
<xnox> popey: can you get me output of $ click list --manifest ?
<popey> xnox: http://paste.ubuntu.com/7185790/
<xnox> popey: and when running as a user phablet I guess as well, so $ sudo -u phablet -i click list --manifest ?
<popey> that was as phablet
<xnox> popey: cool, thanks.
<xnox> popey: so autopilot/python blows up on one of those =)
<popey> oh nice
<xnox> popey: in particular with the fact that it's not running in UTF-8 locale, I think.
<xnox> popey: (same as all other locale based problems recently reported)
<popey> makes sense â»
<ogra_> hmm, is the randomization of PIDs a kernel feature ? and if so, is there wa way to switch it off ?
<ogra_> it just struck me how helpful it would be to have the processes visually ordered in a bootchart
<ogra_> (which proper ordering of the PIDs would achieve)
<sarnold> ogra_: yes, it would be a kernel feature if it exists; are you confident you're seeing that behaviour? to my knowledge, linux has never had it..
<sarnold> (and my week-old-ish uuntu touch image doesn't show that behaviour..)
<ogra_> well, looking at bootcharts i see things started with a lower PID than the process starting it ... it seems to start randomizing at some point
<sarnold> crazy thgh, running 'ps ; ps' in terminal shows 10151 and 10156. that's far more intervening processes than I would have expected
<Snow-Man> or it just wrapped?
<mdeslaur> sarnold: if I run it a couple of times, I get sequential pids once in a while
<sarnold> iirc cking mentioned some new tool recently, a fork-tracker... it'd be worth tracking that down
<sarnold> mdeslaur: heh, I never got two consecutive pids
<mdeslaur> sarnold: you need to stop running the fork bomb in the other window :)
<sarnold> mdeslaur: oh is -that- why my battery life is not so good? :)
<mdeslaur> sarnold: hehe :)
 * sarnold mumbles "last time I trust an article that says you can speed up your phone with this one simple trick..."
<balloons> xnox, popey so what's the synopsis?
<popey> balloons: xnox was reflashing his device, but seems maybe one of the apps I have installed on my phone was triggering the issue. But we don't know which one (yet)?
<zyga> ogra_: IIRC kernel has PID reuse but the way it reclaims dead pids is unclear to me
<ogra_> it seems slightly random ...
<ogra_> but not completely
<zyga> ogra_: probably next free from a rotating counter *but* given that this is the kernel I woudn't be surprised if there are some multi-core features to avoid any locking on next
<ogra_> yeah
<xnox> popey: i think i do know what's triggering this.
<xnox> popey: working on a fix.
<xnox> popey: please don't change your phone =)
<popey> ok
<xnox> popey: make your phone RW (if not already) then do:
<xnox> adb shell "echo exec su - -c adbd > /etc/init/android-tools-adbd.override"
<xnox> adb reboot
<xnox> popey: then try running music-app tests again and it should work.
<xnox> popey: right, the UTF-8 app is tradera that you have installed, and i've now reproduced your bug and the fix for it.
<leftyfb> paul_1: can you hop onto the webex and login to the local 12.04 install for me?
<leftyfb> paul_1: in a meeting at the moment so can't talk on the webex call
<leftyfb> paul_1: thank you
<popey> xnox: sorry, was on a call..
<xnox> popey: no worries. Fix uploaded into unapproved queue. Hopefully would be reviewed and accepted soon.
<infinity> bdmurray: Yup.
 * popey hugs xnox 
<popey> xnox: so just removing Tradera will allow me to run the tests?
<xnox> popey: or doing: adb shell "echo exec su - -c adbd > /etc/init/android-tools-adbd.override"
<xnox> popey: and rebooting
<popey> xnox: i went for removing the app
<xnox> popey: you might have other apps installed which would also affect the results....
<xnox> popey: it's the first problematic one, not sure if there are others =)
<popey> is there an easy way to tell?
<popey> which was the problematic app?
<xnox> freeciv, airbnb, baboom, bytesjack, ....
<xnox> popey: is your phone not in RW mode?
<xnox> in that case wait for adbd fix to get accepted.
<popey> no, not rw, I dont really want to do that
<ogra_> xnox, did you run any AP tests for this ? would be good to know that still works with the multiple sudo hoops they jump through in adb
<xnox> popey: well, it got accepted now. So in one of the next images it should be available via channel updates ;-)
<xnox> ogra_: all works correctly, tested with click and non-click AP tests.
<ogra_> cool
 * ogra_ wishes we could drop that some day .... it is awful
<slangasek> drop which?
<ogra_> slangasek, the sudoing to become phablet
<slangasek> what's awful about it, and what are you wanting to drop it in favor of?
<ogra_> proper pam integration of adbd ... or running adbd as user by default
<slangasek> well, I don't think that's an "or"; running it as a user by default still doesn't give you a pam session unless you add the pam integration
<slangasek> I'm unconvinced that there's anything wrong with the current solution that's worth the effort of adding pam integration to adbd
<ogra_> adb shell "sudo -u phablet -i 'bash -i -c $command'" ...
<ogra_> i still find it awful and ugly :)
<ogra_> not to mention it gets you into quoting hell with a little complex commands
<slangasek> ogra_: well, there's certainly some redundancy there
<slangasek> but that should be fixed directly
<ogra_> well, we have plenty different vesions of that command in different plases and tools ...
<ogra_> phablet-test-run has: adb $ADBOPTS shell sudo -u $USER -i sh -lc \'"$@"\' ...
<ogra_> slightly less ugly
<slangasek> no, that's even more ugly
<ogra_> oh ?
<slangasek> '-i sh -lc'?
<slangasek> you want 'sudo -u $USER -i -c "$@"'
<ogra_> that somehow didnt work for the people writing the tests
<slangasek> then they should've asked for advice from someone who knows how sudo and the shell work
<hallyn> hm, maybe i'm having a pulseaudio bug.  mplayer keeps saying 'audio device got stuck.'  banshee last night seemed to keep completely hanging my laptop (to the point that sysrq didn't work)
<ogra_> i think that doesnt process profile.d
<ogra_> which we need to get the proper env
<hallyn> i'll test some more witih banshee tonight after a reboot ...
<slangasek> and actually, I'm wrong, what you actually want is 'sudo -u $USER -i "$@"'
<slangasek> ogra_: 'sudo -i' is all you need in order to get a login shell
<slangasek> all the other crufty arguments here are cruft, but that has nothing to do with adbd supporting pam, that just has to do with people piling on commandline arguments without understanding them
<ogra_> well, there was a reason for the bash call in there
<slangasek> not a good reason
 * ogra_ cant remember anymore, thats nearly a year old 
<ogra_> but i know that the SDK ads well as the automation uses it like that
<slangasek> it's possible that the phablet user had the wrong login shell.  That should have been fixed by fixing the phablet user's login shell.
<slangasek> (and if that was the problem, it has been fixed since)
<ogra_> i dont think it ever changed from /bin/bash
<ogra_> what i remember is that it had something to do with the environemnt not being proper
<slangasek> regardless, this is unnecessary complexity.  phablet-test-run should just be 'adb $ADBOPTS shell sudo -u $USER -i $@', and the other invocations likewise
<ogra_> right, i was promoting that back then ... but for some reason it didnt work
<slangasek> ogra_: ok, so the issue within phablet-test-run is that it's trying to run a sequence of commands under sudo, so yes, that requires sh -c.  It certainly doesn't require 'bash -ic', however... 'sh -c' is fine and it will inherit the environment from the login shell that's already been launched
<Justanick> Hello, is it useful, that an upgrade from the last LTS did not remove the packages
<Justanick> linux-image-generic-lts-quantal
<Justanick> linux-headers-generic-lts-quantal
<Justanick> Also the new gcc is not added to update-alternatives
<Justanick> Still showing the old gcc 4.6
<cjwatson> gcc is intentionally not managed in update-alternatives, to avoid determinism problems in builds
<leftyfb> paul_1: Would you mind joining us on that call? Having some issues.
<cjwatson> A normal upgrade should simply repoint the /usr/bin/gcc symlink directly at gcc-4.8, assuming that you upgraded gcc
<Justanick> cjwatson: The gcc 4.6 has been still installed after the update. I have just purge it with apt-get purge
<Justanick> This has also delete the gcc 4.6 entry on update-alternatives
<Justanick> The new entry for gcc 4.8 is still missing
<Justanick> The binaries are at /usr/bin/
<cjwatson> There has never been a gcc-4.6 entry in update-alternatives at all, as far as I'm aware
<cjwatson> I suggest "sudo apt-get install gcc"
<Justanick> cjwatson: The message is "newest version is installed". I will add the entry manually.
<infinity> Justanick: There should be no "entry", there should be a straight symlink, as provided by the "gcc" package.
<infinity> Justanick: If you had alternatives before, that was not from the Ubuntu packaging, but perhaps something you added yourself?  In which case, you should expect that to break.
<Justanick> infinity: I could be added by myself. I have used the older LTS a bunch of time with a bunch of compiler versions.
<cjwatson> Perhaps at some point you used dpkg-divert?
<cjwatson> dpkg-divert --list | grep gcc
<Justanick> I don't think so.
<Justanick> Does the return nothing
<Justanick> Does return nothing
<cjwatson> well, gcc 4:4.8.2-1ubuntu4 here ships the file /usr/bin/gcc, so I have no other ideas why it wouldn't be installed if that package is installed on your system.
<cjwatson> symlink, not file, that is.
<Justanick> I will simple add it to update-alternative
<cjwatson> Don't compound your mistake.
<cjwatson> It isn't supposed to be an alternative.  Installing it as an alternative locally is going to lead to trouble.
<cjwatson> Try 'dpkg -L gcc' and see whether it lists /usr/bin/gcc.
<cjwatson> And in future use CC=gcc-4.8 or whatever if you need to switch versions rather than mucking around with system-level alternatives.
<Justanick> cjwatson: Yes it is on the list.
<cjwatson> Then I might try "sudo apt-get --reinstall install gcc" to see if that resurrects /usr/bin/gcc.
<cjwatson> And make sure that you have no alternatives for gcc now.
<Justanick> gcc -v returns now the ubuntu build of 4.8.2
<cjwatson> I don't really want to think about what an alternative for a file name also shipped directly in a package would do to dpkg, but it wouldn't be good.
<cjwatson> It certainly isn't a valid configuration.
<cjwatson> There are alternatives for c89, c99, and cc, those are OK (they're for switching between gcc and clang)
<cjwatson> Though CC= is still usually preferable
<Justanick> Okay.
<cjwatson> I think it's probably more or less expected that linux-*-generic-lts-quantal aren't removed, not sure; might be nice to sort that out via an upgrade quirk in ubuntu-release-upgrader
<cjwatson> Clearing out old kernels requires care ...
<infinity> cjwatson: The release-upgrader already violently tears out old kernels, I thought.  Maybe it's being fooled by the lts backports.
<Justanick> cjwatson: Or a question to the customer, if the older kernel should be removed?
<doko> xnox, thanks for taking care about the python3.3 drops
<xnox> doko: no problem.
<xnox> doko: need to make up uploads since missing in action for a wekk =)
<Justanick> Should scons work on the daily?
<Justanick> g++ has not been valid
<jtaylor> xnox: whats different in the headless builders? or why is stuff suddenly failing to build after beta freeze?
<Justanick> At the boot grub2 shows me 3 times error:file not found. What the source of the problem could be?
<xnox> jtaylor: it has also been failing in all test rebuilds.
<jtaylor> it didn't fail in february
<xnox> jtaylor: the errors are comming from X server, on initial inspection, maybe the problem is somewhere else.
<xnox> jtaylor: it did fail in early march. http://people.ubuntuwire.org/~wgrant/rebuild-ftbfs-test/test-rebuild-20140307-trusty.html
<xnox> jtaylor: well, march 16th.
<xnox> ~ 2 weeks ago.
<jtaylor> ah, mixed it up with pytables that still build a week ago
<jtaylor> I'll check it out
<jtaylor> xnox: oh I remember, its nose thats broken
<jtaylor> fixed in debian svn
<jtaylor> want to sponsor :)
<jtaylor> oh been done today, so just needs syncing
<xnox> jtaylor: which package? =)
<jtaylor> python-nose
<xnox> jtaylor: done - https://launchpad.net/ubuntu/trusty/+queue?queue_state=1&queue_text=nose
<jtaylor> thx
<xnox> jtaylor: thanks for tracking this down =)
<jtaylor> mitya57 tracked it down, I just reported :)
<slangasek> ogra_: so I proposed a fix to phablet-test-run, and the testsuite fails CI because of unrelated bashisms in phablet-screenshot :-P https://jenkins.qa.ubuntu.com/job/phablet-tools-trusty-amd64-ci/67/console
<hallyn> hi - could someone on sru team please look at https://launchpad.net/ubuntu/saucy/+queue?queue_state=1&queue_text=libvirt?
<hallyn> the version currently in -proposed failed to build, 8.9 in unapproved fixes that
<bdmurray> infinity: nag about bug 1296386
<ubottu> bug 1296386 in casper (Ubuntu) "[PATCH] Remove 23etc_modules script" [Undecided,New] https://launchpad.net/bugs/1296386
#ubuntu-devel 2014-04-01
<ScottK> xnox: No need to change maintainer for a no change rebuild.
<Mirv> mardy: sure. requires full testing but I'll schedule a slot for that patch.
<Logan_> ScottK: I think it becomes kinda instinctual :P
<Logan_> update-maintainer before debuild -s
<Logan_> *S
<Mirv> any core dev available for packaging ack of ubuntu-ui-toolkit (a doc file change it seems): http://162.213.34.102/job/landing-018-2-publish/lastSuccessfulBuild/artifact/packaging_changes_ubuntu-ui-toolkit_0.1.46+14.04.20140331-0ubuntu1.diff
<dholbach> good morning
<ogra_> slangasek, hmm, i dont get that, must be a false positive https://jenkins.qa.ubuntu.com/job/phablet-tools-trusty-amd64-ci/67/console says line 176 .... nothing suspicious in that line at http://bazaar.launchpad.net/~phablet-team/phablet-tools/trunk/view/head:/phablet-screenshot .... and checkbashisms agrees too http://paste.ubuntu.com/7188675/
<zyga> good morning
<pitti> barry: note your pyflakes sync is stuck in -proposed as it makes lintian4python uninstallable (Depends: pyflakes (< 0.7.3+))
<seb128> mitya57, hey, what does "resubmit" means? should the mp be changed to workinprogress as well so get out of the sponsoring queue?
<mitya57> seb128: Indeed, marked as WIP
<seb128> mitya57, thanks
<mitya57> pitti, barry: https://bitbucket.org/jwilk/lintian4python/commits/f2f7400ef33fcc08, I expect jwilk will upload it soon (he usually does).
 * seb128 is looking at https://bugs.launchpad.net/ubuntu/+source/nautilus-share/+bug/1293177
<ubottu> Launchpad bug 1293177 in samba (Ubuntu Trusty) "'net usershare' returned error 255: net usershare add: cannot convert name "Everyone" to a SID. Access denied." [Medium,Confirmed]
<seb128> which knows about samba/is the closest from a maintainer we have for it?
<seb128> slangasek? ;-)
<hyperair> me
<hyperair> oh
<hyperair> samba
<seb128> lol
<hyperair> :)
<seb128> hyperair, thanks for commenting on that one, pointing it as a samba regression
<hyperair> yeah well, i maintain nautilus-share
<seb128> right
<seb128> do you know what command can be called manually to reproduce the issue?
<hyperair> hmm lemme check
<seb128> thanks
<hyperair> net usershare add sharename /path/to/sharename "comment" Everyone:R
<pitti> mitya57: ah, nice
<rbasak> While we're talking about samba, bug 1296289 bothers me too. Bug 1292548 is a possible dupe.
<ubottu> bug 1296289 in samba (Ubuntu) "smb.conf contains valid users = %S in [global]" [Undecided,New] https://launchpad.net/bugs/1296289
<ubottu> bug 1292548 in samba (Ubuntu) "Standalone Server: Update from Samba 2:3.6.18-1ubuntu3.1 (saucy) to 2:4.1.3+dfsg-2ubuntu3 (trusty) breaks access to the server" [High,New] https://launchpad.net/bugs/1292548
<seb128> rbasak, ok; so more people with samba issue but still no sign of maintainer/somebody wanting to look at those, that doesn't help us much :/
<rbasak> seb128: I'd like to look into this one. It's on my todo, but I feel a bit swamped by death of a thousand papercuts at the moment :-/
<seb128> rbasak, yeah, that's a common issue around here...
<seb128> zul, hey, maybe you can help with those samba issues ^ (would it be good to update to 4.1.5 before the LTS, that report claims it fixes the issue from our current version)
<seb128> slangasek, ^
<FourDollars> Hi, I made a patch on https://bugs.launchpad.net/ubuntu/+source/bluez/+bug/1300623. Could someone help me to review it? It is for precise.
<ubottu> Launchpad bug 1300623 in bluez (Ubuntu) "bluetoothd crashs after resuming from Suspend to RAM. " [Undecided,New]
<seb128> FourDollars, hey, add it to the bug and subscribe ubuntu-sponsors to it
<FourDollars> seb128: I have done it.
<seb128> you can also try to ping cyphermox in a few hours when he starts his day, he usually look at bluetooth issues
<FourDollars> Thanks for the information. :)
<FourDollars> cyphermox: ping
<seb128> FourDollars, he's in Canada and still sleeping at this time
<FourDollars> seb128: haha. I see.
<dholbach> mitya57, do you think we should get another ubuntu-packaging-guide uploaded?
<Cimi> Laney, ev : I've been trying to hook up to diagnostics plugin for system settings to set whoopsie preferences
<Cimi> I set up 'watch qdbus --system com.ubuntu.WhoopsiePreferences /com/ubuntu/WhoopsiePreferences org.freedesktop.DBus.Properties.GetAll com.ubuntu.WhoopsiePreference'
<mitya57> dholbach: Oh, sorry, I promised that I'll update the autopkgtest article, but forgot to do that.
 * mitya57 checks the changelog
<Cimi> but I'm only getting ReportCrashes changing, not AutomaticallyReportCrashes
<Laney> I don't think that automatically works
<mitya57> dholbach: Maybe we should upload the current version, yes
<dholbach> awesome
<mitya57> Will you ping Andrew?
<Laney> Cimi: I asked ev a similar question the other day, I think the setting is simply ignored
<dholbach> mitya57, yes, will do
<Laney> so don't worry about it (assuming I'm right)
<dholbach> mitya57, I was just looking at the packaging guide to see if it could be used as a basis for the docs on developer.u.c :)
<ev> Laney: automatic crash reporting is separate from automatically reporting crashed on failed login, confusingly enough
<ev> automatic crash reporting is needed for the phone
<ev> where we definitely definitely don't want to pop up a dialog when the application goes away
<ev> automatically reporting crashes on failed login is only relevant for the desktop, and is not implemented yet
<ev> automatic crash reporting on the phone is, however
<Laney> oh right
<Cimi> Laney, so we have a bug
<Cimi> Laney, the property is false here
<Laney> Cimi: yeah I see it too
<Laney> infact if I call the dbus method I get a polkit denial
<Laney> so it's a problem there
<Laney> ah wait hang on maybe not
<Laney> ev: whoopsie-preferences crashes when you perform this dbus call!
<Laney> try it on your desktop: gdbus call -y -d com.ubuntu.WhoopsiePreferences -o /com/ubuntu/WhoopsiePreferences -m com.ubuntu.WhoopsiePreferences.SetAutomaticallyReportCrashes true
<Laney> Cimi: indeed there is a bug, well spotted
<apachelogger> pitti: ping bug 1267769 bug 1267771 bug 1267773
<ubottu> bug 1267769 in kubuntu-notification-helper (Ubuntu) "kubuntu-notification-helper needs export to language pack" [High,Triaged] https://launchpad.net/bugs/1267769
<ubottu> bug 1267771 in kubuntu-debug-installer (Ubuntu) "kubuntu-debug-installer needs export to langpack" [High,Triaged] https://launchpad.net/bugs/1267771
<ubottu> bug 1267773 in kubuntu-web-shortcuts (Ubuntu) "kubuntu-web-shortcuts needs export to langpack" [High,Triaged] https://launchpad.net/bugs/1267773
<Riddell> pitti: better do it or else he'll get his pink unicorn onto you
<ev> Laney: that's not good :)
<seb128> does anyone know why http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#unity8 has e.g
<seb128> "out of date on arm64: unity8 (from 7.84+14.04.20140327.1-0ubuntu1) "
<seb128> when unity8 was already not available on that arch
<didrocks> the fix for #271 Touch which doesn't start will be blocked (if unity8 is really blocked on that ^)
<Laney> hopefully fixed for the next run
<Laney> Cimi: ev: It's because nothing creates /var/lib/apport/ and the code doesn't check for this possibility
<Laney> fixing it to create the directory
<Dudytz> hi all .. I have my custom patch in a debian package (gnucash), and a custom preinst to divert a file of another package (a xml: /usr/share/xml/iso-codes/iso_4217.xml) and add a new line ... the line is added after the dpkg-divert via sed command ... this is a good approach or exist another "standard" way to do this?
<seb128> Laney, "hopefully fixed for the next run" ... did you hint anything or are you just hopping it's a transient issue/going to be resolving itself with next publisher?
<Laney> I fixed it, or at least I think I did
<didrocks> yeah, it's not anymore, so should be published next time in the release pocket
<seb128> Laney, what was the issue?
<Laney> there's a faux package which needs to have its version in sync with the archive
<Laney> I didn't follow why it exists, so don't ask me that :P
<seb128> oh ok
<seb128> thanks for fixing it in any case ;-)
<ev> Laney: cheers
<doko> Dimitri John Ledkov (xnox) tried to claim the Launchpad
<doko> team named Debian GCC maintainers (debian-gcc) (which is
<doko> associated with debian-gcc@lists.debian.org).
<doko> To finish claiming that team, making Dimitri John Ledkov (xnox)
<doko> its owner, just follow the link below.
<doko>     https://launchpad.net/token/0VvKD6lckmM57V5Vpp2l
<doko> tss, tss, tss ...
<Laney> O_O
<xnox> doko: Laney: just to protect mailing list from bogus person who tried to merge their launchpad account with the mailing list.
<xnox> you can now forever ignore that team.
<xnox> ScottK: yes and no, so debuild -S may fail if it's ubuntu2 -> ubuntu3 upload and e.g. previous ubuntu upload did not update the maintainer field (e.g. if doko was the TIL). Hence i always do it...
<zul> seb128: rbasak has mentioned a work around
<Cimi> seb128, so I discovered why my privacy page is not working on the phone
<Cimi> seb128, I'm having authorisation failed
<Cimi> seb128, whoopsie preferences and policykit
<Cimi> how do I gather permissions?
<seb128> Laney, ^ you looked at that more than me
<Laney> Cimi: why do you think it doesn't work?
<Laney> Did you see my conversation earlier in response to your question?
<Cimi> Laney, because I get auth failed from my wizard
<Laney> I found that there was a bug with automatic crash reporting
<Cimi> Laney, I'm using the diagnostics plugin from the welcome wizard
<Cimi> and on the phone I cannot change settings
<Laney> Does it work if you launch it from system-settings?
<Laney> (does here)
<Cimi> I receive not authorized qdbus message
<Cimi> Laney, yes
<Laney> Shouldn't be a difference
<Laney> how are you launching your stuff?
<Cimi> Laney, MIR_SOCKET=/run/user/32011/mir_socket system-settings-wizard --desktop_file_hint=/usr/share/applications/webbrowser-app.desktop
<Cimi> from console
<ogra_> Cimi, are you the phablet user when doing that ?
<Cimi> ogra_, yes
<Laney> terminal on device?
<Laney> or ssh?
<Cimi> adb shell
<Cimi> and ssh
<Laney> you don't get the right permissions if you do that
<Laney> try making a script and launching it from the terminal app
<xnox> .... there is upstart-app-launch as well.
<Laney> that works for pk?
<xnox> did not try.
<Laney> doesn't look like it to me
<Laney> Cimi: ^^^
<Cimi> Laney,
<Cimi> Laney, yes
<Cimi> works
<Laney> great
 * ogra_ notes that xnox doesnt like us phone people anymore ... i dont see you on #ubuntu-touch 
<xnox> ogra_: hi, what can I do for you?
<xnox> ogra_: i did a channel clean up, i idle on way too many channels anyway.
<ogra_> well, seems initctl stopped working in the latest image
<ogra_> for the root user
<xnox> ogra_: in what way? does initctl --system list works?
<ogra_> and i was wondering what actually happens after your adbd change ... i duppose /etc/profile gets processed now ?
<ogra_> *suppose
<xnox> ogra_: plus are you talking about root user as: sudo -i from the terminal app from within the phone, or via ssh, or via adb shell?
<ogra_> .... we have hacks like http://paste.ubuntu.com/7189348/ in there
<xnox> ogra_: "root user" is ambigious =)
<ogra_> root user via adb shell i think
<xnox> ogra_: root user talks to system upstart via socket and not via dbus.
<ogra_> ah, k
<ogra_> xnox, how about that one http://paste.ubuntu.com/7189358/
<ogra_> (there is no /run/user/0 ... indeed)
<xnox> ogra_: root user has no user sessions....
<xnox> ogra_: and that snippet is wrong, as it shouldn't be in profile.d
<ogra_> xnox, well, it would be nice if you coulld also see what is discussed in -touch
<xnox> ogra_: i'll read irc logs =)
<ogra_> heh
<xnox> ogra_: again, does: initctl --system list
<xnox> ogra_: work for you?
<ogra_> so Saviq notes that UPSTART_SESSION is unset
<xnox> root user does not have UPSTART_SESSION.
<ogra_> right
<xnox> ogra_: and root user never can talk to upstart user session.
<xnox> ogra_: root user only ever needs to talk to system upstart.
<ogra_> the initctl works on 270 ... i dont have 271 installed since thats completely broked
<xnox> ogra_: hence i've asked you, does: initctl --system list
<xnox> work
<ogra_> (but 271 has your change)
<ogra_> i.e. Saviq testing would be more helpful
<xnox> ogra_: you still didn't tell me what's broken =) you only pasted pastebins of profile.d snippets =)
<Saviq> me just flashes 271 again
<ogra_> xnox, ask Saviq i'm just proxying
<Saviq> xnox, initctl as root didn't work
<Saviq> xnox, for the system init
<xnox> Saviq: does initctl --system list, work?
<Saviq> xnox, I'm reflashing right now, will get back to you in 3
<xnox> Saviq: yeah, i dual boot so for me it takes longer to reflash.
<doko> is this mvo's first work day?
<xnox> doko: are you kidding me?! =)
<Laney> APRIL FOOL!
<Saviq> xnox, I dual boot, too, new dual boot app from ondra actually supports "sideloading" from the host
<Saviq> xnox, https://chinstrap.canonical.com/~okubik/humpolec/refactor/
<xnox> Saviq: hm, haven't upgraded to that one yet.
<Saviq> not official yet, but it's purty ocol
<Saviq> cool
<Saviq> works with system-image downloads, too
<Saviq> and deltas
<xnox> Saviq: so if it works with "--system" then i'd upload updated profile.d snippet to be less crazy.
<xnox> Saviq: yeah, i'd want delta updates \o/
<ogra_> doko, yes
<Saviq> xnox, k, reboots to ubuntu now
<Saviq> xnox, yes, that works
<Saviq> xnox, can I export something in the env so that initctl defaults to the system init?
<xnox> Saviq: ok, can you pastebin me the output of "$ adb shell env" ?
<Saviq> xnox, http://paste.ubuntu.com/7189396/
<Saviq> lunch time...
<mvo> doko: yes, first day today, at your service
<doko> how many wishes do I have? ;-P
<xnox> mvo: welcome back! =)))))))
<mvo> xnox: thanks :)
<doko> xnox, wait until he escapes again to do some app store thingy ...
<ogra_> doko, yeah, the movie start career obviously didnt work out
<xnox> Saviq: i think http://paste.ubuntu.com/7189418/ should solve it. Waiting for the download.
<ogra_> doko, http://video.golem.de/politik-recht/12714/rohrpostsystem.html (forward to 0:47 sec)
<ogra_> s/start/star/
<ogra_> :)
<ogra_> xnox, ++
<ogra_> we would probably also want such a check in the dbus script
<xnox> ogra_: and arguabily it's a bug in upstart as well, since empty UPSTART_SESSION variable, should be ignored.
<xnox> ogra_: well just not export empty vars should be fine.
<ogra_> xnox, note that ubuntu-touch-session is stuck in a silo atm though ...
<xnox> ogra_: [ -n "$DBUS_SESSION_BUS_ADDRESS ] && export DBUS_SESSION_BUS_ADDRESS
<ogra_> (luckily owned by Saviq so you should be able to upload there)
<xnox> ogra_: which silo?
<xnox> or i guess i can hunt down the silo number from spreadsheets.
<ogra_> yeah, u-t-s also became a fulll branch now ... just make an MP
<ogra_> (source packages work pretty bad on silos if there are multiple landings using the same package at different revisions)
<xnox> ogra_: of course it's everything else that's a problem, rather than the silos =)))))))))))
<xnox> ogra_: still downloading 271.
<xnox> ogra_: will propose after checked it's all correct.
<ogra_> it definitely looks correct
 * ogra_ goes back to glare at http://people.canonical.com/~ogra/touch-bootcharts/ubuntu-phablet-trusty-270.png 
 * xnox ponders if mvo's comeback is for one-day only to stage the most ellaborate april's fools joke ever.
<xnox> ogra_: i want a boot chart for emulator. How would i do that?
<ogra_> xnox, i discussed that with rsalveti already ... its a bit more tricky since the initrd needs to be updated
<mvo> xnox: I certainly hope its for more than 1 day :) hopefully at least as long as my pervious gig :)
<Unit193> mvo: Poke.  Any updates? :)
<xnox> ogra_: updating initrd is easy =) what needs changing?
<ogra_> xnox, this is my ultra ugly bootchart script http://paste.ubuntu.com/7189452/ ... i'm working on transforming it into phablet-bootchart for phablet-tools
<mvo> Unit193: uhhhhhh, no yet! sorry!
<ogra_> (and on getting it into CI as a standard test this week)
<Unit193> mvo: Hey, you remembered, better than nothing.  Thanks. :)
<mvo> Unit193: but I will have to use my log file to find the bugnumber :)
<ogra_> xnox, so after the bootchart package was installed, you want to grab the initrd from /boot inside the rootfs i guess ... that should be all (well, and boot with it on the next reboot)
<xnox> ogra_: ack.
<ogra_> (and you probably want to replace the network bringup hack with something sane too :) )
 * ogra_ wonders why there is nothing between 3 and 10 seconds in his dmesg output at http://paste.ubuntu.com/7189485/
<ogra_> i would really like to know whats going on in these 7 seconds
<ivoks> ogra_: /var/log/upstart?
<ivoks> ogra_: or is that even before upstart?
<ogra_> ivoks, thats after initrd (teh swapon is the last thing that happens there) so yes, the first chunks of upstart processing ...
<ogra_> i have a bootchart, i can see what processes ran when, i'm concerned that dmesg doesnt log anything
<ivoks> well, dmesg is kernel only
<ogra_> its init as well
<ogra_> even the android init from the container that starts at 10.78 logs there
<ogra_> ivoks, i think the console switches somewhere where it cant be logged for that time frame
<xnox> Saviq: ogra_: initctl and dbus works with both adb shell as root user and as phablet user with https://code.launchpad.net/~xnox/ubuntu-touch-session/no-export-bogus-environment/+merge/213646 applied
<xnox> Saviq: please reconfigure/land as appropriate.
<ogra_> xnox, great !
<Saviq> xnox, coolz
<Saviq> ogra_, I could add this to the right edge landing, who should review?
<ogra_> Saviq, done
<Saviq> ogra_, building in silo 015
<ogra_> Saviq, do you think you can land it today ? else i would like to push my lxc-android-config changes in the silo as well
<Saviq> ogra_, yes, I really want to land it today
<ogra_> ok
<Saviq> ogra_, just building those and doing last round of testing
<ogra_> (and i would prefer a separate landing :) )
<ogra_> hmm, so even echoing to /dev/kmgs doesnt show up during that timeframe
<ogra_> *kmsg
<ogra_> hallyn, i see a bunch of http://paste.ubuntu.com/7189686/ during boot on the phones ... is there any kernel option we need ?
<pitti> apachelogger, Riddell: travelling today, but these are simple, doing now
 * pitti waves from Dublin airport
<seb128> pitti, hey, what are you doing in Dublin? ;-)
 * ogra_ was about to ask the same :)
<pitti> seb128: waiting for my flight to IoM :)
<seb128> pitti, oh, good to IoM? have fun there!
<pitti> it's horribly difficult to get there -- 9 hours trip there, 10:30 hours back
<seb128> :-(
<pitti> seb128: yep, little sprint here
<pitti> apachelogger: hm, the notificationhelper has been there for a long time already; if it doesn't work that needs some further research, can't do ATM
<pitti> apachelogger: so queueing
<sladen> pitti: yes it takes that long on the train+ferry to get to the IoM :)
<ogra_> hrm ...
<ogra_> so i wonder why it takes two seconds from run-init to starting mountall
<Laney> that's why when you live there you have a private jet :-)
<ogra_> /sbin/init cant be that slow
<sladen> pitti: yes it takes _less than that_ on the train+ferry to get to the IoM :)  (8h30 hours Euston->Douglas)
<pitti> cjwatson: what was the name of that little magic tool which would download apt indexes and let you simulate installs (to check installability problems, etc) as pure user without a full chroot?
<wookey> cjwatson: man-db is failing test on arm64 in debian: https://paste.debian.net/90962/
<wookey> any suggestions before I dig in. it's built OK on trusty in same version SFAICS
<Laney> pitti: I think you're thinking of chdist
<pitti> Laney: yes! that was it, thanks
<pitti> cjwatson: unping
<ogra_> xnox, jodh, so i added some "echo .... >>/dev/kmsg" right before run-init is executed in the initrd and right when mountall starts from upstart ... http://paste.ubuntu.com/7189757/ is what i get then ... any idea why it takes 2.5 sec for run-init to switch to upstart ? (or any idea how i could get more fine grained data)
<jodh> ogra_: are you booting with --debug?
<ogra_> jodh, nope, thats a phone, i cant fiddle easily with cmdline options
<jodh> ogra_: well it would help significantly if you could :)
<ogra_> this is a normal boot ... bootchart installed and these two echos added
<ogra_> hmm
<jodh> can't you modify the initramfs's init script?
<cjwatson> wookey: I tried to reproduce that on real hw and couldn't
<cjwatson> wookey: be my guest if you can see what's up
<ogra_> jodh, ok, was easier than i thought ... trying a boot now
<cjwatson> wookey: oh, that's a different error from the one I saw before, actually - https://launchpad.net/ubuntu/+archive/test-rebuild-20140307/+build/5708181
<cjwatson> wookey: not in remotely the same place either
<cjwatson> wookey: that error's actually from groff
<wookey> If it's not immediately obvious I'll report a bug including the logs, then take a look at what's up.
<ogra_> jodh, bah, to much spam ... the earliest info i can get from dmesg or kern.log is at 8sec
<cjwatson> wookey: suspect you'll need to run the test verbosely to get the actual groff command, use groff's -V option to get the formatting pipeline, apply gdb to troff and see what the values of the relevant variables around there are
 * ogra_ creates an upstart job that makes dmesg snapshots 
<doko> cjwatson, wookey: don't bother about that, this is the xgene optimizing compiler in the test rebuild
<hallyn> ogra: pretty sure that's due to how the upstart jobs are designed.
<seb128> zul, slangasek: comments/opinion on https://launchpadlibrarian.net/171463522/samba.diff
<ogra_> hallyn, well, do i need cgproxy on a phone ?
<seb128> zul, those changes got dropped in https://launchpad.net/ubuntu/+source/samba/2:4.0.10+dfsg-4ubuntu1 (your trusty samba4 merge), not sure if that was on purpose or an overlook/error
<zul> seb128:  +1 from me
<seb128> zul, thanks
<hallyn> ogra: you might, if you were on a re-3.12 kernel
<ogra_> lol
<hallyn> pre-3.12 that is
<ogra_> we are on 3.0 to 3.5
<ogra_> (android kernels)
<hallyn> actually that's not the version, but if /proc/pid/ns/pid does not exist then you need it
<hallyn> but no, wiat
<ogra_> it doesnt exist ... checked that already
<hallyn> respawning.  something else is going on
<ogra_> right
<ogra_> root@ubuntu-phablet:/# ps ax|grep cgproxy
<ogra_>   613 ?        Ss     0:00 /sbin/cgproxy
<ogra_> it starts eventually
<hallyn> well i expect it to start once and go away, then be started manually by the cgmanager job
<hallyn> but what you're seeing is not what i'd expect.  can you start it under strace (in /etc/init/cgproxy.conf)?
<jodh> ogra_: you could try --verbose which is slightly less spammy than --debug
<ogra_> ok
<hallyn> also add --debug to the cgproxy options :)
 * hallyn biab
<ogra_> heh, doing ten things at once here :)
<ogra_> jodh, even with verbose i get the first line at 7.8sec
<ogra_> i'll try to make the ringbuffer larger
<cjwatson> doko: you mean the mandb segfault in the test rebuild?
<cjwatson> doko: wookey's problem is not the same, now that I look at it, it's groff reporting overflows
<hallyn> ogra: kids are still breakfasting, so ignore me for a few mins :)
<doko> cjwatson, yes in the test rebuild only
<ogra_> jodh, line 598 to 857 http://paste.ubuntu.com/7189889/
<ogra_> we have the majority (but not all) plymouth jobs disabled on the phone
 * ogra_ is surprised how much stuff is going on there 
<pitti> Riddell, apachelogger: I'm afraid I need some heads-up here: KDE langpacks got dropped a while ago, what replaced them?
<pitti> Riddell, apachelogger: are these kubuntu specific translations supposed to be in kde-l10n-* or are these teh upstream translations only?
<apachelogger> pitti: kde-l10n is upstream only
<Riddell> pitti: the generic langauge packs for the few kubuntu transations in main
<apachelogger> ^ that's what we concluded last we talked about where to put them anyway ;)
<pitti> aah
<pitti> like /usr/share/locale-langpack/de/LC_MESSAGES/kubuntu-patched-l10n.mo ?
<cjwatson> doko: ok, thanks
<jodh> ogra_: can't we disable /etc/init/startpar-bridge.conf on Touch?
<ogra_> jodh, what does it do ?
 * ogra_ just noticed that disabling the unused ureadahed jobs gains him a good bunch 
<xnox> jodh: if there are no initd scripts that depend on upstart jobs.
<ogra_> i think that was it ...
<ogra_> [    4.286860] run-init !!!
<ogra_> [    4.594689] mountall !!!
<ogra_> only .3 seconds now
 * ogra_ cleans up the kernel cmdline and makes a bootchart 
<jodh> ogra_: great. I thought you'd gone round the ureadahead-required-on-touch-or-not loop already? :)
<ogra_> jodh, i had, it works great by just looping over the .pack files ... but i forgot to disable the default jobs :)
<ogra_> wow !
<ogra_> 2 seconds gained \o/
<pitti> apachelogger: ok, added overrides to langpack-o-matic; next langpack update shold have it
<apachelogger> pitti: danke. I'll put down a todo to verify :)
<xnox> barry: i see strange failures, python-regex ftbfs due to test-suite errors with python2.7. Yet this was not present before, nor in the recent test rebuild....
<barry> xnox: huh, interesting.  is this in the trusty version?
<xnox> barry: yeap.
<barry> xnox: looking
<barry> xnox: test_getattr failure?
<xnox> barry: yeap.
<xnox> barry: the assert is simply checking that default flags are sane. And the flag value under test is insane =)
<barry> >>> import regex
<barry> >>> x = regex.compile('(?i)(a)(b)')
<barry> >>> x.flags
<barry> 8322
<barry>  
<barry> amd64 ^
<barry> xnox: i386 looks sane too
<barry> chroot
<xnox> barry: true. and recompiled & installed .debs also work fine. I'm confused how come it fails in sbuild.
<xnox> barry: i'll upload and hope for the best.
<barry> xnox: sounds good.  if it fails there, the place to look is in Python2/_regex.c.  my best guess is that there's a bogus assumption about the size of the "flags" field in the PatternObject structure.  e.g. sizeof(RE_CODE) != PYSIZET
<xnox> barry: failed on ppc64el https://launchpad.net/ubuntu/+source/python-regex/0.1.20140120-1build1
 * xnox ponders if i'm accidently running ppc64el kernel on my amd64 machine..... nope, i'm not.
<barry> xnox: i don't have time atm to dig into that, but see above.  i'm sure it's an upstream bug.  or file a bug and i can look at it soonish
<xnox> barry: and that's  a regression cause ppc64el did build before.
<xnox> barry: right, thanks! i'll see what i can dig out of above hint.
<barry> xnox: hmm
<barry> cool!
<rbasak> Who runs +1 maint currently?
<rbasak> I'd like to do another month rotation early next cycle, if that still happens. Though I need to run the schedule past my manager first.
<slangasek> ogra_: right, checkbashisms likes it /now/ because a fix for it went in yesterday ;)
<ogra_> lol
<ogra_> slangasek, that checkbashisms run was on precise
<ogra_> or do you mean the CI tool
<slangasek> seb128: if you're asking for my general opinion, I'd say yes we should update samba to the latest 4.1.x version before the LTS; but someone else can go through the FFe process to show that it's safe :)
<seb128> slangasek, that makes sense, thanks
<slangasek> ogra_: ah, yeah, maybe you're seeing a difference in checkbashisms versions... I guess the changes are still in a silo
<slangasek> seb128: Debian unstable is at 4.1.6 now fwiw
<ogra_> slangasek, well, i meant the bastebin i sent you with the ping above
<ogra_> *pastebin
<ogra_> http://paste.ubuntu.com/7188675/
<seb128> slangasek, I saw that
<Laney> sounds like seb128 won a merge :-)
<slangasek> ogra_: with the current checkbashisms?  Regardless, I pushed a change that both works and makes checkbashisms happy
<ogra_> slangasek, i think whatever tool is used there to run the bashism verification should learn about single quotes :)
<slangasek> ogra_: and drops the grep|sed pipe ;)
<ogra_> yes, i saw your fix and it is nice
<ogra_> but i think checkbashisms shouldnt have fallen over in the first place
<seb128> slangasek, do we have somebody usually looking after samba?
<seb128> Laney, nice try :p
<slangasek> seb128: I'd say that's probably zul
<zul> slangasek:  i would say thats rbasak
<seb128> zul, hey, you wouldn't have spare cycles to merge/update samba to the current version before trusty by any chance? ;-)
<seb128> haha
<slangasek> oh, ok
<Laney> hahaha
<Laney> this potato seems pretty warm
<seb128> rbasak hinted he would like to look at those issues but is too busy
<zul> seb128:  sure i can do it then...debdiff?
<ogra_> just make him stop doing that other stuff then :)
<seb128> zul, debdiff of? the versions? ;-)
<rbasak> Part busy, part too scared to touch it! Plus, I'd need sponsorship anyway.
<zul> seb128:  debdiff
<seb128> zul, dget https://launchpad.net/ubuntu/+archive/primary/+files/samba_4.1.3%2Bdfsg-2ubuntu4.dsc http://ftp.iut-bm.univ-fcomte.fr/debian/pool/main/s/samba/samba_4.1.6+dfsg-1.dsc; debdiff *.dsc
<seb128> ? ;-)
<zul> grr...ill have a look it this afternoon
<seb128> zul, sorry if I didn't understand what you asked for ... you though somebody had it merged with a debdiff ready to sponsor?
<ogra_> i think we should just check who touched samba last ... as usually that  person owns it forever :P
<seb128> zul, I can try having a look at the merge if you want
<stgraber> zul: if you do that, can you please fix bug 1268180 at the same time, should be trivial
<ubottu> bug 1268180 in samba (Ubuntu) "net join doesn't work by default since switch to 4.x" [High,Triaged] https://launchpad.net/bugs/1268180
<zul> seb128: i thought it was merged already
<zul> slangasek:  sure
<doko> tkamppeter, what is blocking system-config-printer moving to Python3?
<seb128> zul, oh ok, sorry about the confusion, no we were discussing if it's doable to update to the current point version before the LTS, and trying to find somebody with slots to do that
<zul> seb128:  well i dont have slots but i can do it anyway
<seb128> zul, let me know if you are too busy, I can try having a look at the merge (though I don't know enough about samba to properly test it)
<seb128> zul, thanks
<tkamppeter> doko, I did not try whether it actually works, was busy with making printing working for mobile, so I will ask Tim Waugh, the upstream author.
<mdeslaur> tkamppeter: have you seen this? http://www.openwall.com/lists/oss-security/2014/04/01/4
<stgraber> mdeslaur: that's slightly scary... broadcast some crap on the network and everyone runs it? (well, they have to print something, but still...)
<mdeslaur> stgraber: yeah...good thing cups is protected by apparmor
<ogra_> xnox, did you already do an android rebuild after uploading the touch initrd changes ?
<ogra_> (i have a pending change here i would like to land if you didnt yet, so it gets pulled in alongside)
<tkamppeter> mdeslaur, so we need to check the inserted strings (make/model, PDLs, ...) for illegal characters in cups-browsed?
<mdeslaur> tkamppeter: yeah, I think that would be ok. or rather, a whitelist of valid characters
<tkamppeter> mdeslaur, I will add that and issue it as 1.0.51.
<xnox> ogra_: yeah, that's all landed ages ago with deb support
<ogra_> xnox, i mean the fstab parsing change
<ogra_> that only landed on the weekend, no ?
<ogra_> oh, ignore me
 * ogra_ was off by one week
 * ogra_ blames DST !
<xnox> ogra_: yeah, not sure about timings. But everything is in release pocket, so you are all clear for any android/initramfs changes.
<ogra_> xnox, right, i was hoping you had not uploaded android yet :)
<ogra_> xnox, OH !
<ogra_> xnox, https://launchpad.net/ubuntu/trusty/+source/initramfs-tools-ubuntu-touch/0.70
<ogra_> seems it took two weeks to migrate from proposed
 * ogra_ was wonderign why apt-get source didnt give him 0.70
<cjwatson> ogra_: it was manually blocked for some time by a bug
<ogra_> ah, ok
<xnox> wgrant: infinity: CI has a whole new meaning from now on =)
<doanac> xnox: you have any suggestions/ideas how i can get the ubuntu-emulator to show up as an adb device?
<mdeslaur> tkamppeter: thanks
<ogra_> doanac, it just shows up as one once adbd is started (here at least)
<ogra_> you just need the patience to wait til its booted after 20min :P
<doanac> ogra_: hmm. i get the device to boot and have a log-in prompt in my shell. but it doesn't show up under adb
<ogra_> doanac, do you have the UI yet ?
<doanac> ogra_: its off now. let me power on so i can give more info
<ogra_> adb only starts after the container nowadays
<ogra_> so pretty late in the boot process
<doanac> last night i had it to the touch intro, but no adb
<ogra_> hmm, thats surely wrong
<doanac> ack. i'll retry
<doanac> hopefully user-error
<xnox> mvo_: would you be able to kick off command-not-found data update based on trusty series? as far as i could trace it, it's still running by your cronjobs albeit still against precise (or some such).
<mvo_> xnox: I certainly hope its not against precise, but probably saucy, but I will check
<mvo_> xnox: now that I can login again :)
<xnox> mvo_: well, I only tested against something that's new in trusty. E.g. "ubuntu-emulator" is not known to command-not-found =)
<doanac> ogra_: so  my emulator is running. i'm at the edges intro, i've got a login prompt for ttyS2, but adb-devices shows nothing on my host pc
<ogra_> weird
<ogra_> (i havent run an emulator in a while, let me try)
<doanac> thanks. i suspect its something easy to address. i just wasn't sure where to start
 * ogra_ watches his laptop to start hovering over the desk
<ogra_> doanac, so i see adbd running in the emulator, but you are right, no device seen on my laptop
<ogra_> doanac, restarting the adb server on the laptop helped
<ogra_> i assume adb waits for an USB event it doesnt get for noticing the connection
<doanac> ogra_: that helped. mine is still offline though
<doanac> it shows up as offline that is
<ogra_> thats strange, i'm logged in
<doanac> hmm. my emulator seems locked up.
<ogra_> ogra@styx:~/Devel/packages/android-tools-4.2.2+git20130218/core/adbd$ adb devices
<ogra_> List of devices attached
<ogra_> emulator-5554	device
<ogra_> and i can log in just fine
<doanac> ogra_: let me retry this. if it just needs a restart, i can code around things for now
<ogra_> k
<doanac> ogra_: thanks. i think i've got a path forward now!
<ogra_> awesome
<zyga> doanac: hey
<zyga> doanac: how are you? :)
<doanac> zyga: not too bad. what's up?
<ogra_> i would ask to open a bug for that but i have not even remotely a clue if thats a qemu issue or udev on the host ... or adb
<zyga> doanac: good, thanks, busy week, eh?
<doanac> zyga: yeah. they've all been pretty busy lately :)
<cjwatson> psusi: I think the LVM regression here is because dev->loop is undefined on some paths.  Considering http://paste.ubuntu.com/7190835/ - what do you think?
<cjwatson> psusi: the whole PedDevice.loop thing seems to be very awkward in terms of layering, because you need it when you only have a PedDevice in hand, but strictly speaking it's really a property of a PedDisk ...
<psusi> cjwatson, I just noticed that I did make a booboo there... if you run parted and attempt to rm the fake partition, it pukes trying to remove the lv itself
<cjwatson> Don't know if that's related
<psusi> I just had to clear the loop flag temporarily and restore it after the remove partition step... but there seem to be a number of different weird things going on in partman
<cjwatson> It's not that weird
<cjwatson> partman is doing a ped_device_new_fresh
<cjwatson> You only initialise dev->loop in ped_device_new
<cjwatson> So it's random
<cjwatson> (I think)
<psusi> beacuse the first problem I run into, even after fixing that issue removing the fake partition, is that the first error in syslog is that /dev/ubuntu-vg can not be statted... well, no kidding, you didn't call pvcreate and vgcreate yet
<psusi> it just created the partitions at that point
<cjwatson> Sorry, s/ped_device_new/ped_disk_new/g in all that
<cjwatson> That's all a consequence of the above, as far as I can tell
<psusi> retrying the same step again lets it correctly create the lv/pv and proceed, after I fixed the issue with removing the fake partition
<cjwatson> It tries to call pvcreate/vgcreate but it's very confused because the uninitialised PedDevice.loop causes it to get the wrong path to create the PV on
<psusi> then  why does it work the second time?
<cjwatson> Second time it'll be going through ped_disk_new which *does* initialise it
<psusi> ohh, I see
<psusi> do those changes fix it?
<cjwatson> I'm trying to rig a test now
<psusi> why did you remove the initialization from ped_disk_new?
<cjwatson> Because ped_disk_new calls ped_disk_new_fresh
<psusi> ohh, right
<cjwatson> Presumably you're not allowed to ask a PedDevice for a partition path without going through ped_disk_new* first
<cjwatson> Hopefully
<cjwatson> Like I say, the layering is awkward
<psusi> ok, in addition to those changes, you want to go disk_sync_part_table and around the call to remove_partition, add an int loop = disk->dev->loop; disk->dev->loop = 0;, then restore it after
<cjwatson> I don't quite see why you didn't instead key off PED_DEVICE_FILE or some such
<psusi> because a loop device isn't a PED_DEVICE_FILE
<cjwatson> But this whole area of parted has always been a total mess
<psusi> yea... it has... that's why I've been trying to fix it up
<cjwatson> Well, it's still a conceptual mess :)
<psusi> you can create a loop label on a normal scsi disk if you want
<cjwatson> You now have ped_device behaviour that depends on what ped_disk has done on top of it ...
<psusi> that's actually the use case I was working on in gparted when I found and tried to fix these bugs... you mkfs the whole scsi disk with no partition table
<psusi> yea... the layering is a bit goofy
<cjwatson> would you mind pastebinning me a patch for the disk_sync_part_table thing?  I have a rotten headache and not sure I'm coherent
<psusi> come to think of it, maybe taht should have been just initialized in linux_new
<cjwatson> it kinda sounds like hack upon hack
<cjwatson> isn't it better to do it in the architecture-independent code?
<psusi> well yea... the loop lable is kind of a hack... its basically pretending there is a partition table there when there isn't
<cjwatson> oh, you only use it in linux.  why is it not in PedDevice.arch_specific then?
<psusi> good point
<psusi> hrm... it shouldn't be linux only
<cjwatson> hack upon hack> what I mean is, why do we need the partition path with number appended in some situations but not others?
<cjwatson> that seems to make only dubious sense
<psusi> because partitions normally have a number appended
<psusi> but not when you don't have a partition table ( i.e. loop label )
<cjwatson> sure.  but why then do we suddenly need the number when removing partitions?
<cjwatson> surely either we need it or we don't
<psusi> say you initially do have a partition table with some partitions, and then mklabel loop over top of it
<psusi> you want to remove the no longer needed partitions
<cjwatson> oh, loop is set way before actually committing the removal, right
<cjwatson> this is foul
<cjwatson> I'd have thought then that we need to detect what the actual pre-removal state is, rather than just forcing it to zero ...
<psusi> can't really and it doesn't matter
<psusi> if the partitions are there, we remove them... if they aren't... then we don't care...
<psusi> i.e. if we get back ENXIO trying to remove, we ignore it since it's already gone and that's what we wanted
<cjwatson> well, it's potentially a name clash isn't it?
<cjwatson> I agree it's relatively unlikely
<cjwatson> with my patch, vg creation works, but I get a whinge about being unable to inform the kernel about the change to partition 1 of /dev/mapper/ubuntu--vg-root
<cjwatson> maybe that's the removal issue you describe
<psusi> cjwatson, http://paste.ubuntu.com/7190938/
<psusi> bingo
<psusi> what is potentially a name clash?
<cjwatson> what if somebody makes an lv called root1
<psusi> ahh, ick... and one called root, and then creates a partition on it?
<cjwatson> I guess it would still have clashed before, just differently
<psusi> yea
<psusi> yea, there's just no good way out of that one
<psusi> other than patching lvm to not allow you to create such names ;)
<cjwatson> there is.  parted could know that vg-root wasn't previously non-loop-partitioned and never try to access vg-root1
<cjwatson> like I say, by reading the previous state
<psusi> well no, this doesn't have anythign to do with loop lables
<psusi> if you just make a volume named root, and another named root1, then use parted to create a partition table and partition on loop, then it's going to clash with the root1 lv
<psusi> s/loop/root
<cjwatson> but if it's a loop table on root, then it should never need to hit root1
<psusi> true... but at that layer of the code there is no "previous" state you can compare to... remember, the same stuff is called when you execute partprobe
<psusi> which only knows what the current partition table says... has no idea about what, if anything, was there before
<cjwatson> mm.  horrible.
<psusi> so it just has to remove everything
<psusi> well, it's a lot better than it was before when it was using BLKRRPRT ;)
<psusi> also the name clash goes beyond parted
<cjwatson> ok, same warning this time round
<psusi> no tool or person can tell whether /dev/mapper/root1 is a partition or lv
<psusi> you sure you got it applied and the updated package installed in your testing vm?
<psusi> it fixed it for me
<cjwatson> pretty sure
<cjwatson> no doubt we're hitting different warnings
<psusi> you rebooted the vm with a clean disk right?
<cjwatson> yes
<psusi> run parted by hand on the lv and try to rm 1
<psusi> that's how I reproduced it and figured out what was really going on
<cjwatson> "Warning: Partition /dev/mapper/ubuntu--vg-root is being used. Are you sure you want to continue?"
<psusi> you have it mounted ;)
<cjwatson> well yes, but that's basically the same error I was getting in the UI
<psusi> well you can't remove a partition that's mounted
<psusi> and the ui certainly shouldn't be trying to
<cjwatson> this all worked before so something is broken.
<cjwatson> I'm afraid I'm out of steam for today though
<cjwatson> I'll pick it up again tomorrow and try to disentangle it
<psusi> I'm positive it never tried to remove a mounted partition before ;)
<cjwatson> I expect that this is a second-order effect
<cjwatson> Something to do with this parted change is confusing it into trying to do so
<psusi> if you didn't clear the disk when you rebooted the vm, then it probably found the existing swap partition and mounted that?
<cjwatson> I cleared the disk
<cjwatson> Stop it :P
<psusi> hrm... weird
<cjwatson> Obviously it isn't *intentionally* trying to remove a mounted partition device
<cjwatson> That would be silly
<psusi> by clear the disk you don't just mean blew away the partition table right?
<cjwatson> I mean qemu-img create
<psusi> yep, ok then...
<cjwatson> The error is on ped_disk_commit
<cjwatson> And OK, the error in the UI is actually different
<cjwatson> "Partition(s) 1 on /dev/mapper/ubuntu--vg-root have been written, but we have been unable to inform the kernel of the change, probably because it/they are in use.  As a result, the old partition(s) will remain in use.  You should reboot now before making further changes."
<cjwatson> Sorry for misleading
<psusi> yea.. same thing
<psusi> the question is how the hell can it be trying to (re)create the partition after mounting it
<cjwatson> right, yeah, after I unmount, I get a stream of "device-mapper: remove ioctl on ubuntu--vg-root failed: Device or resource busy"
<cjwatson> Then the above message
<psusi> then you must not have my patch in there?
<cjwatson> (from "rm 1" in "parted /dev/mapper/ubuntu--vg-root")
<cjwatson> I sure do
<cjwatson> Oh
<psusi> that's exactly what I had before I applied that patch
<cjwatson> Damnit, I lost my debian/changelog
<cjwatson> So it built with the wrong version
<psusi> heh
<cjwatson> Sorry!
<psusi> <G>
<cjwatson> Right, that actually seems to work now
<cjwatson> http://paste.ubuntu.com/7191088/ for the record
<cjwatson> If that still looks sensible to me in the morning then I'll upload
<cjwatson> Don't trust myself with dput right now :)
<cjwatson> Thanks
<psusi> looks sensible to me.... will see if I can find any other ways to break it
<cjwatson> I'll actually fold that into fix-loop-labels.patch of course, no point having patch upon patch for the same thing
<psusi> aye
<psusi> and I'll upstream those changes
<cjwatson> Thanks
<bdmurray> hallyn: bug 1300927 sounds familiar but I don't recall the exact details
<ubottu> bug 1300927 in procps (Ubuntu) "lxc. procps can not be installed" [Undecided,New] https://launchpad.net/bugs/1300927
<hallyn> bdmurray: yeh it does sound familiar.  but by now i thought we had procps not failing if it fails to write to something?
<blkperl> cjwatson: I'm running into this issue, bug 1300943, any suggestions? I'm trying to get log files but mount is hanging when trying to connect my nfs server
<ubottu> bug 1300943 in parted (Ubuntu) "parted unable to inform kernel of partition change" [Undecided,New] https://launchpad.net/bugs/1300943
<psusi> cjwatson, come to think of it, disk.c shoudln't be touching loop at all... it should only need initialized once... in device.c just after it is created
<hallyn> bdmurray: i'll follow that one, thanks
<bdmurray> hallyn: cool, thank you
<hallyn> if eth0 is defined both in /etc/network/interfaces and /etc/network/interfaces.d/eth0, which definition do we expect to be used?
<stgraber> hallyn: short answer, "don't do that".
<stgraber> in practice, I'd sort of expect the response to be "both" but I'd have to go look at the code to make sure
<stgraber> ifupdown isn't very clever, it basically reads the /etc/network/interfaces and processes things as it finds them
<stgraber> so I'd expect it to first parse and bring up the first one, then find the second one through the include and complain because it's already up
<hallyn> stgraber: i'm not doing it, i'm looking at a system where it's the case... :)
<mwhudson> infinity: eglibc is failing to build for me on arm64
<infinity> mwhudson: In what way?
<infinity> mwhudson: Also, the buildds would mostly disagree with you. ;)
<mwhudson> infinity: have you seen anything like this? http://paste.ubuntu.com/7191580/
<mwhudson> yes
<mwhudson> i realize :)
<infinity> mwhudson: A log and a debdiff of what you're abusing it with would help.
<mwhudson> ok
<infinity> mwhudson: I've never seen tst-tls5 fail, no.  That's either a regression from the patch you're testing, or a bug in the kernel you're building on.
<mwhudson> hm
<mwhudson> i bet the kernel
<mwhudson> 3.13.0-19-generic
<mwhudson> are the buildds still on 3.8?
<infinity> Or a bug in the binutils patches from APM that doko accepted?
<infinity> But I'm pretty sure I've built glibc in the archive since then.
<infinity> mwhudson: The buildds are still on 3.8 until I can adequately test a distro kernel for sanity, yeah.
<mwhudson> i guess binutils could do this too for sure
<mwhudson> infinity: do you still want to see build log / debdiff?
<infinity> So, binutils could absolutely do that, but the last eglibc upload to the archive was after the last binutils, by several days.
<infinity> So it's probably not that.
<infinity> mwhudson: Diff yes, log no, your snippet was enough.
<mwhudson> infinity: http://paste.ubuntu.com/7191589/
<infinity> mwhudson: Also, find the tst-tls5 invocation in your log and try running that massive line of goop by hand a few times to see if it's just racy/confused somehow.
<mwhudson> i assume you don't just want to take my word for it and upload that to the archive? :)
<infinity> Though that doesn't look racy.
<mwhudson> it's failed the build twice
<infinity> mwhudson: I'll throw your patch at a PPA and see how it fares on the distro builders too.
<mwhudson> the first time i thought it might have been moving the time by 140 years during the test suite...
<mwhudson> infinity: that would be great, thanks
<infinity> mwhudson: Some headers in said patch that indicate origin and the like would be nice. :P
<infinity> mwhudson: And maybe some prodding of Will to push harder to get it re-reviewed and committed.
<mwhudson> infinity: heh, yes
<mwhudson> does quilt refresh eat comments like that>?
<mwhudson> i quilt import-ed the git format-patch version i think
<mwhudson> and yes, i don't think will's reposted the patch yet
<infinity> mwhudson: quilt refresh should ignore everything above the patch itself.
<infinity> cjwatson: Hey, grub-probe has an FD leak, according to LVM.
<infinity> (LVM, the best leak tracer EVER)
<mwhudson> infinity: hm ok, i wonder what i did wrong then
<bdmurray> stgraber: could you have a look at bug 1300516?
<ubottu> bug 1300516 in dbus (Ubuntu) "upstart sessions needs to create upstart cache directory" [Undecided,New] https://launchpad.net/bugs/1300516
<stgraber> bdmurray: looks reasonable to me
<stgraber> I'd probably make it: [ ! -d "$HOME/.cache/upstart" ] && mkdir -p "$HOME/.cache/upstart"
<stgraber> which is shorter and covers some corner cases (spaces and such)
<bdmurray> stgraber: okay, do you want to apply / upload that or should I?
<stgraber> bdmurray: I can do it
<stgraber> bdmurray: uploaded
<juliank> infinity: So, (Continuing here, rather than on #debian-devel) Does http://paste.debian.net/91079/ look sensible for trusty?
<infinity> juliank: Why did get_ubuntu_mirrors go away?
<juliank> bdmurray: In case you're bored, you're opinion is appreciated as well. If we can get that python-apt into trusty, I'll just upload it to Debian as 0.9.3.5 and we can sync. Otherwise, we'd need cherry-pick the python/tag.cc and possibly the debian/* changes.
<juliank> infinity: Because we use a script get_ubuntu_mirrors_from_lp for a long time already.
<juliank> The old one is unused and broken.
<infinity> juliank: The python2.6 cleanups look fine to me to accept as-is.
<infinity> juliank: Ahh, kay.
<infinity> juliank: In that case, that all looks fine, assuming a changelog that explains it.
<juliank> infinity: Now the only question is, should I follow APT into 1.0 land and name the release 1.0.0 or should I stick with 0.9.3.5, or should I use 0.9.4. That's an important question!
<infinity> juliank: Whoa, apt went 1.0?
<juliank> It's bug fix only, but hey super stability is a good reason for a 1.0
<juliank> infinity: Yes, today.
<xnox> juliank: i thought that was april's fools joke.
<juliank> Or yesterday, depending on location (it's now yesterday here)
<infinity> I don't know how to deal with this information.
<xnox> bah, it did =) http://packages.qa.debian.org/a/apt/news/20140401T170442Z.html
<infinity> Michael just broke my brain.
<xnox> also, appears to use a very small key.
<infinity> juliank: Anyhow, version it how you like.  But if you want to imply that "this is the python-apt you should use with apt 1.0", going for the version bump might make sense.
<juliank> Meh, now python-apt FTBFS on Debian because of a new pyflakes version which complains about more things.
<juliank> We're shadowing _ in a loop variable.
<xnox> barry: i ponder if we'll manage to drop python2 from the desktop cd this cycle =)
<xnox> barry: if we push printing stack it should be all tip-top.
<Unit193> gstreamer0.10 is close.
<xnox> that too.
<xnox> cyphermox: any news on bluez-gstreamer?
<xnox> cyphermox: i'm tempted to just drop it, and see if anything breaks.
#ubuntu-devel 2014-04-02
<cyphermox> xnox: tomorrow morning I'll test removing it to see what breaks, and I tell you then whether it's ok to remove?
<cyphermox> my tomorrow morning is in about 12 hours.
<FourDollars> cyphermox: Could you help me to review the patch of https://bugs.launchpad.net/ubuntu/+source/bluez/+bug/1300623 ?
<ubottu> Launchpad bug 1300623 in bluez (Ubuntu) "bluetoothd crashs after resuming from Suspend to RAM. " [Undecided,New]
<mwhudson> infinity: hey did you stick that libc patch into a ppa?
<mwhudson> should have built or failed by now i think...
<infinity> mwhudson: Nope.  I'm like a kitten with a laser pointer today.
<mwhudson> heh
<mwhudson> infinity: anything i can do to make it more likely?
<infinity> mwhudson: Uploading nowish.
<infinity> In theory.
<infinity> When the source builds.
 * infinity smacks his laptop.
<mwhudson> infinity: which ppa?
<infinity> mwhudson: adconrad/ppa
<mwhudson> cool
<infinity> mwhudson: And building.
<mwhudson> infinity: awesome, thanks
<mwhudson> takes about 90 mins on arm64, right?
<infinity> mwhudson: So, if this works and fixes your issue, we have a few things to do.
<infinity> mwhudson: 1: nag Will harder about upstream review (but I won't block on this)
<infinity> mwhudson: 2: Fish Will's testcase patch out of libc-alpha and give me that to add with this other patch.
<infinity> mwhudson: 3: Figure out WTF our distro kernel chokes on tst-tls5. :/
<mwhudson> 1: i cc:ed you on a mail to will earlier i think?
<mwhudson> i meant to, anyway
<infinity> mwhudson: Yeah, you did. :)
<mwhudson> cool
<mwhudson> 2: ack
<mwhudson> 3: yes :/
<mwhudson> do you know offhand what that test is testing?
<mwhudson> other than thread local storage
<infinity> Haven't looked at it at all.
<mwhudson> kay
<infinity> But the failure doesn't look like something we should XFAIL either, without understanding why.
<mwhudson> indeed
<mwhudson> totally a WAG but... how do i tell if i have a 64k page kernel?
<infinity> getconf
<infinity> (base)adconrad@cthulhu:~$ getconf PAGESIZE
<infinity> 4096
<mwhudson> ok same
<mwhudson> boring
<infinity> mwhudson: And about 70 minutes to build on arm64.
<infinity> mwhudson: At least, on my snazzy 2.4GHz buildds. :P
<mwhudson> heh
<mwhudson> what are the porter boxes?  2.0?
<infinity> mwhudson: If they're still A2s, then yeah.
<mwhudson> hm, 'make check' just succeeded in ~/eglibc-builds/eglibc-2.19/build-tree/arm64-libc
<mwhudson> how do you run the tests?
<infinity> mwhudson: Well, make check would have had nothing to re-make...
<mwhudson> oh ok
<infinity> mwhudson: I go hunt through the log for the exact invocation of the test that failed and just run that massive commandline over and over.
<infinity> I'm sure there are better ways. :P
<infinity> mwhudson: So, I have no idea what am1 is, cause the new cpuinfo is completely uninformative.
<infinity> Special.
<mwhudson> infinity: hey, it tells you that there are 8 cores
<mwhudson> but yes
<infinity> mwhudson: The lack of model name and speed seems weird.
<mwhudson> infinity: ok
<mwhudson> so
<mwhudson> the test program prints WRONG ALIGNMENT
<mwhudson> (and fails)
<mwhudson> _if_ you have ulimit -s unlimited
<mwhudson> (which makes memory be allocated in the other direction)
<mwhudson> (the fact that i know this bothers me i think)
<Niles> Could it be a PAE problem?
<mwhudson> 64 bit user space on 64 bit processor?  i hope not
<Niles> Oh wait, that's dumb
<Niles> Nevermind
<Niles> Only case I know where memory gets allocated backwards
<mwhudson> i've only read the relevant bits of the kernel for arm64 :)
<mwhudson> so um yeah
<mwhudson> does anyone happen to know where THREAD_SELF is defined/
<mwhudson> ?
<mwhudson> (on aarch64)
<barry> xnox: that would rock :)
 * mwhudson hugs the glibc source layout
<sarnold> I've never seen an ironic hug before, but there it is :)
<mwhudson> now __builtin_thread_pointer
<mwhudson> i guess that's a gcc thing
<mwhudson> sarnold: :)
<infinity> mwhudson: I'd I'm reading the log-in-process right, tst-tls5 didn't fail in my PPA.
<infinity> s/process/progress/
<mwhudson> infinity: i think if my patch was causing this failure i'd give up and start looking for lawn mowing jobs
<infinity> Lawn mowing is good, honest work.
<infinity> You might need to buy some shoes, though.
<infinity> sarnold: You don't like the glibc source tree?
<infinity> sarnold: Given the complex concepts it needs to encapsulate, I feel it does a pretty good job.
<infinity> Doesn't take long to wrap your head around the cascading include paths, etc.
<mwhudson> i find the fact that the eg s390 platform specific code is in ./nptl/s390 but the aarch64 specific stuff is in ./ports/sysdeps/unix or somewhere constantly confusing
<infinity> mwhudson: Oh, well, ports is gone in 2.20
<mwhudson> infinity: \o/
<infinity> mwhudson: Or will be, once all the ports are moved.  Most are.
<infinity> In fact, all but hppa look to have moved.
<infinity> Carlos is a slacker.
<mwhudson> oh
<mwhudson> um
<mwhudson> does libpthread do some crazy magic in its .init section?
<mwhudson> because i now have a test program that fails _if_ it's linked against libpthread
<mwhudson> and not otherwise
<mwhudson> infinity: can you run a small test case on a buildd (or some other vintage kernal machine i guess)
<infinity> mwhudson: Sure.
<mwhudson> infinity: http://paste.ubuntu.com/7192634/
<infinity> mwhudson: http://paste.ubuntu.com/7192638/
<mwhudson> ho strange
<infinity> mwhudson: Well, seems to be the same as the results you got?
<mwhudson> yes
<infinity> So, not a regression.
<infinity> But quite possibly a bug.
<mwhudson> maybe i was just building eglibc in a shell that had ulimit -s unlimited?
<infinity> mwhudson: Seems plausible.
<mwhudson> it would be a good explanation, but i don't recall changing that :/
<mwhudson> ah, i remember why i didn't quilt import this patch: it isn't rooted at the base of the tree
<infinity> mwhudson: Well, quilt import doesn't work so well in eglibc probably anyway.
<infinity> mwhudson: But just stuffing the git-formatted patch in debian/patches/ubuntu/ works fine. :P
<mwhudson> ok i'm now rebuilding in a shell that _definitely_ does not have ulimit -s set
<mwhudson> (well rather, not set to unlimited)
<mwhudson> and yes, this looks like a bug
<mwhudson> glibc tests that pthread_self is always 16 byte aligned, and on aarch64 with unlimited stack it isn't
<mwhudson> so is the bug in the test or the ... whatever sets the tls pointer
<infinity> mwhudson: Worth an upstream bug report and a nudge to the maintainers.
<mwhudson> yeah
<mwhudson> glibc bugzilla?
<infinity> Yeah.
<mwhudson> i'll ping linaro-toolchain about it too
<mwhudson> infinity: https://sourceware.org/bugzilla/show_bug.cgi?id=16796 (i added you to cc so maybe you got mail already)
<ubottu> sourceware.org bug 16796 in nptl "[aarch64] pthread_self not aligned to 16 bytes when heap grows up" [Normal,New]
<cyphermox> FourDollars: gladly. patch looks fine, perhaps it should just also happen in saucy and trusty?
<FourDollars> cyphermox: The codebase changed too much in saucy and trusty so this patch may only work in precise.
<cyphermox> ok
<cyphermox> well then I'd like to give it a shot in trusty tomorrow
<cyphermox> and if I can't make it work, then I'll just say so on the bug so there's no questions
<cyphermox> FourDollars: want to update the bug for the SRU process?
<FourDollars> cyphermox: yes
<cyphermox> FourDollars: thanks
<cyphermox> FourDollars: I'll sponsor the patch first thing tomorrow morning
<FourDollars> cyphermox: Sorry. I just checked saucy and trusty. I think this patch can also apply on them.
<FourDollars> cyphermox: Thanks a lot.
<cyphermox> FourDollars: alright, np :)
<FourDollars> :)
<cyphermox> if it turns out it doesn't work for you, I'll look myself in the morning to see if I can make sense of it
<FourDollars> OK
<sarnold> infinity: well, I can't really argue one way or another about glibc source tree except to say that when I try to figure out how something is implemented in the libc wrappers in linux, it always takes me two or three times longer to find it than I'd expect
<pitti> Good morning
<ion> that
<infinity> mwhudson: Well, that was a quick response to your bug.
<infinity> mardy: You around?
<infinity> mardy: Your dpkg-maintscript-helper calls in account-plugins should have a version argument on them, so it's not attempted on every single upgrade forever.
<infinity> mardy: I'm rejecting based on that.  Please fix.
<dholbach> good morning
<mardy> infinity: OK
<mardy> infinity: I should put the version where the script was last useful, right?
<infinity> mardy: It should be the version just before the one being uploaded.  The easiest way to do that is just to tack a ~ on the end of the version you're uploading.
<infinity> mardy: ie: if you're uploading 1.2.3-1 that removes the conffile, the version passed to rm_conffile should be 1.2.3-1~
<infinity> mardy: The manpage explains why, and how.
<mardy> infinity: ok, thanks
<infinity> mardy: (Given that you're doing daily builds that tend to have a large gap between uploads, though, you could probably just fudge it as "$date -1" or something if you wanted to)
<infinity> mardy: But generally, the goal is to not screw over people who rebuild, do local test builds, derive in other distros, etc, etc.
<doko> Sweetshark, could you have a look at https://launchpad.net/ubuntu/+source/accessodf/0.1-4/+build/5866883 ?  looks like the only difference is the lo version
<mardy> dbarth: so, infinity suggested a change in the account-plugin-flickr debian scripts
<mardy> dbarth: quoting from this morning:
<mardy> 09:39 < infinity> mardy: Your dpkg-maintscript-helper calls in account-plugins should have a version argument on them, so it's not attempted on every single upgrade forever.
<mardy> 09:39 < infinity> mardy: I'm rejecting based on that.  Please fix.
<dbarth> mardy: ah ok
<dbarth> mardy: then can you file a bug with infinity's concerns, and i'll land asap
<mardy> dbarth: why a second one? account-plugins didn't land, did it?
<Noskcaj_> Can someone check if modemmanager is syncable?
<Noskcaj_> There's some fairly important upgradeing fixes
<dbarth> mardy: it did
<dbarth> mardy: was tested and published yesterday
<dbarth> mardy: i merged them this morning, since we couldn't take back the packages anyway
<mardy> dbarth: oh, you are right
<mardy> dbarth: but the bug is still open
<mardy> dbarth: and the merge proposal is not in "merged" status yet
<mardy> dbarth: even though I see that the changes are now in trunk... weird...
<Sweetshark> doko: weird. yeah, Ill take a look.
<Noskcaj_> Logan_: http://paste.ubuntu.com/7193182/
<seb128> Noskcaj_, hey
<Sweetshark> doko: so, have it fixed locally, wonder why it ever build. investigating if we changed the API there upstream ...
<Sweetshark> oh, we did. Well actually those cowboys at AOO changed the API and we followed suit ...
<brendand> hi, this is a slightly unusual situation, but if we had a feature in a package and then had to drop it for while and now want to bring it back, will we need a feature freeze exception?
<pitti> infinity: ah, lintian autopkgtest succeeds now; thanks for pointing out the dep parsing bug
<infinity> pitti: Yeahp, I got the spam about it being fixed.  Thanks. :)
<didrocks> xnox: are you going to reupload your g+ apps or should I do that?
<pitti> infinity: so that was either a bug in lintian or in python-debian; I suspec that the comment in lintian isn't entirely legal, but then again this is probaly underdefined (comments starting at the first column but don't break the continuation line)
<infinity> pitti: The comment does start at the first column...
<infinity> Oh, I missed the "but" there.
<pitti> infinity: right, but it's in the middle of a continuation line
<pitti> infinity: so, I don't know whether that's legal or a bug in python-debian, but it just works around that now
<pitti> it == adt-run
<infinity> pitti: Yeah, it's arguable if it's allowed or not, but I'm not sure I've ever read anything that says it's not, and dpkg parses it correctly.
<infinity> pitti: And I'd say that dpkg is the authority on how to parse debian/control.
<pitti> *nod*, hence I filed a bug against p-debian
<infinity> pitti: I'd have just torn the comments out in our delta, but then it would still be broken for ci.debian, plus it can't be the only package that does that.
<infinity> pitti: So, yay, thanks for the bug and the workaround. :)
<xnox> didrocks: i can republish it, if the container/ua is fixed now.
<xnox> cyphermox: that would be awesome! you're a start =) thanks.
<didrocks> xnox: yeah, you need to target the 14.04 dev1 framework though
<didrocks> xnox: to get oxide
<xnox> didrocks: right, yeah i see ping from davmor2 about that.
<davmor2> xnox: see everyone loves the google+
<ogra_> wow, G+ in the new browser is just lovely to use
<ogra_> working javascript makes such a big difference
<davmor2> ogra_: so easily pleased now get off G+ and get some work done ;)
<ogra_> haha
<davmor2> ogra_: and none of this I'm just "testing oxide" milarky either that's my excuse :P
<ogra_> heh
<xnox> is there a way to get oxide on the desktop?
 * xnox dist-upgrades first
<ogra_> xnox, i think that should get it for you (at least for the webapps)
<happyaron> seb128: why unity-control-center depends on ibus?
<seb128> happyaron, because it writes to its gsettings schemas
<seb128> I though of you when that was added
<seb128> I guess we could handle the missing schemas and lower to a recommends or something
<happyaron> if recommends is doable then that'd be great.
<seb128> happyaron, https://code.launchpad.net/~attente/unity-control-center/1288717/+merge/209982
<seb128> happyaron, btw https://bugs.launchpad.net/ubuntu/+source/unity-control-center/+bug/1288717/comments/3
<ubottu> Launchpad bug 1288717 in unity-control-center (Ubuntu) "/usr/bin/unity-control-center:6:g_assertion_message:g_assertion_message_expr:ibus_config_get_value:orientation_combo_changed:_g_closure_invoke_va" [High,Fix released]
<seb128> happyaron, but you never bothered replying to my comment
<seb128> happyaron, if you had you would have seen the change/new depends...
<seb128> happyaron, anyway, I don't think making that a recommends is on top of you priority list, but patches are welcome if somebody wants to work on that
<happyaron> seb128: well I'm being so busy recently dealing with all kinds of stuff...
<seb128> happyaron, we all are...
<happyaron> :)
<seb128> happyaron, anyway you have the why you asked for now ;-)
<tkamppeter> mdeslaur, I have issued cups-filter 1.0.51 upstream now and also packaged and uploaded it for Trusty, so the vulnerability is fixed now. Thanks for the report.
<happyaron> seb128: well the good thing is we got this fix: https://bugs.launchpad.net/ubuntu/+source/im-config/+bug/1297831/comments/18
<ubottu> Launchpad bug 1297831 in Ubuntu Kylin "Input method set to ibus in Ubuntu Kylin, while fcitx is the desired default" [Critical,Fix committed]
<happyaron> seb128: so you are right, it's not on the top of my list.
<seb128> happyaron, ok, good
<brendand> seb128, this is a slightly unusual situation, but if we had a feature in a package and then had to drop it for while and now want to bring it back, will we need a feature freeze exception?
<seb128> brendand, I would assume so, but check with #ubuntu-release
<Sweetshark> doko, seb128: fix for the build breaker at http://people.canonical.com/~bjoern/trusty/accessodf_0.1-1.3ubuntu2_amd64.changes -- the diff is next to it ...
<seb128> Sweetshark, thanks, is that something we can get in Debian and sync?
<Sweetshark> seb128: its a clearcut buildbreaker -- I guess debian would want that. Although the fix doesnt recreate the messagebox type (infobox, questionbox etc.), but IMHO thats something for upstream (not debian) to take care of.
<pitti> doko: s/langpack-en-us
<pitti> doko: ... /language-pack-en-us/ :)
<Sweetshark> seb128: Ill hint rene at it (although he is not the maintainer there)
<pitti> doko: sorry, I mean language-pack-en; we don't have by-country packs except for -zh
<pitti> doko: FYI, infinity wants to move langpack-locales back into eglibc and also build locales-all (hopefully next cycle), so that's going away at some point
<seb128> Sweetshark, do you still want sponsoring to trusty? we can sync over from Debian once they fix it
<Sweetshark> seb128: lets wait for renes reaction first ..
<seb128> Sweetshark, k
<apachelogger> pitti: https://launchpad.net/ubuntu/+source/gpgme1.0/1.4.3-0.1ubuntu2 seems to have broken kdepim s/mime support as per bug 1293704
<ubottu> bug 1293704 in kdepim (Ubuntu) "Kleopatra don't support s/mime" [High,Confirmed] https://launchpad.net/bugs/1293704
<shadeslayer> pitti: https://bugs.launchpad.net/ubuntu/+source/ubuntu-drivers-common/+bug/1301307
<ubottu> Launchpad bug 1301307 in ubuntu-drivers-common (Ubuntu) "Empty vendor string for driver" [Undecided,New]
<shadeslayer> tseliot: ^^
<xnox> ogra_: are there any webapps that work as contained clicks with oxide?
<xnox> cause updated g+ fails like shown in bug #1301305
<ubottu> bug 1301305 in webbrowser-app (Ubuntu) "oxide fails to launch contained webapp" [Undecided,New] https://launchpad.net/bugs/1301305
<ogra_> xnox, yes, the default shipped ones (gmail, facebook etc) ... and the browser itself is using it now
<ogra_> only webapps that havent been re-uploaded with the new framework added use the old way still
<tseliot> shadeslayer: I don't think there's a single vendor for that
<shadeslayer> tseliot: right, but then the UI just looks terribly broken
<shadeslayer> or atleast the KDE one does
<tseliot> shadeslayer: any pictures?
<shadeslayer> moment
<ogra_> xnox, using the gmail app and then clicking the G+ menu option in there works too ... just has the gmail top bar then :)
<xnox> ogra_: maybe i need "webview" policy group. Let's see.
<shadeslayer> tseliot: http://im9.eu/picture/a19862
<shadeslayer> tseliot: something else I noticed
<tseliot> shadeslayer: you might want to have a fallback such as "Unspecified vendor" for when that happens
<shadeslayer> tseliot: the pci values for Airport extreme is a subset of the one from linux-firmware-nonfree
<shadeslayer> /sys/devices/pci0000:00/0000:00:15.0/0000:02:00.0/ssb0:0 vs /sys/devices/pci0000:00/0000:00:15.0/0000:02:00.0
<shadeslayer> so maybe it would make sense to group them together?
<tseliot> shadeslayer: does the Airport extreme require linux-firmware-nonfree?
<shadeslayer> tseliot: yep
<shadeslayer> that or the other b43 driver
<shadeslayer> both work
<tseliot> shadeslayer: and what do you mean by "grouping them together"?
<shadeslayer> tseliot: under the same device :)
<shadeslayer> so that ubuntu-drivers devices shows Broadcom Airport Extreme with 2 drivers : b43 and linux-firmware-nonfree
<tseliot> oh, I see what you mean now
<tseliot> I guess that would make sense
<tseliot> pitti: ^
<ogra_> oh !
<ogra_> oh ! oh !
<ogra_> video streaming inside the phone bowser works now !!!
<xnox> new g+ is in the store review queue.
<mdeslaur> tkamppeter: awesome, thanks!
<Riddell> 6/win 15
<Riddell> tsk
<addiks> hi, does anybody know which exact component is responsible for giving input-events to the applications?
<dobey> dpm_: ping
<dpm_> hi dobey
<dobey> dpm_: hi. do you know what the recommended way to build translations with under cmake would be?
<mardy> is there a directory which can be used to store files which are cleared after a user's session ends?
<dobey> intltool doesn't integrate with cmake
<mardy> I've thought about XDG_RUNTIME_DIR, but that's not cleared on logout
<dobey> mardy: delete the file when your process ends?
<mardy> mdeslaur: I see you are here, maybe you know? ^
 * ogra_ hugs xnox 
<mardy> dobey: I want the file to persist across my process invocations, while in the same user session
<mdeslaur> mardy: I don't believe there are any
<dobey> yeah, there aren't any
<mardy> dobey, mdeslaur: that's also good to know :-)
<dpm_> dobey, yeah, unfortunately there is no standard way of building translations with cmake, and intltool does not support cmake. We ended up writing a custom rule to build them for core apps, e.g.: http://bazaar.launchpad.net/~ubuntu-weather-dev/ubuntu-weather-app/trunk/view/head:/po/CMakeLists.txt
<mdeslaur> mardy: you can probably store something in XDG_RUNTIME_DIR, and then check the timestamp on it vs. when the user session started
<ogra_> xnox, external links dont open in the G+ app ... (not sure thats the app or the container)
<mardy> mdeslaur: mmm... interesting! How can I know when the session started?
<dobey> dpm_: ok, thanks
<xnox> ogra_: i had to enable urlpatterns. At the moment login screens and google plus itself should stay in google plus.
<mdeslaur> mardy: I...uh....well....perhaps you can ask logind? /me isn't sure
<xnox> mdeslaur: i thought we do cleate a fresh XDG_RUNTIME_DIR on each login... that's the whole point of it.
<dpm_> dobey, in addition to that, we also use a bit of a hack to extract translations from the desktop.in file: http://bazaar.launchpad.net/~ubuntu-weather-dev/ubuntu-weather-app/trunk/view/head:/CMakeLists.txt#L58
<ogra_> xnox, well, it doesnt open any external pages ... (though i assume thats a drawback of the new browser)
<xnox> ogra_: oh, well... not sure =)
<ogra_> xnox, oh, and i can play embedded videos when i open G+ in the browser, i guess your app musses the video apparmor profile
<ogra_> *misses
<ogra_> (i cant play it in the app)
<xnox> ogra_: i have video profile.
<ogra_> weird
<xnox>     "policy_groups": [
<xnox>         "networking",
<xnox>         "audio",
<xnox>         "video",
<xnox>         "location",
<xnox>         "webview"
<xnox>     ],
<dobey> dpm_: ok.
<mdeslaur> xnox: doesn't look like it...stuff stays there
<ogra_> xnox, well, open G+ in the browser and tap a youtube video, it plays fine ... doesnt in the app
 * ogra_ was just trying that with his recent post
<ogra_> in the app i see the loading animation ... and then it stops
<ogra_> dbarth, ^^^
<mdeslaur> xnox: nope, if the directory exists, it's kept as-is
<dbarth> hmm, just reading the backlog
<dbarth> xnox: do you have apparmor rejects when trying to play that video?
<dbarth> xnox: it may also be that the app tries to play video fullscreen and fails
<dbarth> the youtube player i mean
<ogra_> dbarth, http://paste.ubuntu.com/7194027/
<dbarth> previously it was not even trying, cause we were not detected as a "good enough" webview
<ogra_> smells like you need some apparmor love from jdstrand
<dbarth> ogra_: weird
<ogra_> (this is what i get when trying to play an embedded yourtube video in G+ ... the same thing works when using G+ in the browser)
<dbarth> do you have policy_version 1.*1* ?
<ogra_> hmm, no idea
<dbarth> i see you have the webview group already
<ogra_> i'm on the latest image
<dbarth> you need both, ie add the webview p.g. and bump the policy_version to 1.1
<ogra_> where do i check that ?
<dbarth> and declare framework 14.04-dev1
<dbarth> manifest.json and <app>.json
<ogra_> yes, i think thats what xnox did with his last upload
<dbarth> then it's a bug
<ogra_> http://paste.ubuntu.com/7194044/
<dbarth> can you file and affect webbrowser-app, use [webapp-container] as a prefix
<ogra_> looks all fine
<dbarth> and i'll affect oxide and other if neede
<dbarth> d
<ogra_> (this was /opt/click.ubuntu.com/net.launchpad.click-webapps.gooogleplus/6/app.json)
<jdstrand> dbarth: where have these rejects been happening?
<jdstrand> dbarth: the silo or the archive?
<ogra_> dbarth, bug 1301351
<ubottu> bug 1301351 in webbrowser-app (Ubuntu) "[webapp-container] embedded videos do not play in G+ app while they play fine in the browser" [Undecided,New] https://launchpad.net/bugs/1301351
<ogra_> jdstrand, latest image with the latest G+ app
<ogra_> (both updated today, using oxide now)
<ogra_> jdstrand, see the bug above
<jdstrand> well, it should be against apparmor-easyprof-ubuntu
 * jdstrand changes
<ogra_> jdstrand, well, not sure, it might be two bugs ... (external links ... and video playback)
<jdstrand> dbarth: fyi, I was trying to work out the final profile changes when I hit that crasher bug, so was blocked
<jdstrand> but I'll get it worked out
<ogra_> dbarth, m.youtube.com doesnt play back videos at all ... tapping on play just reloads
<ogra_> (funny because the same video embedded in a G+ post plays just fine)
<xnox> jdstrand: would i need to reupload the app? i believe i have all the correct intentions declared in the policy groups.
<jdstrand> xnox: for that bug ^? no
<jdstrand> xnox: I'll fix it and the policy will be regenerated on the first boot of the new image. if you are impatient, you can install apparmor-easyprof-ubuntu directly
<xnox> jdstrand: ah cool =) didn't know how/when policies are regenerated =) if all gets fixed with an image update, that's cool! =)
<xnox> like, really _cool_ =)))))
<smoser> xnox, are you still looking at bug 1160079 ?
<ubottu> bug 1160079 in plymouth (Ubuntu) "plymouth aborts in cloud images" [Medium,Confirmed] https://launchpad.net/bugs/1160079
<xnox> smoser: yes, i can upload a fix with just the cloud bits. Cause my other changes on top need some further work (e.g. on my machine plymouth crashes on shutdown and i haven't debugged it yet)
<xnox> smoser: i'll upload the cloud fix later today.
<smoser> xnox, thanks, that would be awesome.
<hallyn> seb128: would you mind looking at the 1.1.1-0ubuntu8.9 libvirt awaiting acceptance for saucy-proposed?
<seb128> hallyn, I'm not part of the SRU team
<hallyn> d'oh, i was looking at the wrong comment, sorry
<hallyn> bdmurray: ^
<seb128> no worry ;-)
<jdstrand> ogra_: do you have a couple minutes to help me with the apparmor denials?
<ogra_> jdstrand, i can try
<jdstrand> ogra_: ok, in /var/lib/apparmor/profiles/net.launchpad.click-webapps.googleplus_googleplus_6
<jdstrand> ogra_: you'll see these rules:
<jdstrand> /usr/lib/@{multiarch}/oxide-qt/oxide-renderer Cx -> oxide_helper,
<jdstrand> /usr/lib/@{multiarch}/oxide-qt/chrome-sandbox cx -> oxide_helper,
<jdstrand> ogra_: can you change them to:
<jdstrand> /usr/lib/@{multiarch}/oxide-qt/oxide-renderer Cxmr -> oxide_helper,
<jdstrand> /usr/lib/@{multiarch}/oxide-qt/chrome-sandbox cxmr -> oxide_helper,
<jdstrand> ogra_: when done, please do: sudo apparmor_parser -r /var/lib/apparmor/profiles/net.launchpad.click-webapps.googleplus_googleplus_6
<jdstrand> ogra_: then relaunch the web app
<jdstrand> ogra_: oh, I forgot one. way down you'll see this rule:
<jdstrand> /usr/lib/@{multiarch}/oxide-qt/oxide-renderer rmix,
<jdstrand> under it, can you add:
<jdstrand> @{PROC}/sys/kernel/yama/ptrace_scope r,
<udevbot> Error: "{PROC}/sys/kernel/yama/ptrace_scope" is not a valid command.
<jdstrand> ogra_: then do 'sudo apparmor_parser -r /var/lib/apparmor/profiles/net.launchpad.click-webapps.googleplus_googleplus_6' and relaunch the app
<ogra_> jdstrand, no change ...
<ogra_> let me reboot the phone
<jdstrand> ogra_: are there denials?
<ogra_> havent seen any when tailing syslog
<jdstrand> ok, then it is like you said-- two bugs
<ogra_> but the video doesnt play
<ogra_> well, the other would be "not opening external links"
<jdstrand> heh, well, I mostly mean I can fix my bug
<ogra_> jdstrand, i dont really get why it plays flawless when opening G+ in the browser ... might not be apparmor related though
<jdstrand> it is probably the webapp-container
<jdstrand> I'll direct you to alex-abreau and dbarth
<jdstrand> let's go to #webapps
<jdstrand> (where they both are)
<ogra_> well, dbarth asked me to file the bug, he is aware
 * dholbach hugs mvo
<ogra_> no need to be pushy, it never worked before ... having it working in the browser now is a massive improvement already :)
<Laney> How can I run a/the click user hook/s manually?
<Laney> I got an apport report from one of them
<Laney> click hook run-user, got it
<barry> mvo: ping
<mvo> barry: hello! pong
<barry> mvo: hi!  thanks for merging and uploading gdebi.  it'll be nice to kill another python2 dependency. :)  however i think there's a problem in sid:
<barry> apt-get install gdebi-core
<barry> The following packages have unmet dependencies:
<barry>  gdebi-core : Depends: python3:any (>= 3.4~)
<barry>  
<barry> that's in a fresh sid chroot, but on a debian system w/gdebi-core already:
<barry>  gdebi : Depends: python3:any (>= 3.4~)
<barry>          Depends: gdebi-core (= 0.9.5) but 0.9.4 is to be installed
<barry>  
<mvo> barry: oh, let me have a look
<barry> thanks
<barry> mvo: ah, i see xnox committed (probably) a fix in bzr
<xnox> barry: and uploaded...
<mvo> :) thanks xnox !
<xnox> barry: it seems that X-Python3-Verions: >= 3.4 was actually honored and impossible dependencies got generated =)
<barry> xnox: thanks!  will you sync once it lands in debian?
<xnox> barry: it's not needed on ubuntu.
<xnox> barry: as our python3 is 3.4
<barry> xnox: right, it didn't break us, but it still might be good to keep in sync
<barry> xnox, mvo anyway, thanks!
<Riddell> gosh, an mvo
<mvo> hey Riddell
<pitti> juliank: FYI, our jenkins now exports *-packages, like in https://jenkins.qa.ubuntu.com/job/trusty-adt-unattended-upgrades/45/ARCH=i386,label=adt/
<bdmurray> hallyn: should that supercede the existing libvirt (which appears to have ftbfs btw)
<hallyn> bdmurray: yes
<bdmurray> hallyn: got it
<hallyn> i goofed - the pach i was backporting in 8.8 had a hunk applied int he wrong effing fn
<hallyn> thanks
<jibel> barry, mvo latest pyflakes seems to have broken autopkgtest of unattended-upgrade https://jenkins.qa.ubuntu.com/view/Trusty/view/AutoPkgTest/job/trusty-adt-unattended-upgrades/ARCH=amd64,label=adt/46/artifact/results/dsc0t-run-tests-stdout
<barry> jibel: thanks, that ought to be shallow.  let me see if i can craft a fix
<juliank> pitti: That's great, but why do you tell me about it? Did I ask about that recently?
<juliank> Seriously, I don't know. I forget many things I ask.
<mvo> jibel: thanks
<mvo> barry: let me know if you want me to have a look instead
<barry> mvo: if you have some time to get a fix uploaded, that would be great.  this ought to do it: http://paste.ubuntu.com/7194816/
<barry> mvo: or something like it ;)
<mvo> barry: aha, the new "shadowing" warning :)
<mvo> barry: sure thing, happy to do that
<barry> mvo: yep ;)  thanks!
<pitti> juliank: hm, I thought you did; sorry if I mixed that up with someone else
<pitti> juliank: sorry, I was
<pitti> jtaylor: FYI, our jenkins now exports *-packages, like in https://jenkins.qa.ubuntu.com/job/trusty-adt-unattended-upgrades/45/ARCH=i386,label=adt/
<juliank> pitti: No problem.
<jibel> bdmurray, FYI, I reproduced bug 1286161 with the clone from the OP
<ubottu> bug 1286161 in ubuntu-release-upgrader (Ubuntu Trusty) "13.10 -> 14.04 upgrade failed: initramfs failed to ugprade, udev is not configured yet" [High,Confirmed] https://launchpad.net/bugs/1286161
<mvo> barry: uploaded
<barry> mvo: thanks!
<bdmurray> jibel: oh, anything interesting?
<jibel> bdmurray, apart that it is reproducible with packages from the archive without any PPA, nothing else yet
<bdmurray> jibel: oh, you might interested in bug 1290584 regarding apt-clone
<ubottu> bug 1290584 in apt-clone (Ubuntu) "apt-clone restore should have a use my mirror option" [Undecided,In progress] https://launchpad.net/bugs/1290584
<pitti> xnox: all these "ValueError: invalid literal for int() with base 10:" in ubiquity, is that real, or just a transient thing?
<pitti> xnox: i. e. does it make sense to retry a few times, or is that really broken?
<pitti> xnox: sounds like it's trying to interpret a nonexisting debconf key as a number?
<pitti> but why would removing the u1 bits affect partman..
<xnox> pitti: haven't looked. That error messages comes up for any reason when debconf backend goes away.
<xnox> (and ubiquity still tries to interract with it)
<pitti> hallyn: is 2.0 still on the table for trusty? it gets kind of tight now
<pitti> hallyn: FWIW, I've been using it since your annoucement (and that crash fix), and have basically forgotten about it :) (IOW, all happy)
<hallyn> pitti: yeah, my plan is if upstream doesn't tag v2.0 this weekend i will take a git snapshot for .orig.tar.gz and push to trusty archive
<pitti> hallyn: ah, you were waiting for the final, not on testing any more?
<hallyn> pitti: what do you mean?
<pitti> hallyn: yes, then uploading a pre-release snapshot sounds fine
<hallyn> pitti: im' still uploading new versions to that ppa every other day or so
<pitti> hallyn: the diff from the snapshot to final is presumably much smaller than 1.7 to 2.0 final?
<hallyn> oh, yeah, i definately do not want to do a diff on top of 1.7
<pitti> oh, need to run out, taxi going back to the hotel; good night everyone
<hallyn> pitti: good night
<doko> mlankhorst, tjaalton: xorg ping
<tjaalton> doko: xorg pong
<doko> tjaalton, two things:
<doko> https://launchpad.net/ubuntu/+archive/test-rebuild-20140307/+build/5735335  the xorg-gtest ftbfs
<doko> and the vnc4 ftbfs for arm64 and ppc64el (embedded xorg), https://launchpad.net/ubuntu/+source/vnc4/4.1.1+xorg4.3.0-37ubuntu5  do you have an idea how to fix that?
<tjaalton> ugh
<tjaalton> i bet xorg-gtest builds fine on sbuild..
<tjaalton> lp is picky
<tjaalton> no idea about vnc4.. i'd just drop it but someone might whine
<bdmurray> stgraber: could you have a look at bug 1300654?
<ubottu> bug 1300654 in isc-dhcp (Ubuntu) "Prompt to update unmodified configuration file during upgrade from Precise to Trusty" [High,New] https://launchpad.net/bugs/1300654
<stgraber> bdmurray: I'm aware of it
<bdmurray> stgraber: great
<mwhudson> infinity: so the glibc build failed *again* for me, and i am very sure that ulimit -s wasn't unlimited
 * mwhudson tries to remember the other reasons why the heap might grow up
<infinity> mwhudson: Try the patch in the bug you filed?
<mwhudson> well yes, that will certainly help
<infinity> mwhudson: (assuming it was tst-tls5 that failed again)
<mwhudson> or is certainly worth trying at least
<mwhudson> yeah, same failure
<mwhudson> i wonder if the newer kernel grows the heap up in some other circumstance than 3.8
<infinity> mwhudson: I'm really not interested in knowing all the reasons why that test might fail, if the 2-line patch fixes the bug. :P
<mwhudson> yeah, focus focus
<mwhudson> building
<infinity> hallyn: *poke*
<infinity> hallyn: In that cgmanager upload, you moved pretty much EVERYTHING to /lib ... Really, only the actual library should move, the .so, .pc, and .a should stay in /usr/lib
<infinity> hallyn: Also, you dropped the static build (intentional?), and your changelog claims you added -static when I think you meant -shared.
<infinity> stgraber: ^ If you want to address any/all of that for hallyn...
<infinity> mvo: Say, why does unattended-upgrades have .pyc files in the source?
<juliank> infinity: I believe the pyc files in unattended-upgrades were accidental See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=741467 for the fix.
<ubottu> Debian bug 741467 in src:unattended-upgrades "unattended-upgrades: source package contains generated files (*.pyc)" [Minor,Fixed]
<juliank> While I'm not mvo, this might still help.
<infinity> juliank: Ahh, kay, good to know that it's been addressed.  I just noticed the binary diffs in the queue and was non-plussed, but it's not like this is a new regression in the packaging or anything. :P
<juliank> Maybe mvo wants to merge 0.82.4, assuming it's not too different from 0.82.1ubuntu1. The "fix Bug in rewind_cache() that can cause unwanted removals of packages" in 0.82.2 makes 0.82.1 seem a bit scary
<jtaylor> what are the chances of still patching libtool to not strip gccs -fsanitize stuff in trusty?
<jtaylor> hm I guess its not super important as you can get the links indirectly in your main application
<infinity> jtaylor: I'm not sure that changing the behaviour of libtool two weeks before release would be a bright idea.  Since nothing will be rebuilt with it, but all security updates will be.
<jtaylor> yes
<jtaylor> just tested it, indirect links seem to work alright anyway
<hallyn> infinity: feh, so i should just be moving the actual file by hand in debian/rules?
<hallyn> infinity: i dropped the static build bc libcgmanager.so didn't want to be built -shared unless I did so;  if i find a way to have both happen i'll re-add the static lib
<infinity> hallyn: Sure, don't care much about the static lib, was just curious.
<infinity> hallyn: And yeah, check the bit in expat's debian/rules which moves libexpat.so.* to /lib and then re-targets the symlink in /usr.
<infinity> hallyn: Should be able to do that fairly cleanly in a dh_auto_install override.
<infinity> (Credit to slangasek for finding the expat rules snippet)
<hallyn> ok, thanks.  I'll change that tongiht and re-push.
<doko> robert_ancell, pyexiv2 ftbfs on ppc64el
<xnox> stgraber: not sure if you are arround, could i get a silo for: https://code.launchpad.net/~xnox/indicator-applet/drop-u1/+merge/213873 and https://code.launchpad.net/~xnox/webapps-applications/remove-u1/+merge/213853 ?
<xnox> or does anybody know who is US/west based who can allocate silos... cyphermox ?
<stgraber> xnox: I'm not on the landing team myself, so I can add you to the spreadsheet but since those aren't foundations team packages, you may as well go straight to the ci channel
<xnox> stgraber: hm, let me check who those two should go via. Maybe i can ping about them tomorrow.
<stgraber> cyphermox is my usual suspect but it's past our eastern time EOD so he may be gone for dinner or something
<xnox> i've been chatting with dbarth about the webapps one, not sure who is responsible for legacy applets.
<xnox> stgraber: excellent. "indicator-applet" has no owner =) but it has been reviewed by ~unitish people. Could you silo up that one?
<stgraber> xnox: since they're related, they probably should go in the same silo, let me add you to the spreadsheet at least
<xnox> stgraber: all of them are stand alone. webapps is about dropping ubuntuone music webapp, indicator-applet is about dropping recommends to indicator-sync which will stop working.
<xnox> stgraber: the two unity7 branches are already inflight in silo5 - which do same as indicator-applet branch + twiddle default settings to drop u1 control panel from default launchers.
<xnox> unity7 is bundled with other bug-fixes however, so i wouldn't want to piggy back on top of that.
<xnox> bregma: can you release/land indicator-applet?
<stgraber> xnox: ok, I added you to the spreadsheet, let's see if there's someone in #ubuntu-ci-eng to give you a silo
<xnox> bregma: this is assuming indicator-applet are ~= unitiish =)))
<xnox> stgraber: could you ask? i'm not in that channel at all.
<stgraber> xnox: yeah, just joined and asked (since we pretty much never land anything through the citrain I don't idle in there)
<stgraber> xnox: do you have any testsuite I should link in there?
<xnox> stgraber: it's desktop only, btw.
<xnox> stgraber: i have manual test cases to test that xubuntu works, and that shortcuts are not in the default unity launcher. I've tested both locally.
<xnox> (xubuntu is the prime user of indicator-applet)
<stgraber> xnox: ok, I think I've put as much details as I can in the spreadsheet, hopefully someone will flip the switch and give you a silo soon
<xnox> stgraber: thanks a lot! i'll watch that spreadsheet.
<robert_ancell> doko, what is the easiest way to test on ppc64el?
<doko> robert_ancell, ssh porter-ppc64el.canonical.com
<robert_ancell> doko, any chance of getting git installed on there?
<cjwatson> robert_ancell: schroot -c trusty-ppc64el
<doko> robert_ancell, afk now
<cjwatson> robert_ancell: git's in the schroot
<cjwatson> robert_ancell: (and you can "sudo apt-get install" things)
<robert_ancell> ah, thanks
<stgraber> xnox: we've got a silo
<xnox> \o/
<xnox> cjwatson: i'm pretty sure i've installed a whole bunch of things in the chroot, to the point of getting build-conflicts now. sudo apt-get remove does not work.
<xnox> cjwatson: was i using our porter boxes somehow wrong? (e.g. a session/snapshot is not created for me that gets auto-cleaned up)
#ubuntu-devel 2014-04-03
<cjwatson> xnox: https://rt.admin.canonical.com/Ticket/Display.html?id=68468
<cjwatson> xnox: For now you'll just have to get IS to remove things for you
<xnox> cjwatson: whilst modern style porter boxes would be nice, getting rapt to support "remove" command would be nice as well.
<xnox> (limited to things outside of e.g. minimal and build-essentials or some such)
<cjwatson> Maybe, but that just increases the chance of people clashing with each other.  I'd rather we just had modern infra
<infinity> xnox: Not supporting remove was an intentional design decision when we wrote rapt.
<xnox> ok.
<infinity> xnox: Because you removing a build-conflict that happens to be a build-dep that doko's 8h build-in-progress depdends on would suck.
<infinity> (But yes, we should just move to the Debian way of doing things)
<doko> ?
<xnox> doko: don't worry, we are not _actually_ breaking one of your in-progress 8h builds. it's just hypothetical =)
<infinity> doko: You were just being used as a fictional example, not being summoned.
<doko> oh, I would like YOU to be summoned, and not just as a fictional example
<infinity> doko: But, given our history, whenever I think of someone breaking a computer and affecting a long-running build, the hypothetical user is you. ;)
 * infinity still remembers the week-long GCC builds on his Amiga...
<doko> yeah, glibc sucks with test suites
<mwhudson> infinity: so that patch from andrew fixes the eglibc build for me
<mwhudson> oh i guess i should also glom up the test case
<infinity> mwhudson: Okay, can you give me an email with all the patches you know and love, and I'll get them queued up for the next upload?
<infinity> mwhudson: So, that should be Will's setcontext patch, Will's testcase for same, and that 2-liner for the alignment issue.
<infinity> mwhudson: With patch headers pointing to origin, since none of them are in git yet. :/
<mwhudson> infinity: i just commented on  https://bugs.launchpad.net/ubuntu/+source/eglibc/+bug/1279620#9
<ubottu> Launchpad bug 1279620 in eglibc (Ubuntu Trusty) "stack corruption running "go install launchpad.net/juju-core/..."" [High,Confirmed]
<mwhudson> infinity: i don't know the formatting for patch headers, i can go find it out i guess...
<UBUNTUuser> hi guys I want to know if ubuntu 14.04 will work will daul boot
<blkperl> UBUNTUuser: yep
<infinity> mwhudson: Oh, I don't care if it's formatted in any specific way.  Garbage above the diff is fine.
<infinity> mwhudson: I can fix it up, I just want the refs.
<mwhudson> infinity: is that bug comment useful? i can email them as well...
<UBUNTUuser> you sure I am already having problems with ubuntu 13.10
<UBUNTUuser> I have a uefi which secure boot
<UBUNTUuser> is on
<blkperl> UBUNTUuser: your question is probably better suited for #ubuntu, this is the dev channel
<UBUNTUuser> ok
<infinity> mwhudson: Nope, that's perfect.
<infinity> robert_ancell: Did you want your changelog for that lightdm to actually match reality? :P
<robert_ancell> infinity, um... what did I write?
<infinity> robert_ancell: s/greeter/cursor/
<robert_ancell> yeah, that would make more sense
<infinity> robert_ancell: Not enough of a nit for me to reject, but feel free to retroactively fix it in your VCS so it's not a lie on the next upload. :P
<cyphermox> stgraber: xnox: I'm around now
<robert_ancell> infinity, there are many wrong changelog entries :)
<infinity> robert_ancell: I don't doubt it. :)
<blkperl> cjwatson: so since you fixed bug 1300072 my trusty install works but now im running into bug 1274320
<ubottu> bug 1300072 in parted (Ubuntu Trusty) "LVM installation fails - regression with parted 2.3-17" [Critical,Fix released] https://launchpad.net/bugs/1300072
<xnox> cyphermox: well, you could help me understand what's going on in silo11 and why it failed to build =)
<ubottu> bug 1274320 in grub2 (Ubuntu) "Error: diskfilter writes are not supported" [Medium,Confirmed] https://launchpad.net/bugs/1274320
<cyphermox> sure
<infinity> robert_ancell: Also, wtf?  -lstdc++?  Is that not building with g++?
<robert_ancell> infinity, I have no idea, but the library build explicitly does that
<robert_ancell> so making the introspection match fixes the problem
<xnox> cyphermox: it said it build everything, and then decided not to upload them.... or something?!
<infinity> robert_ancell: Ahh, yeah, it's using cc
<infinity> robert_ancell: Building C++ code with cc is usually a sign that one's doing something wrong.
<xnox> cyphermox: i'd love to fix that up, if i new what needs changing.
<cyphermox> oh, nice.
<robert_ancell> infinity, feel free to berate them on https://bugzilla.gnome.org/show_bug.cgi?id=727521 :)
<ubottu> Gnome bug 727521 in build "Fails to build on ppc64el" [Normal,Unconfirmed]
<infinity> robert_ancell: Although... This could have more to do with the libtool macros being broken in that build.
<infinity> robert_ancell: Did you test with just dh_autoreconf before adding the link hack?
<infinity> checking whether the g++ linker (/usr/bin/ld -m elf64ppc) supports shared libraries... yes
<infinity> Err, wrong paste.
<infinity> checking whether the gcc linker (/usr/bin/ld -m elf64ppc) supports shared libraries... no
<infinity> ^-- Indicative of libtool macros needing love.
<robert_ancell> infinity, no, I only added it because I couldn't patch the Makefile directly without automake getting confused
<infinity> robert_ancell: So, the above needs to be addressed.  And if dh_autoreconf fixes the above, the lstdc++ thing probably isn't needed.
<robert_ancell> infinity, I can check, but I think it will need the -l stdc++
<infinity> robert_ancell: It really shouldn't if other arches don't.
<robert_ancell> infinity, g-ir-scanner is great at getting linking wrong
<cjwatson> blkperl: expected, grub can't write to raid, not new
<robert_ancell> infinity, huh, you're right
<cjwatson> (or lvm)
<infinity> robert_ancell: Figured.  I'll reject your current upload, then. :)
<robert_ancell> infinity, cheers :)
<cjwatson> blkperl: and save_env involves writing to /boot/grub/grubenv
<cjwatson> blkperl: the best we could do is maybe silence the error - but like I say it isn't a new thing
<infinity> robert_ancell: You might want to followup to that upstream bug noting that all they need is a newer/saner libtool.
<infinity> robert_ancell: So people don't go hunting in circles some other weird cause. :)
<robert_ancell> infinity, should I re-use -0ubuntu2 or do I make a -0ubuntu3?
<infinity> robert_ancell: 2 is fine, the rejected one doesn't get used up.
<cyphermox> xnox: tbh, I think there might be no way for me to tell you currently
<cyphermox> xnox: let's try to run it again :/
<xnox> cyphermox: maybe add the two source packages to "Sources:" line?
<chiluk> Hey cjwatson , I'm casually looking into https://savannah.gnu.org/bugs/?42026 , and Vladimir thinks that our grub-efi version is differnt from our grub-pc version.  Any clue where to start looking?  The grub-pc version works fine, but the grub-efi fails to discover the amt sol serial port..
<xnox> cyphermox: no idea if that will help the train driver or not =)
<cyphermox> two new source packages?
<cjwatson> chiluk: well that's not possible, they're built from the same source.
<chiluk> that's what I was thinking.
<xnox> cyphermox: they are existing, in the archive, and i think they were previously released via train already.
<cjwatson> and that patch was long ago.
<chiluk> yeah..
<cyphermox> xnox: well if the issue was with versions you should get an error earlier
<xnox> cyphermox: right.... hm =) i'm clueless, all I know is how to operate dput =)
<cyphermox> unless it's trying to make the exact same version but with a different source tarball, though that shouldn't happen given that we datestamp the version anyway
<cyphermox> xnox: let me re-run this step by step
<chiluk> cjwatson  was afraid we were missing a define for the efi build maybe
<cyphermox> if it really doesn't work I'll frankenstein the ci... dah
<cyphermox> no longer have access to the jenkins box
<cjwatson> chiluk: no
<cyphermox> xnox: let's just try to rerun, see how it goes, and if it still fails we'll need ev or olli or jfunk to help for now
<cjwatson> chiluk: grub_serial_ns8250_add_port could fail for reasons other than the parsing, which would produce the same error
<chiluk> fyi, this isn't official business
<cjwatson> chiluk: I think Vladimir has misdiagnosed this
<chiluk> k thanks
<cjwatson> chiluk: also grub_serial_ns8250_add_port doesn't seem likely to work on class 3 (or whatever the terminology is) EFI devices
<cjwatson> chiluk: you'd need something involving the efiserial driver
<chiluk> any suggestions on how to go about debugging grub?
<cjwatson> chiluk: which seems to generate efiXXX style port names
<chiluk> I'm not familiar with that style
<chiluk> are you suggesting trying serial --port=efif0e0?
<chiluk> cjwatson or something similar
<cjwatson> I think they're sequential rather than a big hex number
<cjwatson> efi0, efi1, etc.
<chiluk> cool give me a sec to check.
<cjwatson> don't offhand see how to get a list of registered ports
<chiluk> I'm out of my element here...
<cjwatson> oh, the output of "terminal_input" without args should include them with "serial_" prefixed
<infinity> robert_ancell: That did the trick, cheers.
<robert_ancell> infinity, thank you. I learned some more obscure build system knowledge today :)
<chiluk> cjwatson terminal_input yields "serial_* serial at_keyboard"
<cjwatson> chiluk: it is also possible, I suppose, that you have a zombie GRUB image lying around from ages back, so double-check the version on the GRUB menu and not just the binary package
<cjwatson> chiluk: maybe your EFI just doesn't probe the serial ports
<chiluk> which is possible
<chiluk> I have a bug open with intel as well.
<cyphermox> xnox: got it now: https://launchpad.net/~ci-train-ppa-service/+archive/landing-011/+packages
<cjwatson> and if it's a bleeding-edge-enough EFI then it may not allow access to the traditional inb/outb style of port-banging
<chiluk> cjwatson, it's showing up as 2.02~beta2-8
<cjwatson> right, good
<xnox> cyphermox: \o/
<cjwatson> chiluk: I don't see any debug messages currently being logged by the relevant code, so you'll probably have to add grub_dprintf ("serial", ...) to various places and then "set debug=serial"
<infinity> It's a NUC, so about as bleeding edge as it can be without being an engineering sample.
<xnox> cyphermox: will test from silo as soon as they are ready, and will ping you about publishing them.
<cjwatson> chiluk: grub-core/term/serial.c grub-core/term/efi/serial.c would be the places to start
<infinity> (I'm not convinced that NUCs aren't pretty much engineering samples, from all the bugs I've heard people complain about)
<cjwatson> probably the latter
<chiluk> ah... efi/serial.c missed that one
<chiluk> infinity, I have mine working pretty darn well./
<cjwatson> you'll probably want to add traces to the loop in grub_efiserial_init
<chiluk> except for this efi issue everything else seems pretty decent.
<chiluk> cjwatson, stupid question... what's best way to print out info without printf?
<infinity> chiluk: Everyone seems to have their pet complaint.  This is yours. :)
<chiluk> infinity, I even have kvm working reliably-ish.
<cjwatson> chiluk: err, I don't quite get the question, grub_dprintf is generally the best way to debug grub
<chiluk> that's the answer I was looking for.
<cjwatson> there's a grub_printf to print things unconditionally
<cjwatson> but you indeed don't have the standard C library
<chiluk> right..
<chiluk> I haven't screwed with things this early in boot before.
<cjwatson> see e.g. grub-core/disk/efi/efidisk.c for an example of using grub_dprintf
<cjwatson> though it's scattered pretty liberally over the codebase
<cjwatson> the first arg to grub_dprintf is something that you might put in "set debug="
<chiluk> cjwatson, cool thanks again... I'll push this a bit.. considering how many of us are investing in nucs, it'd be nice to have these things work reliably... that and it might be nice to test serial on an efi machine just in case this is a larger problem.
<cjwatson> sure, it's possible.  I think it's been confirmed to work at least sometimes :)
<chiluk> for such old-school tech it should work all the time.
<cjwatson> chiluk: serial may be old-school tech, but EFI serial sure isn't.
<cjwatson> The driver only went into 2.02, IIRC
<cjwatson> Oh, no, git says it was in 2.00, just a couple of patches since then
<cjwatson> But even so
<blkperl> cjwatson: alright thanks, good to know its nothing serious :)
<darkxst> something is pulling in the entire Unity world on Ubuntu GNOME :(
<xnox> cyphermox: i have finished testing all packages from silo 11, please upload them into -proposed.
<xnox> cyphermox: all is good.
<cyphermox> xnox: done
<chiluk> hey infinity can I get some upload lovin on https://bugs.launchpad.net/ubuntu/+source/amtterm/+bug/1301692   I notice there are no patch pilots online right now.
<ubottu> Launchpad bug 1301692 in amtterm (Ubuntu) "amtterm errors out with "amtterm: ERROR: redir_data: unknown r->buf 0x29"" [Undecided,In progress]
<chiluk> xnox are you still around and will to upload https://bugs.launchpad.net/ubuntu/+source/amtterm/+bug/1301692
<ubottu> Launchpad bug 1301692 in amtterm (Ubuntu) "amtterm errors out with "amtterm: ERROR: redir_data: unknown r->buf 0x29"" [Undecided,In progress]
<cyphermox> FourDollars: hey, re: your bluetooth patch
<FourDollars> cyphermox: yes
<cyphermox> I'm not convinced it would really fix the crash...
<FourDollars> cyphermox: Err... XD
<cyphermox> I agree with the extra check, but it's freeing the caps list in the device that crashes bluez
<FourDollars> cyphermox: Because it is freed before.
<cyphermox> so that extra check would only guard you from trying the free the device if the device pointer is invalid, not from invalidly freeing the capabilities list if the device pointer is valid but the caps list may not be (as seemed to be the case in your crash)
<cyphermox> so while I'm happy with the patch as it is, I can't confirm it's valid as I have no way to really reproduce this state
<cyphermox> if you tell me you could reproduce the crasher reliably on your hardware and it fixed it, then all good :)
<FourDollars> cyphermox: Before it runs to the crash place, it will run unix_device_removed().
<cyphermox> oh wait a second
<cyphermox> FourDollars: can you easily reproduce this crash? I can't here. I'd really like to see the backtrace for all threads
<FourDollars> cyphermox: Yes, I can easily reproduce this issue.
<FourDollars> cyphermox: I need some time to setup the environment because I am working on many different machines for this issue.
<cyphermox> oh ok
<cyphermox> ah, I see what's happening now
<FourDollars> Do you stiil need the backtrace for all threads?
<FourDollars> cyphermox: ?
<cyphermox> no, I don't
<FourDollars> OK
<cyphermox> I see what you're doing now, fully agree with the patch, I'll upload now for trusty, and then for precise
<FourDollars> Thanks a lot. :D
<dannf> stgraber: fyi, now that udev links w/ libcgmanager0, d-i ftbfs due to a lack of a libcgmanager-udeb
<dannf> hallyn: ^
<dannf> and libnih0 apparently
<infinity> stgraber: Also, upstart needs udebs now because of that (nih and nih-dbus)
<infinity> Which might be a slipper slope...
<stgraber> well, our systemd source now build-depends against libcgmanager-dev because we need logind to talk to cgmanager in some cases. I can't think of a good reason for udev itself to do so though, maybe I can get some sanity into upstream's crazy Makefile to avoid that particular one
<infinity> Disabling cgmanager support in the udev udeb pass might be smarter.
<stgraber> well, udev never does anything with cgroups, so there's no good reason for it to be linked to cgmanager to begin with
<infinity> stgraber: With --as-needed, I wouldn't expect it to be.
<infinity> ./lib/systemd/systemd-udevd
<infinity> 	libcgmanager.so.0 => not found
<infinity> It's definitely udevd itself that's linked to it.
<infinity> stgraber: I'll just add --disable-whatever to the udeb pass and test that.
<stgraber> infinity: right, --disable-cgmanager should do the trick
<stgraber> I'm still pretty confused as to why udev would even use any of that code to begin with, I was under the (apparently wrong) impression that udev was supposed to be kept mostly separate after its merge into systemd...
<infinity> stgraber: It probably statically links libsystemd, because Lennart and Kai.
<infinity> stgraber: And your cgmanager stuff is built into libsystemd, so...
<infinity> Testbuilding now.
<chiluk> hey infinity want to do an upload for https://bugs.launchpad.net/ubuntu/+source/amtterm/+bug/1301692 as well?
<ubottu> Launchpad bug 1301692 in amtterm (Ubuntu) "amtterm errors out with "amtterm: ERROR: redir_data: unknown r->buf 0x29"" [Undecided,In progress]
<infinity> stgraber: http://paste.ubuntu.com/7197140/ Looks like success.
<infinity> stgraber: And in the queue, if you'd like to do the honours.
<stgraber> infinity: looks good, will review in the queue. Thanks for fixing that one!
<chiluk> hey stgraber I see you listed as a patch pilot would you help me with an upload for bug 1301692 ?
<ubottu> bug 1301692 in amtterm (Ubuntu) "amtterm errors out with "amtterm: ERROR: redir_data: unknown r->buf 0x29"" [Undecided,In progress] https://launchpad.net/bugs/1301692
<stgraber> chiluk: it's past midnight here and I'm headed to bed after I'm done reviewing that systemd upload, I'll be happy to take a look tomorrow if you remind me though :)
<chiluk>  sure thing.. I'll harass tomorrow's patch pilot
<dholbach> good morning
<darkxst> hey dholbach
<dholbach> hi darkxst
<darkxst> re bug 1294891, was quite clear on exactly what is need with license texts, I put full text for CC-BY-SA 2 and 3 in both COPYING and debian/copyright
<ubottu> bug 1294891 in Ubuntu "Ubuntu GNOME community wallpapers" [High,Incomplete] https://launchpad.net/bugs/1294891
<darkxst> s/was/wasnt/
<darkxst> is that what you meant?
<caribou> Are SRU for packages in Universe handled differently than for those in main ?
<Laney> Nope
<caribou> Laney: ok,thanks
<mpt> mvo_!!!
<mvo_> hey mpt
 * janimo hugs mvo
 * mvo_ hugs janimo
<seb128> bdmurray, mvo_: would have of you have some spare cycles to look at https://bugs.launchpad.net/ubuntu/+source/ubuntu-release-upgrader/+bug/1294124 ?
<ubottu> Launchpad bug 1294124 in ubuntu-release-upgrader (Ubuntu) "do-release-upgrade crashed with AssertionError in confirmChanges()" [Medium,Confirmed]
<seb128> it's ranked 3rd on the daily e.u.c trusty report with 30 reports in a day
<jibel> seb128, the crash signature is not really accurate for this bug because from the duplicates the root cause of the failure is "MarkUpgrade() called on a non-upgrable pkg: 'brasero'"
<seb128> jibel, what bug?
<jibel> seb128, 1294124
<seb128> jibel, you mean it doesn't match https://errors.ubuntu.com/problem/3b1ff63e2f241b3ef46a2ed80e2ae253370b8721 ?
<seb128> jibel, I'm not sure what you are getting at? it's not a bug? it's mistriaged?
<jibel> seb128, I mean this signature matches any upgrade that fails because a package is non-upgradable
<jibel> in that case 'brasero'
<seb128> where do you see that?
<seb128> jibel, I'm looking at https://launchpadlibrarian.net/169922204/Traceback.txt ... are we looking at the same thing?
<jibel> seb128, from apt.log
<seb128> I mean the signature
<seb128> where do you see it
<jibel> https://launchpadlibrarian.net/169922201/DuplicateSignature.txt
<seb128> I don't see anything on https://errors.ubuntu.com/problem/3b1ff63e2f241b3ef46a2ed80e2ae253370b8721
<seb128> jibel, that has the python bt?
<seb128> jibel, anyway, I'm unsure what you are getting at, even if some packages are not-upgradable that should hit an assert and is a bug still no?
<seb128> shouldn't*
<jibel> seb128, right, this is a bug. My point is that the problem on errors.u.c aggregates all the failures caused by non-upgradable packages.
<seb128> jibel, let's fix the assert and make it report the actual errors then :p
<seb128> jibel, do you know why those packages (e.g brasero) are non-upgradable?
<jibel> seb128, not yet, I'll try to reproduce it.
<seb128> jibel, thanks
 * seb128 shakes fist at ted
<seb128> my desktop greets me at each login with an apport prompt about click :/
<pitti> seb128: is that still from those few days where a new indicator version pulled in all of click?
<seb128> pitti, no, I'm having click installed because we use it in the touch settings and I'm testing those on my desktop
<seb128> things like click list work there
<seb128> even if the clicks can't be run from unity7
<Laney> https://bugs.launchpad.net/ubuntu/+source/url-dispatcher/+bug/1290997
<ubottu> Launchpad bug 1290997 in url-dispatcher (Ubuntu) "click crashed with gi._glib.GError in run(): Child process exited with code 139" [High,Triaged]
<seb128> right
<seb128> which is why I shake my first at ted :p
<seb128> (it also tops e.u.c since yesterday)
<pitti> slangasek: as we have logind now taking care of the power button even if nobody is logged in, I think it's time to rip this functionality out of acpid; it leads to bugs like bug 1201180
<ubottu> bug 1201180 in kde-workspace (Ubuntu) "Pressing power button turns off the PC ignoring the presence of another session manager" [Medium,Triaged] https://launchpad.net/bugs/1201180
<pitti> slangasek: do you agree, or am I missing something here?
<xnox> pitti: yes, please!
<xnox> pitti: is logind also present on the servers and taking care of login buttons there?
<xnox> pitti: atleast acpid shouldn't do anything if there is logind present.
<pitti> xnox: yes, that seems like the easiest solution then (pidof systemd-logind)
<pitti> xnox: I'm not sure whether it's running on all servers, but it might not be
<xnox> pitti: it can and does create sessions for serial/ssh users etc. but i'm not sure how far down libpam-systemd & logind are seeded.
<pitti> I made a comment on the bug, I'll look into that
 * Laney finds some systemd-cgmanagery bugs
<xnox> sergiusens: hey! Could you please remove ubuntuone click webapp from http://people.canonical.com/~ubuntu-archive/click_packages/click_list ? we no longer want it pre-installed, as u1 file services will be shutdown.
<sergiusens> xnox: sure; it's a mostly useless web app anyways :-P
<sergiusens> xnox: is it already unpublished by dbarth?
<ogra_> yeah, it never had any mobile CSS either
<xnox> sergiusens: yes, he unpublished it in the store.
<dbarth> sergiusens: yup unpublished; see if you need to let your script now
<dbarth> know
<sergiusens> xnox: dbarth done
<dbarth> cool thanks
<sergiusens> next sync should do the right thing at 11 after the clock
<pitti> xnox: FTR, logind isn't on our server images (meh.. we keep dragging along acpid/acpi-support)
<pitti> xnox: so instead of completely ripping it out, let's go for "check for logind" for trusty, yes
<pitti> acpi-support will survive us all..
<xnox> pitti: it will do for another 5 years =)
<ypwong> seb128, hi!
<ypwong> seb128, could you or someone in your team take a look at bug 1299855? We need the feature to set the default search engine in ubuntu kylin
<ubottu> bug 1299855 in ubuntu-defaults-builder (Ubuntu) "setting browser.search.defaultenginename in distribution.ini does not have effect" [High,Confirmed] https://launchpad.net/bugs/1299855
<seb128> ypwong, hey, sure, adding to our list
<seb128> happyaron, ^ would you have a free slots to look at that one?
<infinity> pitti: If I'm using run-adt-test, what's the best way to upgrade my base image so it's not updated over and over on every run?
<pitti> infinity: just re-run "prepare-testbed amd64" is the easiest
<infinity> pitti: Won't that download a fresh cloud image all over?
<pitti> infinity: with the prepare-testbed VMs it's not trivial to dist-upgrade them; you can do it, though
<pitti> infinity: yes, it will; but they aren't particularly big
<infinity> Bigger than a dist-upgrade.:)
<infinity> But will keep that in mind the next time it annoys me.
<pitti> infinity: so run the image with -hda pristine-trusty-amd64-20140324_084956.img and -hdb pristine-trusty-amd64-20140324_084956.img.seed
<pitti> with whichever images you have
<pitti> and then log in as ubuntu/ubuntu and dist-upgrade
<infinity> pitti: Also, when can get right of the twisty maze of jenkins-is-the-worst-video-game-ever and have results I can actually navigate, like Debian now does? ;)
<infinity> pitti: Aaaand a feature request, being able to stuff mirror and apt_proxy info into the image via arguments to prepare-testbed would make me happy.
<pitti> infinity: it's in the pipeline :) https://wiki.debian.org/MartinPitt/DistributedDebCI
<pitti> infinity: that already exists in autopkgtest
<infinity> pitti: Which already exists?  Mirror/proxy selection?
<pitti> infinity: I don't want to waste too much effort on lp:auto-package-testing and jenkins any more, given that I really want both of them to go away next cycle
<pitti> adt-buildvm-ubuntu-cloud --help
<infinity> pitti: Oh, should I be using something other than lp:auto-package-testing?  I was just following a random wiki.
<pitti>   -m URL, --mirror URL  Use this mirror for apt (default:
<pitti>                         http://archive.ubuntu.com/ubuntu)
<pitti>   -p URL, --proxy URL   Use a proxy for apt
<pitti> and adt-build-lxc just automagically uses whichever apt proxy you have on the host
<pitti> that doesn't have a --mirror yet, please file a bug if you need that
<pitti> infinity: you can use the new stuff; lp:a-p-t is still what we are running in production
<pitti> infinity: but locally I don't use it any more, I just run adt-run directly with schroot, LXC, or QEMU (depending on what's appropriate)
<pitti> infinity: I spent some time to write /usr/share/doc/autopkgtest/README.running-tests.gz, I hope that's a good enough intro how to run schroot/lxc/qemu and how to build testbeds
<infinity> pitti: Are there docs for idiots on how to do it that way?  I've just been following the two simple steps on http://packaging.ubuntu.com/html/auto-pkg-test.html#executing-the-test for prepare/run-adt
<pitti> infinity: if you have a test which doesn't open network ports or fiddles with the kernel, then using an existing schroot is certainly by far the easiest method
<infinity> pitti: Ahh, cool.  Alright, I'll look at that at some point.
<infinity> pitti: And yeah, schroots would be fine for most things (and how Debian seems to be running their tests?), but I'd prefer to match production when I can.  Ish.
<pitti> infinity: read that doc and please tell me if anything is unclear; I'm really eager that this is a good intro document, as ohterwise I'll keep explaining this on IRC forever :)
<infinity> pitti: Pointing out the doc on the above page might be helpful. ;)
<pitti> infinity: don't worry; if it works in a minimal schroot it's very likely also going to work in the fat cloud images
<pitti> infinity: yes, I'm going to do that once we actually switch over production
<pitti> infinity: I think for now the official answer is still "prepare-testbed every day" and "run-adt-test"
<pitti> it's just about as expensive as it can get, but it's easy
<bdmurray> pitti: have you had a change to look at my apport-retrace package versions branch?
<stgraber> hallyn: any idea what could be causing bug 1301882? from the backtrace it looks like we're stuck in ping...
<ubottu> bug 1301882 in systemd (Ubuntu) "systemd-logind can get hung in cg_enumerate_tasks" [Undecided,New] https://launchpad.net/bugs/1301882
<bdmurray> mvo_: Hi, would you mind having a look at bug 1300465? Its not too important but curious.
<ubottu> bug 1300465 in python-apt (Ubuntu) "description dialog is empty" [High,Triaged] https://launchpad.net/bugs/1300465
<mvo_> sure
<mvo_> bdmurray: I "stole" #1286161 from you, hope you don't mind
<bdmurray> mvo_: heh, not at all!
<infinity> jcastro: He's mine, back off.
<infinity> Erm, ECHAN.
<stgraber> hallyn: one idea would be to switch to using a single connection to cgmanager and keep it open to avoid all those connect/ping/disconnect but I'm not sure this would have fixed that particular hang. (The reason for all the connect/disconnect is that logind spends most of its time idle and I wanted to be as robust as possible in case something goes wrong with cgmanager and the reconnect code doesn't work)
<mvo_> what the process to request a FFe for apt 1.0 for trusty? http://people.canonical.com/~mvo/apt_0.9.15.4ubuntu2_to_1.0ubuntu1.debdiff <- its a bit long, mostly cppchecker fixes
<stgraber> hallyn: an alternative would be to have connect fail after a short timeout if ping doesn't respond, not sure how easy that'd be.
<bdmurray> mvo_: what might go wrong with the fix for bug 1286161?
<ubottu> bug 1286161 in ubuntu-release-upgrader (Ubuntu Trusty) "13.10 -> 14.04 upgrade failed: initramfs failed to ugprade, udev is not configured yet" [High,In progress] https://launchpad.net/bugs/1286161
<pitti> bdmurray: sorry, not this week; the sprint takes pretty much all brain and time, I'm afraid
<infinity> mvo_: File a but against the apt package titled "[FFe] update apt to shiny version with more cows" , describe the how and why in the bug, and subscribe ubuntu-release.
<infinity> mvo_: And then convince me directly that it's low impact, and why. ;)
<hallyn> stgraber: I'll take a look
<bdmurray> pitti: ah, didn't know you were sprinting
<mvo_> bdmurray: on the phone right now, will reply in a bit
<hallyn> stgraber: do you know if cgmanager had crashed/restarted?
<stgraber> hallyn: don't know
<stgraber> Laney: can you post your /var/log/upstart/cgmanager.log in the bug?
<hallyn> ok lemme set up a victim vm to torment
<Laney> stgraber: oh yes, sorry, which one?
<Laney> or either I guess
<Laney> btw I got it back into the borked state accidentally if you want some data out of it :-)
<hallyn> stgraber: i can't imagine why it would've happened otherwise.  especialy on ping
<hallyn> Laney: you had no containers running right?
<Laney> hallyn: I almost certainly did, I usually do
<Laney> and certainly do now
<hallyn> Laney: oh but that shoudl be fine, i should've asked, the ping hang didn't happen in a container?
<Laney> Everything I was doing with loginctl was outside
<Laney> hallyn: log is attached
<hallyn> thanks.
<mvo_> bdmurray: so what might go wrong - well, the ording might break in a different way. there is no indicataion that this is the case and it definitely fixes the bug in the bugreport
<mvo_> thanks infinity, I will do this
<bdmurray> mvo_: okay, jibel you could do some automated testing with that new version of apt right?
<hallyn> stgraber: logind doesn't do any threading right?
<mvo_> bdmurray: yeah, that would be great. I can do some testing on my workstation too. I think its pretty safe (the diff) but we all know that shortly before a release stuff may break :)
<jibel> bdmurray, sure, if you provide a deb, I can run the tests with this version.
<bdmurray> mvo_: why don't you upload it to the saucy-proposed queue and I'll approve it later today
<mvo_> bdmurray: sounds good
<bdmurray> pitti: the powerd debug symbols seem to be out of date
<slangasek> pitti: ah yes, if logind is now handling the power button outside of login sessions (hurray), we should indeed drop it from acpid (double-hurray!)
<pitti> slangasek: right, thanks; as xnox pointed out, it's not currently on server images, so for now I just added the "pidof systemd-logind" check
<pitti> slangasek: this acpid{d,support} stuff is annoyingly sticky :(
<slangasek> pitti: ah, doh
<pitti> bdmurray: checking where it was built and trying to rescue
<bdmurray> pitti: thanks
<pitti> bdmurray: hm, the ddebs are nowhere on kishi06/toyol/lamiak, so there's nothing to rescue I'm afraid
<psusi> cjwatson: I noticed that it looks like you fixed bug #1065281 some time ago, but it still has one open task against ubiquity ( not release specific ).  Has it really not been fixed in trusty, or does it not affect anything above precise and so the task should be removed?
<ubottu> bug 1065281 in partman-efi (Ubuntu Quantal) "Installer crashed when trying to partition 4k/4k sector hard disks" [High,Triaged] https://launchpad.net/bugs/1065281
<pitti> bdmurray: "powerd has no unstripped objects, ignoring"
<pitti> bdmurray: so I think powerd is built without -g
<cjwatson> psusi: ah, see, this is why I hate having ubiquity tasks on bugs that just amount to incorporating new included sources
<psusi> yep
<cjwatson> psusi: closing, thanks
<pitti> bdmurray: so the build log doesn't have any -On option or -g
<pitti> bdmurray: that's a "cmake does not respect $CFLAGS" kind of bug, I'm afraid
<psusi> btw, I've been closing a lot of bugs lately that are installer crashes due to booting the installer in efi mode, and trying to install on a disk already set up for bios mode.. I think we really, really need to fix partman-xxx to stop and tell the user they need to reboot in bios mode instead of getting to grub-install failing
<psusi> sound like a good idea, and if so, what is the partman-xxx to file the bug against?  partman-efi, or partman-auto?
<stgraber> hallyn: it's not extremely clear due to the way all of systemd's code is mixed together... I don't believe logind itself uses threads but I may be wrong...
<psusi> or better yet, switch to using grub-pc instead of grub-efi
<cjwatson> psusi: maybe partman-efi.  not sure we *can* switch to grub-pc at that point, it may not necessarily be able to install
<cjwatson> psusi: certainly not partman-auto
<ogra_> stgraber, we are seeing weird issues with the boot on phones (not sure you read the ubuntu-phone ML lately), the system locks up hard after run-init since nothing changed in mountall and cgmanager is the first additional thing to start there, do you know of any issues cgmanager could cause ?
<psusi> cjwatson: why wouldn't it be able to install?
<ogra_> stgraber, (it only happens ever 20th to 60th boot, which kills the devices in the lab)
<ogra_> (i noticed plenty of mesaages where gcmanager repawns a few times during a normal boot)
<stgraber> ogra_: and I don't suppose adb is up by the time it hangs?
<psusi> isn't partman-auto where you pick then guided - install along side option?  I would think that's where you would want to look at the current disk layout and decide if you should force grub-pc instead of grub-efi
<stgraber> ogra_: when cgmanager respawns, do you get a crash entry in /var/crash by any chance?
<ogra_> stgraber, nope, no adb across run-init ... we have an emergency shell that kicks off wqhen the container cant start and one on panic in the initrd
<hallyn> stgraber: that's bad if it does.  then we need to fix that nih/dbus threading issue
<Laney> hallyn: It doesn't AFAICS
<hallyn> ah good, my victim is done installing.  now to torture it
<hallyn> ok
<ogra_> stgraber, i'll check, i'm not near the phone atm
<dholbach> xnox, Paolo just pinged me about https://bugs.launchpad.net/ubuntu/+source/live-build/+bug/1300400 again - he said they want to get out an Italian CD for 14.04 but would need this fixed - if you don't have time, do you know anyone else who could take a look at this?
<ubottu> Launchpad bug 1300400 in live-build (Ubuntu) "Please add saucy and trusty strings to releases.sh" [Undecided,Confirmed]
<stgraber> ogra_: it still wouldn't explain why the phone doesn't boot though. Even if cgmanager fails to start or crashes, the worst case scenario should be that the container won't start.
<stgraber> ogra_: but the rest of the system doesn't depend on cgmanager and so everything else should start, including adb
<xnox> dholbach: i'll sponsor that patch now.
<xnox> dholbach: we can work on a generic solution later.
<dholbach> xnox, awesome
<cjwatson> psusi: I'd have to go pick over the UEFI spec with a fine tooth-comb to see if there's anything that e.g. a class 3 device might do that could break grub-pc installation.  Dunno
<cjwatson> psusi: platform-specific stuff like this, other than default partition layouts, doesn't belong in partman-auto
<cjwatson> psusi: (also, you're asking a question and then arguing with the answer ...)
<ogra_> stgraber, unless the android kernel is not safe for something cgmanager tries to do to it
<psusi> well, I mean, if the existing disk is MBR partitioned, then obviously the machine normally boots in bios mode, right?  so screw efi
<stgraber> ogra_: doubtful, all cgmanager does is write to plain text files
<stgraber> ogra_: and is basically a copy/paste of what LXC used to do directly itself before
<cjwatson> psusi: well, probably, yeah
<ogra_> stgraber, ok
<xnox> cjwatson: psusi: it can do either, e.g. on Macs they keep MBR and UEFI in sync thus one can boot using either method. That's more or less how bootcamp works.
<cjwatson> psusi: but you definitely want to do it later than partman-auto because it's completely legitimate for somebody to manually zap the existing partition table and replace it with GPT in order to convert to full-fat UEFI
<psusi> xnox: right.. but the disk is gpt ( hybrid )
<cjwatson> xnox: that's an irrelevant side issue though, as parted will still see that as GPT
<xnox> ok.
<psusi> cjwatson: yes, but isn't partman-auto the place where they decide they are not going to do that, but do a side-by-side install?
<psusi> on the existing pure MBR disk?
<hallyn> stgraber: ok, so i have just installed ubuntu-desktop on trusty vm, but cgmanager and logind are not installed.  ?
<hallyn> shouldn't logind be automaticlaly there?
<cjwatson> psusi: they can perfectly well switch to manual partitioning
<cjwatson> psusi: in fact, to overwrite the existing partition table, I think they may *have* to switch to manual partitioning
<cjwatson> psusi: like I say, partman-auto is just simply the wrong place for this
<psusi> *after* they already chose side by side in partman-auto?
<cjwatson> that has nothing to do with it
<cjwatson> look
<stgraber> hallyn: it should, is that vm up to date?
<cjwatson> consider an existing mbr disk.  user selects manual partitioning, may or may not replace the entire thing with GPT
<psusi> maybe I'm misunderstanding the relationship between the menu and the partman modules... I thought that partman-auto implements the options for either guided or manual partitioning?
<cjwatson> if it's GPT at the commit stage, then we don't complain, otherwise we do
<cjwatson> simple
<cjwatson> partman-auto does not step in at the commit stage
<cjwatson> partman-efi (and others) do, via check.d scripts
<hallyn> stgraber: yup.  what should bring in logind?  (logind is the pkg name right?)
<cjwatson> no, partman-auto does not implement manual partitioning beyond just the single option letting you get into it
<stgraber> hallyn: systemd-services is the package name
<psusi> right, that's what I meant, that's where you make the choice
<cjwatson> but that choice is not sufficient information to decide whether to issue this warning
<cjwatson> the proper place to do it is in a check.d script which happens at commit time
<cjwatson> and those do not belong in partman-auto
<psusi> so if you choose the side-by-side option, then at that point, if the disk is mbr, I would think that would be where we want to set a flag to not bother loading partman-efi, and force grub-pc
<cjwatson> I'm not going to argue this further
<hallyn> stgraber: oh, hm, that's there
<psusi> what warning?  I'm trying to avoid any kind of warning
<cjwatson> not bother loading partman-efi> you misunderstand the architecture
<cjwatson> please stop it
<stgraber> hallyn: it should only bring libcgmanager0 though, not the daemon itself
<cjwatson> you asked a question, I gave you the answer ...
<stgraber> hallyn: so a default desktop install won't have Laney's problem, the hangs are currently restricted to those who have lxc installed
<hallyn> stgraber: oh ok.  and it uses fs if cgmanager is not installed.  got it
<hallyn> ok just making sure what i had was sane, thanks :)
<cjwatson> grub-installer should be the thing that decides which grub platform to install
<cjwatson> if it's necessary to tell the user they can't proceed with their current layout, then that belongs in a check.d script in partman
<cjwatson> if it's possible to avoid such a thing, then partman doesn't need to change at all
<cjwatson> in neither case should partman-auto be touched
<psusi> ok, but we want to change its decision based on the fact that we are doing a side-by-side install on an MBR disk... is that information availible to grub-installer?
<cjwatson> no, there's no need to take that into consideration
<cjwatson> all grub-installer needs to know is the partition label in place when it runs
<cjwatson> which is well after partitioning
<cjwatson> it's not relevant how it got that way
<psusi> ahh... ok... got ya
<cjwatson> and, you can just as well do a side-by-side install in manual partitioning as in partman-auto ...
<cjwatson> it's obviously more effort, but it's entirely doable
<cjwatson> partman-auto is basically just recipes and code for applying them, not anything specifically about the implementation of the various filesystems and labels and such
<psusi> ok, I was thinking we only wanted to do this for the guided install option, but yea, I suppose it also makes sense in manual
<cjwatson> I try very hard to keep this sort of thing out of partman-auto because the inevitable result is a bug ten seconds later complaining that the same thing doesn't work in manual partitioning :-)
<cjwatson> It's a lot easier to be hard-nosed about the architecture from the start
<psusi> what triggers partman-efi to be loaded?
<psusi> so partman-efi's check should throw an error if you are using gpt but don't have an efi system partition ( or maybe bios_grub? ), but if you are using mbr, let it go and have grub-installer switch to grub-pc if using mbr?
<psusi> or perhaps issue a warning that the resulting system may not boot.. hrm...
<cjwatson> partman-efi is Priority: standard, so anna loads it by default if it's available.
<psusi> probably want to suppress that warning though if they picked guided install beside
<cjwatson> Yeah, partman-efi should probably only care about systems with GPT.
<cjwatson> I don't think guided install or not should be relevant.  Yes, it's a bug if guided install sets up something wrong, but we still want to know about it early rather than failing in a confused heap that's hell to debug later.
<cjwatson> EFI System Partition / bios_grub> I feel that partman-efi should probably allow either, and grub-installer should use that to decide which platform to install
<psusi> I think the warning makes perfectly good sense if they did a manual setup, but I'd rather not give the user a scary warning if they are doing a side by side install with an existing setup that obviously boots in bios mode just fine
<cjwatson> Though partman-efi's job is really specifically about the EFI System Partition, so maybe this actually belongs somewhere like partman-partitioning
<cjwatson> (which already handles stuff about bios_grub)
<cjwatson> We need to make sure that the logic is such that the warning doesn't appear in such a side-by-side case, and that we install a boot loader which will cope
<psusi> right. that's what I'm saying
<mvo_> bdmurray: so for #1300465 - you see pkg.candidate.raw_description, correct?
<cjwatson> But detecting guided partitioning and suppressing the warning in that case is the wrong answer
<cjwatson> This is a safety check - it's better not to proceed than to generate something unbootable due to a logic bug in partitioning
<mvo_> bdmurray: on what system did you reproduced this? anything I could try to reproduce this?
<psusi> hrm... I suppose I was using the guided partitioning as a surrogate for detecting existing operating systems later
<cjwatson> And it's furthermore better to at least give users the chance to fix it, rather than have the whole system just be uninstallable
<cjwatson> (which a check.d warning will naturally do - they can fall back to manual partitioning)
<psusi> right, but I'd like to avoid even a warning if ther's another OS on the disk that obviously is booting just fine in bios mdoe
<cjwatson> Well, we seem to be largely in agreement that we only need to generate a warning if you have a GPT label without any boot-type partition
<cjwatson> So that shouldn't be an issue
<psusi> right
<bdmurray> mvo_: yes, I see raw_description but description is empty
<cjwatson> We do need to check the final state though - with BIOS+GPT you could break that existing OS by the changes that you make in the partitioner (not guided, presumably, but you could wipe the bios_grub partition)
<cjwatson> All I'm saying is that the way we avoid issuing warnings with guided partitioning is by not doing wrong things in guided partitioning :-)
<cjwatson> (Which I think is already the case, as far as this matter goes)
<cjwatson> Side-by-side won't touch the boot partition (of either type), and using the whole disk will set up a new one
<cjwatson> partman-auto only has to be aware of the platform to the extent of setting up the right boot-type partition for it, and knowing how to reuse one that already exists
<hallyn> all right reproduced it
<cjwatson> All of that should be in place
<bdmurray> mvo_: weird, all of those are empty for me
<cjwatson> recipes/atomic is used on BIOS, and has "1 1 1 free $iflabel{ gpt } $reusemethod{ } method{ biosgrub } ." (i.e. "if GPT, reuse an existing bios_grub partition if present, otherwise make a new one")
<psusi> so should the check for bios_grub || esp be in partman-efi, partman-partitioning, or one in each?
<mvo_> bdmurray: could you add some debug code into /usr/lib/python2.7/dist-packages/apt/package.py in @property descripton(self)? (around line 330) ?
<cjwatson> recipes-amd64-efi/atomic is used on UEFI, and has "$iflabel{ gpt } $reusemethod{ } method{ efi } format{ } ." (i.e. "if GPT, reuse an existing ESP if present, otherwise make a new one")
<mvo_> bdmurray: to see if that fails maybe? anything special about this system? or is it a "normal" ubuntu install? (special as in different languages or something)
<cjwatson> psusi: Hm, partman-partitioning/check.d/biosgrub *already* has code that does exactly this
<cjwatson> # Is there at least one EFI System Partition or BIOS Boot Partition, as
<cjwatson> # appropriate?
<cjwatson> Worst case it has some slight bug and needs to be fixed, but we don't need to write that code again
<mvo_> bdmurray: do you have any output from "ls /var/lib/apt/lists/*Transla*"
<psusi> ohh?  hrm... it may not be working then
<bdmurray> mvo_: it happens on a virtual machine too
<mvo_> bdmurray: I suspect for some reasons the "translations" are not downloaded for you (which means that you don't get the long descriptions)
<mvo_> bdmurray: the Package file only contains the short summary these days
<cjwatson> psusi: should be visible in the partman log
<psusi> I'll play around with it
<cjwatson> under check.d/08biosgrub or something like that
<mvo_> bdmurray: but this does not make that much sense if you have the full description in the pkg.raw_description :/
<bdmurray> mvo_: yeah, that seems to be it. ls: cannot access /var/lib/apt/lists/*Transla*: No such file or directory
<mvo_> bdmurray: aha! so the question is why you don't get translations :)
<mvo_> bdmurray: I assume you never actively disabled them? what do you see with: $ apt-config dump|grep Languages
<cjwatson> psusi: I'd be happy to look through logs of an installation that should have generated such a warning and didn't, if you have one to hand
<cjwatson> (i.e. manual GPT partitioning and no ESP or bios_grub partition as appropriate)
<bdmurray> mvo_: its my mirror, sorry
<psusi> cjwatson: I'll try to reproduce it... unless this was a relatively recent fix?  I just know I have seen a number of bugs where people didn't have the bios_grub partition so grub-install failed
<mvo_> bdmurray: no problem
<mvo_> bdmurray: good to know whats causing it :)
<cjwatson> psusi: partman-partitioning 83ubuntu2 in precise
<cjwatson> (before release)
<hallyn> yeah the EMFILE doesn'tlook like a kernel issue - bc it does have a buttlaod of files listed in select
<hallyn> and /proc/pid/fd shows 1024 open files
<mvo_> infinity: https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1302033 fwiw, but looking over the changelog maybe its better if I just cherry pick stuff
<ubottu> Launchpad bug 1302033 in apt (Ubuntu) "[FFe] apt 1.0" [Undecided,New]
<infinity> mvo_: I like the idea of shipping the new shiny in trusty, but yeah, it might be too late to properly test all those changes.  I'll go through the diff after I've slept and see just how crazy it really is.
<infinity> mvo_: The build-profiles change is probably trivial and auditable, and I'd like it in, for instance.
<mvo_> infinity: mostly long, but has some mildly scary bits
<mvo_> infinity: I'm also a bit torn between shinny and conservative here :)
<infinity> mvo_: I'll try to get a definitive answer to you soon enough that you can start cherry-picking things you really want if it's a "no".
 * mvo_ goes and gets some dinner first
 * infinity wonders if it's too late to ship Packages.xz for trusty, or if we can get that through and tested before release day.
<infinity> hallyn: Did we give up on qemu 2.0, or is that still in testing?
<bdmurray> mvo_: is bug 1286161 fixed in trusty apt already?
<ubottu> bug 1286161 in ubuntu-release-upgrader (Ubuntu Trusty) "13.10 -> 14.04 upgrade failed: initramfs failed to ugprade, udev is not configured yet" [High,In progress] https://launchpad.net/bugs/1286161
<stgraber> hallyn: does it look like a cgmanager bug or did I mess up something in logind?
<hallyn> infinity: absolutely did not give up on it.  upstream hasn't released 2.0 yet though,
<hallyn> infinity: so my plan on monday, if it is not released, is to push based on v2.0.0-rc0 + diffpatch
<hallyn> stgraber: well it's possible that logind is keeping open it's files and so cgmanager never closes them...  not sure yet
<infinity> hallyn: Well, we're cutting it close.  If you plan to push 2.0ish, and it's well-tested, we should do that sooner, rather than later, and update to a later rc/git/final as we can.
<hallyn> stgraber: tbh since the testsuite doesn't do this it must be somethign logind is doing, but cgmanager should defend itself against it
<stgraber> hallyn: ok, so what does it look like, missing disconnect in some case?
<hallyn> infinity: the 2.0 has been tested quite a bit out of ppa:ubuntu-virt/candidate fwiw, so it wont' be going into the archive green
<hallyn> stgraber: yeah
<infinity> hallyn: Right, it should still be ASAP is all I'm saying. :)
<hallyn> stgraber: my guess would be the fds we pass in
<hallyn> no wait, you're not doing scm anywhere right?
<hallyn> infinity: ok, well i can push whenever.  i just pushed a new pkg to ppa.
<hallyn> infinity: now what i have now is based on a git snapshot tarball.  is that ok, or is it better ot use the qemu v2.0.0-rc0 snapshot + a huge diff?
<hallyn> (I prefer the former but i have a feeling it's not as 'correct')
<stgraber> hallyn: nope, not doing a single scm call
<hallyn> infinity: also since the debian qemu maintainer prefers to have qemu-ssytem-aarch64 be rolled into qemu-system-arm, i figure we should do that now before release
<hallyn> infinity: any objections to that?  (you've seen the pkg)
<stgraber> hallyn: I also just re-checked the code and I always call close...
<infinity> hallyn: Err, which Debian maintainer prefers that?  mjt or vagrant?
<hallyn> mt
<hallyn> mjt
<hallyn> stgraber: well running the testsuite 10 times doesn't leave a single extra open fd...
<infinity> hallyn: aarch64 and arm really aren't the same platform at all, I feel like perhaps he's missing that.
<hallyn> infinity: his feeling is if you can run armhf binaries on aarch64, then it's the same situation as x86/x86_64
<infinity> hallyn: You can't always.
<hallyn> yup we've been over that
<hallyn> anyway i can go either way,
<infinity> hallyn: aarch64 doesn't require an ARM execution unit, it's an optional bolt-on.
<hallyn> but if debian will merge them and we don't do it before 14.04 release, then we have to keep a metapackage until 16.10
<infinity> hallyn: But meh, I don't much care either.  i386/amd64 are in x86, powerpc/ppc64 are in ppc, I don't mind if arm/aarch64 follow suit, even if it's less technically correct.
<infinity> hallyn: So, if mjt won't move on the topic, bundle 'em up.
<infinity> hallyn: As to the tarball, I don't care.  There's nothing inherently more or less correct about one method versus the other, so long as you have a trust path of some sort to the original code.
<hallyn> infinity: if you wanna go make the case in oftc#debian-qemu that it's less technically correct, maybe you can suade him :)  vorlon and i couldnt
<hallyn> cool
<infinity> hallyn: So, signed tags in the git case, or signed tarballs in the orig case.
<hallyn> ok i'll push that today, with or without the merged arm
<hallyn> hm.  signed tags?
<infinity> hallyn: I'm not going to bother arguing the point, if both you and vorlon tried.  Just merge. :P
<hallyn> meaning there needs to be a tag by upstream?
<hallyn> or just that the last commit id should show up in the version?
<infinity> hallyn: Well, or signed commits.  This isn't a "need", per se, just that, well, how else do you know you're not serving me some MITMed git repo of doom? :)
<xnox> ls
<hallyn> infinity: still missing the point <duncecap> - how to sign the commit?  right now i have qemu_2.0~git-20140403.de03c31.orig.tar.gz
<hallyn> where de03c31 is current git HEAD
<infinity> hallyn: As in was the commit at the head of your branch signed by anyone?
<hallyn> signed-off-by, yes
<infinity> hallyn: And does git log --show-signature show that it was PGP signed?
<infinity> hallyn: (signed-off != signed)
<hallyn> nope
<infinity> hallyn: Anyhow, like I said, this isn't some hard requirement, it's just the sanest way to an auditable trust path to someone who says the repo is sane.
<infinity> There are tons of snapshots in the archive that aren't signed. :P
<hallyn> the v2.0.0-rc0 tag isn't signed either actually, so i'll go with the snapshot :)
<hallyn> thanks
<hallyn> oh this'll be fun.   kvm: malloc(): memory corruption: 0x00007f49cc8c3120   (qemu 1.0 on trusty kernel...  probably my own fault)
<stgraber> Laney: so I believe bug 1301846 shows an actual bug in logind which is usually avoided because logind would just make an invalid fs path and return -1, instead the new code sends that to normalize_controller which contains the assert. I have a fix for this now, doing a test build and will upload after lunch.
<ubottu> bug 1301846 in systemd (Ubuntu) "loginctl crashed with SIGABRT" [Medium,New] https://launchpad.net/bugs/1301846
<hallyn> stgraber: oh, how ar eyou opening your dbus connections?  bc if you don't open them as private then they won't really be closed
<Laney> stgraber: Yeah, I saw it comes all the way from the top but didn't check what logind does itself to avoid passing that in
<hallyn> stgraber: yeah i think this might be the problem,
<hallyn> stgraber: in lxc, we do          connection = dbus_connection_open_private(CGMANAGER_DBUS_SOCK, &dbus_error);
<hallyn> i guess logind is running as a part of a long-running lightdm (?) process.  since it never exits it never closes any of the connections
<hallyn> lemme try my hand at a patch...
<hallyn> stgraber: so i'd try something like http://paste.ubuntu.com/7199494/
<hallyn> lessee if it builds over yonder,
<hallyn> of course if that works, the question remains how cgmanager should defend itself against that
<hallyn> hrmph.  that didn't suffice
<hallyn> d'oh, i see why
<hallyn> let's try http://paste.ubuntu.com/7199648/
<bdmurray> slangasek: looking at bug 1090196 which continues to receive duplicates (see my last comment on it), do you have any ideas what we could do to improve the situation?
<ubottu> bug 1090196 in ndiswrapper (Ubuntu) "ndiswrapper-dkms 1.57-1ubuntu1: ndiswrapper kernel module failed to build [Cannot find kernel build files in ... Please give the path to kernel build directory with the KBUILD=<path> argument to make]" [High,Fix released] https://launchpad.net/bugs/1090196
<slangasek> bdmurray: unseed ndiswrapper as obsolete?
<bdmurray> slangasek: on precise?
<slangasek> oh, probably not so much there :)
<slangasek> bdmurray: if this was fixed in dkms later, should we maybe backport that fix onto precise?  Or do we know why users are winding up with the image installed but not the headers?
<hallyn> stgraber: : http://paste.ubuntu.com/7199648/ seems to work
<hallyn> smoser: jcastro: btw that also should fix the problem you had yesterday afternoon i recon' (at least for a bit)
<bdmurray> I was guessing that people just read some web page that reads 'apt-get install linux-image-generic-lts-saucy'.
<jcastro> hallyn, I am free now if you want to take a look
<slangasek> bdmurray: why would any page say that?  we don't recommend that users install enablement kernels on top of already-installed, already-working systems
<hallyn> jcastro: can you just ps -ef | grep cgmanager to get its pid, then look at /proc/$pid/fd ?
<hallyn> i assume you'll see 1024 fds there
<slangasek> bdmurray: oh, because there's an askubuntu answer for this question - so it's all jcastro's fault!
<hallyn> stgraber: ^ should I push with that fix?
<hallyn> hm, /me back in 3 mins
<smoser> hallyn, possible.
<smoser> $ sudo ls /proc/267/fd | wc -l
<smoser> 208
<smoser> that is what was there now.
<smoser> but it isn't acting up now.
<bdmurray> slangasek: most of what I'm finding seems to recommend linux-generic-lts-* though
<jcastro> yeah I just did a string search and the lts-* is the one people are recommending
<hallyn> smoser: log out and in a few times
<bdmurray> jcastro: with linux-generic or linux-image-generic though?
<jcastro> I as searching for linux-image-generic
<bdmurray> jcastro: and that wouldn't install the linux-headers which is the problem.
<jcastro> "sudo apt-get install linux-headers-generic linux-image-generic" seems to be common
<jcastro> but I can do a doublecheck
<bdmurray> jcastro: okay, if its both that's good
<slangasek> jcastro: edit proposed on http://askubuntu.com/questions/257617/how-can-i-upgrade-the-ubuntu-12-04-2-kernel-to-3-5-0-23/257623#257623
<smoser> hallyn, http://paste.ubuntu.com/7199760/
<smoser> that is seriously leaky
<hallyn> stgraber: pushed that change to ubuntu:systemd;  i think you're working on another update so i'll leave it there for you.
<hallyn> smoser: yeah, at least we know the fix for that.  the next q is hwo to have cgmanager protect itself in teh future.  looking at dbus/dbus-timeout.c
<jcastro> bdmurray, protip: any user can do direct queries of the AU database: http://data.stackexchange.com/askubuntu/queries Handy if you want to search for a specific issue, compare it to say, pageviews of the results to investigate if there is a popular question giving out specific incorrect advice
<stgraber> hallyn: back from lunch, looking
<bdmurray> jcastro: oh neat, thanks
<stgraber> hallyn: stacked my change on top of that one, test build running.
<hallyn> cool
<hallyn> stgraber: so i'm thinking two things:
<hallyn> 1. have cgmanager keep a count of open connections per uid, limit those to say 5  (maybe 20 for root)
<hallyn> 2. keep a nih_timer for each open connection, reset it on every method call, and close the connection after the default (25s)
<stgraber> hallyn: 1) would cause some of my machines to fail quite miserably when I start a few hundreds of containers at the same time
<stgraber> hallyn: 2) sounds fine
<hallyn> maybe 1 isn't necessary
<stgraber> hallyn, Laney: just updated to my patched logind here and things appear to be solid, not seeing any fd leaks on login/logout and logind hasn't crashed, uploading
<hallyn> cool
<mvo_> bdmurray: hello, #1286161 is not yet fixed, I can cherry pick that as well or its fixed with the apt 1.0 update
<Noskcaj_> seb128, Thanks for fixing the gnome-icon-themes-extra bug
<seb128> Noskcaj_, yw!
<barry> doko: what's the current state of cross building python packages?  e.g. https://wiki.ubuntu.com/CrossBuilding  under "Known large-scale problems" it says Python multiarch support, but the debian bug that links to is fixed.   however, cross building e.g. autopilot according to the given instructions fails trying to install dependencies (python2.7).  is the bug fixed in debian but not yet in ubuntu?
<doko> barry: which build dependencies?
<barry> doko: http://paste.ubuntu.com/7200212/
<doko> barry: try with --arch-only
<barry> doko: you don't mean `sbuild --arch-only` since sbuild doesn't have that option.  (but --no-arch-all still doesn't help)
<doko> barry, for dpkg-buildpackage, it's -B (and -b if you don't want to touch the diff)
<psusi> cjwatson: well darn... I thought that was goign to be nice and easy: I copied a chunk of code from check.d/biosgrub that detects an efi system partition and if not found, fall back to grub-pc, but it seems that you can't make use of parted in grub-installer?  or should you and I just messed something up somehow?
<barry> doko: hmm... --no-arch-all is supposed to pass -B to dpkg-buildpackage while --arch-all is supposed to pass -b
<barry> doko: should that note about "almost fixed" in the CrossBuilding wiki page be removed?
<doko> does it build for you? if yes, then yes, please remove it
<barry> it doesn't, but i don't know whether that's caused by the bug or not.
<doko> well, try without sbuild
<barry> doko: i'm going to say in the context of that wiki page, it is not fixed.  you can cross build e.g. apt just fine with sbuild
<doko> cjwatson, ^^^  I don't agree with barry here. is this an issue with sbuild?
<barry> similar problem with pure python3 applications
<doko> barry, no. try to cross-build zope.interface. this works
 * barry tries
<doko> sorry, can't help you with sbuild
<barry> yeah no worries, if it's an sbuild problem, i'll file the appropriate bug
<barry> i'm not going to remove that known problem from the wiki page until and unless i can get it working in sbuild, which is what that page is all about
<barry> heh, cross building zope.interface *does* work in an sbuild.  i'll look more closely at autopilot's control file
<cjwatson> psusi: there's existing code that uses libparted, just not the parted binary
<cjwatson> psusi: parted_server isn't running so you can't use partman stuff
<cjwatson> psusi: (please mail me if you're still stuck, we don't have very compatible IRC times)
<psusi> cjwatson: yea, that's what my guess was
<bdmurray> caribou: can you verify bug 1281066?
<ubottu> bug 1281066 in deja-dup (Ubuntu Saucy) "Needs to backport trusty's fix to handle duplicity's lockfile" [Medium,Fix committed] https://launchpad.net/bugs/1281066
<Laney> stgraber: nice one
<bdmurray> Laney: would you mind having a look at bug 1261096? I haven't quite been able to sort out why its restarting whoopsie all the time.
<ubottu> bug 1261096 in whoopsie-preferences (Ubuntu) "whoopsie-prefernces respawns whoopsie in an infinite loop" [High,Confirmed] https://launchpad.net/bugs/1261096
<bdmurray> robru: is there a bug refernce for the unity-chromium-extension fix for "Pass string argument to MediaPlayer.init on to backend."?
<stgraber> Laney: let me know if you get into any more trouble, we want to make sure that stuff is solid before we start shipping cgmanager on all systems whenever we finally land the support in upstart
<kirkland> cjwatson: I encountered https://bugs.launchpad.net/ubuntu/+source/debian-installer/+bug/1302206 today, installing Ubuntu server
<ubottu> Launchpad bug 1302206 in debian-installer (Ubuntu) "wifi configured and working in debian-installer, but not after installation at first boot" [Undecided,New]
<kirkland> cjwatson: I'm curious if this is designed behavior, if this should have worked?
<stgraber> kirkland: I don't believe netcfg knows how to setup a NM wifi connection at least I can't remember seeing code for that last I patched that part of the code
<stgraber> oh, though you said server
<robru> bdmurray, not sure what you're talking about, sorry
<kirkland> stgraber: I was surprised/impressed that when I chose wlan0 in d-i as my primary interface, it scanned my network, found my essid, prompted me for passphrase, connected, drew an ip
<stgraber> I'd vaguely expect it to spit out a valid ifupdown config for wifi but maybe the code is less clever than I remembered
<kirkland> stgraber: I was just disappointed that that working wifi network did not get committed to disk and wasn't operational on reboot
<Laney> bdmurray: ooooooookay, don't know this code though
<stgraber> kirkland: yeah and the code has logic to spit out ifupdown or NM config files for most of that, the NM stuff is pretty recent so I wouldn't be surprised that wifi is missing, I'm vaguely surprised it doesn't generate a working ifupdown config though
<stgraber> kirkland: what's you /etc/network/interfaces like post-install?
<Laney> Maybe you could see what whoopsie-preferences is doing
<kirkland> stgraber: lo only
<robru> bdmurray, oh, if you're referring to http://bazaar.launchpad.net/~webapps/unity-chromium-extension/13.10/revision/234, you'd have to ask justinmcp, he asked me to SRU it.
<bdmurray> robru: yeah, I'm asking about change that was in 2.4.8+13.10.20131108.1-0ubuntu1 with no bug reference
<robru> bdmurray, yeah, I don't know it, sorry
<bdmurray> robru: but you uploaded it to saucy -proposed?
<robru> bdmurray, no? I uploaded it to ppa:ubuntu-unity/sru-staging
<robru> bdmurray, I gotta step out for a bit. I sent an email to justin asking about the bug and cc'd you.
<bdmurray> robru: okay, thanks
<robru> bdmurray, you're welcome
<bdmurray> Sweetshark: is there a bug about an issue with OOXML and libreoffice? I'm looking at the libreoffice upload in the precise-proposed queue.
<Laney> bdmurray: might have fixed it
<Laney> you on amd64?
<bdmurray> Laney: yeah
<Laney> one sec
<Laney> bdmurray: okay, give deb http://people.canonical.com/~laney/package-junkyard ./ a go
<Laney> Let me know if it fixes it for you and I'll upload in the morning
<Laney> going to bed now, see you
<bdmurray> Laney: thanks, that seems like not enough though...
#ubuntu-devel 2014-04-04
<hyperair> dobey: i thought unity-greeter only handles the login screen, and not the screensaver?
<hyperair> s/screensaver/lock screen/
<Unit193> light-locker makes it so the greeter is the lock screen as well.
<bluesabre> unity-greeter is not the lockscreen
<bluesabre> unity now has its own unity-greeter-esque lockscreen
<hyperair> https://bugs.launchpad.net/bugs/1292451 <-- well, dobey reassigned this bug to unity-greeter
<ubottu> Launchpad bug 1292451 in unity-greeter (Ubuntu) "screensaver re-locks itself after unlocking if the configured screen-off timer goes off while screen is locked" [High,Confirmed]
<hyperair> but the bug is clearly to do with the lockscreen, not the login screen.
<hyperair> Unit193: what's this light-locker?
<hyperair> it doesn't show up in dpkg -S for me
<bluesabre> light-locker uses lightdm as the lockscreen
<hyperair> apart from a light-locker-settings.desktop
<hyperair> bluesabre: it doesn't seem to be installed on my machine.
<hyperair> is it a library of some sort?
<bluesabre> so, using light-locker with xubuntu makes lightdm-gtk-greeter the lock screen
<hyperair> i see.
<bluesabre> I'm not sure what the unity lock screen is called
<bluesabre> it might just be a component of unity
<hyperair> how odd, why doesn't unity use light-locker then?
<hyperair> seems like a better way to ensure consistency
<bluesabre> that's up to them :)
<bluesabre> (im a xubuntu dev)
 * hyperair sighs
<hyperair> okay
<Unit193> I thought it was, or was planned to be, but seems it's only seeded on Xubuntu and Lubuntu.
<bluesabre> yeah
<hyperair> i see.
<hallyn> infinity: /win 25
<hallyn> feh
<hallyn> infinity: so i'm intending to push the pkg in ppa:ubuntu-virt/candidate plus http://people.canonical.com/~serge/qemu-aarch64-into-arm.debdiff
<hallyn> slangasek: ^
<hallyn> dannf was kind enough to do a test build, and the resulting pkgs look sane
<hallyn> am i thinking clearly in that what we don't want is for qemu-user-static to include /usr/share/binfmts/qemu-$arch only for the native arch?
<slangasek> hallyn: what do you mean "only"?
<hallyn> slangasek: so armhf should have all but qemu-user-armhf, and arm64 should have all but qemu-user-aarch64;  but having /usr/bin/qemu-user-armhf on armhf is ok
<slangasek> hallyn: I guess you mean /usr/bin/qemu-user-aarch64 on armhf?
<infinity> slangasek: He means that only the native arch should be excluded.
<infinity> Erm, I hope that's what he means. :P
<hallyn> and i mean that it's ok in /usr/bin so long as it's not in /usr/share/binfmts/
<slangasek> infinity: yes, but that's not the correct rule; i386 is not "the native arch" on amd64, but we exclude it
<infinity> hallyn: So, it's shipped in /usr/bin on x86, so yes.
<infinity> hallyn: As to the bin question.
<infinity> hallyn: For the binfmts question, excluding things that could run natively on that arch makes sense.
<hallyn> so http://paste.ubuntu.com/7201561/ is the contents of the armhf qemu-user-static pkg,
<slangasek> hallyn: note that currently, qemu-user-static excludes both i386 and x86_64 on both i386 and amd64 archs
<hallyn> http://paste.ubuntu.com/7201562/ for the arm64 pkg
<hallyn> i dunno, i'm befuddled.  i t hink i'll push to ppa only tonight :)
<slangasek> hallyn: enough with the ppas
<slangasek> :)
<hallyn> slangasek: but qemu-user-static on my x86 has /usr/bin/qemu-x86_64-static
<slangasek> hallyn: yes, but it does not install the binfmt for either of i386 or amd64
<infinity> hallyn: Yes, it has the binaries, but not the binfmt.
<hallyn> slangasek: last time i fiddled with qemu-user-static i briefly bricked infinity's box
<hallyn> slangasek: right that was my q
<slangasek> and that's intentional, because you can run an i386 userspace on an x86_64 kernel
<hallyn> just making sure that i was thinking right about that :)
<infinity> slangasek: So, the binfmts should be skipped for anything that could reasonably be expecte to run natively on the same machine.
<slangasek> hallyn: so the same should apply to arm+aarch64, since you can run an armhf userspace on an aarch64 kernel
<infinity> Err, hallyn ^
<hallyn> infinity: cool
<slangasek> provide the emulator in /usr/bin, but don't enable it via binfmt-misc
<infinity> hallyn: powerpc/ppc64/ppc64el, sparc/sparc64, i386/amd64, armhf/arm64, etc.
<mwhudson> slangasek: depends on the soc!
 * mwhudson shuts up again
<slangasek> mwhudson: I know ;)
<slangasek> we've already had /that/ discussion on #debian-qemu
<mwhudson> hah
<infinity> mwhudson: Yes, not all SoCs can run both, and not all x86 CPUs can run amd64 binaries, but we're approximating for minimal damage, not maximum support.
<hallyn> bleh
<infinity> This is an area where erring on the side of caution is sane.
<hallyn> but why is there no qemu-user-aarch64
<infinity> hallyn: By which you mean qemu-aarch64-static?
<infinity> hallyn: Or the non-static build that no one cares about? :P
<slangasek> -rwxr-xr-x root/root   2904560 2014-03-21 09:59 ./usr/bin/qemu-aarch64-static
<hallyn> yeah i didn't do that part right
<slangasek> what?  what's with all these last-minute changes :)
<hallyn> slangasek: I'm trying to get the qemu-system-aarch64 pkg into qemu-system-arm, was all,
<infinity> hallyn: FWIW, those ppc/ppc64 lines should be consolidated the same way you're doing for arm.
<infinity>    (powerpc) echo ppc ;;\
<infinity>    (ppc64) echo ppc ppc64 ppc64abi32 ;;\
<infinity> ^-- Wrong.
<infinity> Again, for the same reason that i386 and amd64 were consolidated.
<infinity> hallyn: Anyhow, don't let nitpicking stop you from uploading either.  If you're sure you're not breaking x86 with your upload, we can iterate bugfixes for other arches as we go along.
<hallyn> so (ppc64 | powerpc) echo ppc ppc64 ppc6abi32;;\
<infinity> hallyn: And add ppc64el to the () list, yes. :)
<hallyn> oh that's not in there at all right now
<infinity> The mips line is probably eually wrong, but I don't know enough about mips to care today, and it doesn't affect us.
<hallyn> wiat so you mean (ppc64 | powerpc | ppc64el) echo ppc ppc64 ppc64abi32;;
<slangasek> infinity: aurel32 will be sad
<slangasek> hallyn: yes
<slangasek> (though, boggle at the strange shell convention)
<infinity> hallyn: Aye.  It's entirely possible the syscall emulation doesn't work across endian-flips anyway, but again, better safe than sorry here.
<hallyn> alrighty
<hallyn> dannf: by any chance od you have a victim on which you could install the aarch64 qemu-user-static pkg we built?  that you don't mind if you have to recover? :)
<hallyn> oh, well, noone's gonna be installing that right now anyway are they, so i guess there's no big hurry on that
<hallyn> oh one more newbie q,
<hallyn> shoudl i keep all the changelog entries from the ppa?
<infinity> hallyn: Yes, though you can ditch all the versions and signatures and collapse it into one big entry for the archive upload if you prefer.
<infinity> hallyn: But the log of what was done should be preserved.
<hallyn> oh hey!  upstream tagged rc1 in the meantime, guess i should use that
<hallyn> infinity: ok, thanks, i will consolidate them and push to trusty tonight.
<stgraber> hallyn: still around?
<hallyn> stgraber: yeah,
<stgraber> hallyn: hey, so we have a bit of a critical problem with your systemd fix :)
<hallyn> i'd fogotten what a pain it is getting rid of all the roms in the qemu release tarballs
<stgraber> hallyn: http://paste.ubuntu.com/7201679/
<stgraber> hallyn: my best guess is that we shouldn't be doing that nih_error_get in the failing nih_dbus_setup case as that seems to be the source of the assert, I'm just not 100% sure that this is right
<hallyn> hm
<hallyn> d'oh yeah
<stgraber> hallyn: this is causing systemd-logind to crash and die on quite a number of machines (potentially all machines that don't have cgmanager...)
<hallyn> bc it was a dbus nto nih call
<stgraber> is there a dbus equivalent we need to do, or can we just ignore that and return?
<hallyn> we already do that
<hallyn> doing the dbus_error_init
<hallyn> and _free
<hallyn> am i doing the same mistake in lxc?
<hallyn> i'm not!  d'oh.
<stgraber> well, that's good :)
<hallyn> stgraber: do you want to test first, or push, or do you want me to push?
<stgraber> hallyn: ok, so http://paste.ubuntu.com/7201696/ should do it right?
<stgraber> I'll do a test build and send it to jdstrand for testing
<hallyn> yeah that should do it
<stgraber> hallyn: fix worked for jdstrand, uploaded to the archive now.
<hallyn> stgraber: phew - thanks
<stgraber> hallyn: np, glad I was still around at the time. It was literally in my last run through IRC windows before going to bed.
<stgraber> wouldn't have been fun waking up to everyone not having logind running anymore
<hallyn> yeah, for similar reason si probably should stay up awhile and look for qemu disasters :)
<jdstrand> hallyn: I thought you said you didn't have a libvirt-bin upload?
<jdstrand> hallyn: we are trying to land libvirt with apparmor signal and ptrace mediation
<jdstrand> hallyn: bug #1298611
<ubottu> bug 1298611 in lxc (Ubuntu) "[FFe] apparmor signal and ptrace mediation" [High,Fix committed] https://launchpad.net/bugs/1298611
<stgraber> jdstrand: I've rejected hallyn's upload for now, it's not a critical fix (small feature change) so it can go after yours is through
<jdstrand> ok, thank you :)
<hallyn> jdstrand: 'doh, sorry
<hallyn> stgraber: well, libvirt will have failures with new vms, but..
<hallyn> jdstrand: when is the libvirt fix being pushed?
<jdstrand> so, everything is tested up, just waited on an ack
<jdstrand> waiting*
<stgraber> jdstrand: a ack from whom?
<jdstrand> stgraber: the release team-- specifically infinity since he has been in the loop on all of it
<stgraber> jdstrand: ok
<jdstrand> the ffe for apparmor userspace has not been granted yet
<stgraber> ok, so the situation is, we can't let qemu in without libvirt and we can't let libvirt in because your stuff is in a PPA somewhere
<stgraber> and we want hallyn's qemu in ASAP because it's a pretty major update and we want as much time as possible to catch problems
<hallyn> stgraber: i could pop the trusty machien type patch for now in qemu if you've rejected the prvious upload
<jdstrand> we want the same for apparmor :)
<jdstrand> I think we are talking about hours
<hallyn> jdstrand: i was thinking along different time scales regarding 'if i had anything'
<hallyn> oh
<stgraber> except hallyn's FFes have already been granted :)
<jdstrand> I tried to coordinate this ealier
<stgraber> but yeah, if we can get everything landed tomorrow, then fine but if apparmor is still stuck tomorrow, we should let qemu + libvirt in and you'll have to rebase your libvirt change on top of that next week
<jdstrand> that works for me
<hallyn> (both libvirt debdiffs are pretty trivial, no biggie rebasing either one or even merging them, <shrug>)
<hallyn> jdstrand: i thought we were coordinated - i saw tyhicks' debdiff posted and thought it was done
<jdstrand> hallyn: right-- you can't push mine before apparmor though, otherwise it will break
<hallyn> jdstrand: gotcha
<stgraber> hallyn: ok, so I'll reject your qemu for now just so nobody accepts it by mistake and breaks libvirt. You can still get slangasek or infinity to review it from the rejected queue so that when the apparmor stuff lands we can just accept it from there.
<hallyn> stgraber: so qemu won't be promoted right?
<hallyn> uh.  ok
<jdstrand> hallyn: he posted it for review, but it is only Fix Committed in the bug
<jdstrand> (it is in a ppa)
<hallyn> jdstrand: yeah it's a monster bug you've got there :)
<jdstrand> well, it could be worse. the policy changes were minimal due to how we handled the base abstraction
<hallyn> jdstrand: stgraber: i've got a bad feeling that my precise-plus-ppas-on-trusty-kernel setup is gonna have some broken containers briefly as a result :)
<stgraber> hallyn: why?
<jdstrand> it will work fine with a new kernel and old userspace
<stgraber> I don't backport apparmor to any of my precise PPAs so you should be fine
<jdstrand> that is specifically tested and supported for backport kernls
<hallyn> so containers not specifying 'signal,' or wahtever will be fine?
<jdstrand> if the apparmor userspace doesn't support it, yes
<stgraber> yep, so long as you don't have the new parser on the host
<jdstrand> and if you are on precise, then it won't
<hallyn> very good, i'm reassured :)
<jdstrand> I personally tested trusty kernel with ipc on precise with lxc
<jdstrand> (ie, precise system with no changes other than the new kernel)
<Unit193> mvo: guten Morgen.
<jibel> pitti, good morning. FYI I restarted wolfe-0{3,4,6} , dpkg segfaulted and all the tests failed.
<diwic> hmm, is somebody else experiencing no sound due to lack of acl permissions on /dev/snd/ ?
<RAOF> diwic: Welcome to the n-1st systemd upload!
<RAOF> diwic: Updating and restarting should probably fix it for you.
<diwic> RAOF, thanks. That's what I just did and got this - probably need to switch to main archive instead of mirror then
<darkxst> cjwatson, any ideas what we can do about Bug 1301045?
<ubottu> bug 1301045 in gnome-bluetooth (Ubuntu) "gnome-bluetooth and empathy pull in unity-control-center on Ubuntu GNOME packageset installation" [Undecided,New] https://launchpad.net/bugs/1301045
<diwic> and of course the GUI does not let me switch mirror :-(
<sarnold> diwic: it may not yet be in the archive, stgr aber just fixed it roughly two hours ago
<diwic> ok, thanks
<dholbach> good morning
<mvo> hey Unit193 - its waiting in approval queue :)
<mvo> dholbach: good morning
<mvo> Unit193: thanks again for your patience
<Unit193> mvo: Sweet!  Thanks a ton for fixing before trusty. :D
<dholbach> hey mvo
<mvo> Unit193: your welcome
<dholbach> hum.....
<dholbach> I have upstart-dbus-bridge.2186.pid and upstart-file-bridge.2186.pid in my home directory
<dholbach> did anyone else dist-upgrade and reboot today who can confirm this?
<sarnold> dholbach: moment, I saw that in a bugreport earlier..
<dholbach> sarnold, you are unstoppable
<sarnold> dholbach: hehe, I hope not, it's past my bed time :)
<dholbach> and ~/Testing as well
<sarnold> dholbach: ugh, sorry, bad news on this one, the report today is kind of all over the place, and the bots dup'd it to an ancient bug that doesn't feel appropriate: https://bugs.launchpad.net/ubuntu/+source/lxpanel/+bug/1302254
<ubottu> Launchpad bug 1106945 in lxpanel (Ubuntu) "duplicate for #1302254 lxpanel crashed with SIGSEGV in menu_cache_create()" [Medium,Confirmed]
<dholbach> jodh, ^ do you have any idea why this might be?
<torkel> dholbach: they disappeared (again) after the systemd breakage was fixed
<torkel> new packages in the archive ~10 minutes ago
<sarnold> ah!
<dholbach> ah, brilliant
<dholbach> thanks torkel
<dholbach> let me try that
<dholbach> maybe I'll get sound back again as a bonus ;-)
<jodh> dholbach: yes - XDG_RUNTIME_DIR is unset.
<jodh> dholbach: logind breakage?
<dholbach> I don't know what it is - I'll try an upgrade an brb
<sarnold> jodh: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1302264
<ubottu> Launchpad bug 1302264 in systemd (Ubuntu) "systemd-logind assert failure: error.c:319: Assertion failed in nih_error_get: context_stack != NULL" [Critical,Fix released]
<pitti> jibel: ah, thanks; so again the "try again" clickery exercise?
<pitti> good morning
<dholbach> sarnold, jodh: thanks that solved the issue for me!
<jibel> pitti, yes, I clicked $world-ppc64el
<diwic> dholbach, and brought the sound back too
<dholbach> diwic, it did :)
<tsdgeos> guys any idea why on login i would have deja-dup-monitor using 6GB of my memory?
<seb128> tsdgeos, bug?
<tsdgeos> seb128: as a devel myself i would hate to get a bug saying "i booted up and deja-dup was using 6gb"
<tsdgeos> i mean it's non-reproduceable (probably) and doesn't give much info
<infinity> I'd hate it more if it wasn't reported. :P
<seb128> tsdgeos, use ubuntu-bug deja-dup, that might provide some info
<seb128> tsdgeos, you are not the only one, somebody mentioned issues earlier on #ubuntu-desktop
<seb128> tsdgeos, mterry is the maintainer, but he's probably still sleeping
<tsdgeos> ok
<tsdgeos> guys, any idea of what's wrong here?
<tsdgeos> http://paste.ubuntu.com/7202446/
<tsdgeos> 2.8.95~2430-0ubuntu5 is not >= 2.8.0-0ubuntu26 ?
<seb128> tsdgeos, sudo apt-get install  apparmor-easyprof-ubuntu apparmor
<seb128> tsdgeos, what does that say/do?
<tsdgeos> http://paste.ubuntu.com/7202470/
<jjohansen> tsdgeos: try and apt-get update first, apparmor-easyprof 1.1.14 is the current version in the archive
<jjohansen> your apt-get install is trying to install 1.1.13
<tsdgeos> jjohansen: i'm updated, maybe my mirror is behind
<jjohansen> tsdgeos: okay that is possible, the new easyprof landed 18 min ago
<jjohansen> or at least that is what lp says
<seb128> tsdgeos, right, the issue should resolve itself once the new apparmor-easyprof-ubuntu is available, or you can get it from https://launchpad.net/ubuntu/+source/apparmor-easyprof-ubuntu
<cjwatson> darkxst: hmm, I would have expected this to be handled by the fact that we install the task, so gnome-control-center and mcp-account-manager-goa ought to be marked for install before apt gets round to trying to resolve broken dependencies, which ought to mean that it doesn't need to try the first alternative because the second is already there
<cjwatson> darkxst: that's how it's meant to work, anyway.  if that's not working, somebody probably needs to fiddle with pkgsel.postinst on the fly in the installer to run apt-get with -o Debug::pkgProblemResolver=true so that we can see why it's taking that decision
<infinity> cjwatson: Except that his log clearly shows it installing the metapackage, not the task.
<infinity> Commandline: apt-get install ubuntu-gnome-desktop
<infinity> cjwatson: Which would explain why it works for his livefs (task-based) but not d-i.
<cjwatson> infinity,darkxst: oh, so this just comes down to Jackson's tasksel merge, then
<cjwatson> (probably)
<cjwatson> let me sort that out
<infinity> caribou: Err, tasksel?
<infinity> cjwatson: ^
 * infinity assumes you mean something that's changed more recently than raring.
<cjwatson> yeah, so that tasksel is able to install ubuntu-gnome tasks
<caribou> infinity: ?
<infinity> caribou: misfire.
<caribou> infinity: thought so
<cjwatson> I really do mean tasksel, it never got properly mangled for ubuntu-gnome
<cjwatson> so something is probably falling back to metapackages as a result
<infinity> cjwatson: Fair enough.  So, I guess this has always been broken like this, but it's just now biting them?  Makes some sense.
<infinity> With all the new control-centre splitting madness.
<cjwatson> I think so.  I'm not too sure *how* it's falling back to metapackages
<infinity> I guess just some random /xubuntu/ubuntu-gnome/ cargo-cult would DTRT?
<infinity> Not entirely sure how tasksel would work at all for ubuntu-gnome in its current state.
<infinity> Not without a pkgsel preseed.
<cjwatson> And yet.
<cjwatson> oh, it's not a real d-i log, it's somebody selecting it a bit more manually, I think
<infinity> Like, perhaps, pkgsel.
<infinity> The lack of d-i syslog makes it a mystery.
<cjwatson> Maybe in pkgsel's aptitude mode.
<cjwatson> Shrug.
<infinity> cjwatson: You know what would be nice?  If metapckages could be tasks.  ie: instead of ubuntu-gnome-desktop depending on 300 packages, if it just depended on task:ubuntu-gnome-desktop
<infinity> cjwatson: Though, I suppose that might screw up your point release hacks. :P
<cjwatson> Yeah, it's all a mess ...
<seb128> pete-woods, hey, why did you mark bug #1296715 invalid for the hud?
<ubottu> bug 1296715 in indicator-appmenu (Ubuntu) "Menu items are greyed out in Libreoffice menu." [High,Confirmed] https://launchpad.net/bugs/1296715
<pete-woods> seb128: I thought it'd been logged against the wrong package?
<seb128> pete-woods, I don't know what's the right package, the user says it happens to both the unity menus and the hud
<seb128> pete-woods, but I guess fixing the problem for the appmenu might fix the hud as well?
<seb128> tedg, hey, do you think you could have a look to ^
<pete-woods> seb128: sure, it'd fix the HUD problem too
<seb128> k
<seb128> pete-woods, thanks
<seb128> do you know who is maintaining indicator-appmenu?
<seb128> is that ted?
<pete-woods> seb128: it's certainly not me, but sure, ted would be the right person to ask
<seb128> k
<xnox> Chipaca: sergiusens: jodh: https://bugs.launchpad.net/ubuntu/+source/upstart/+bug/1302516
<ubottu> Launchpad bug 1302516 in upstart (Ubuntu) "upstart-dbus-session-bridge conflicts in stopping certain jobs" [Undecided,New]
<xnox> Chipaca: sergiusens: jodh: see the comments on the bug, if one does $ stop upstart-dbus-session-bridge, one can stop any job e.g. usensord and it does stop.
<xnox> i'm not sure if something is connected/listening on upstart and starts up the jobs, or if the dbus-bridge is rogue.
<mdeslaur> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Trusty Final Beta released! | Archive: Gated Review | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> saucy | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: mdeslaur
<sergiusens> xnox: I don't see the relationship to be honest; but I don't know the innards of the dbus-bridge either
<xnox> sergiusens: there might be a negative feedback loop.... upstart events are emitted on the dbus, then dbus bridge feeds them back into upstart..... and maybe just maybe that causes havoc =)
<xnox> sergiusens: or there is somebody noticing that usensord goes away and sends "start usensord" to upstart.
<xnox> sergiusens: is it a dbus activated service at all? and does something tries to manage it on top of upstart? e.g. unity/life-cycle stuff?!
<sergiusens> xnox: no dbus activation; the only user of usensord is platform api but that integration has been stuck in a silo forever
<sergiusens> that said, I could make it dbus activated instead of started through upstart (for usensord), not sure about the others that have symptons and this would just be a workaround
<ogra_> usensord runs at a low enough level that unity wont relate to it at all
<ogra_> (at least not wrt upstart handling)
<xnox> sergiusens: nah, no need. it does expose a tricky bug. I'll chat with jodh about it, when he is back from lunch.
<ogra_> sergiusens, thats pointless, we need it running constantly anyway for all the sensors
<ogra_> (once it supports all of them :P )
<xnox> sergiusens: but if you do want to stop unstoppable jobs, stop the two dbus bridges first, for now.
<sergiusens> ogra_: yeah; it is; as on first activation it would just be there forever
<ogra_> right, then we can as well leave that to upstart
<ogra_> and not add extra saturation the system dbus for it
<sergiusens> xnox: ok; Chipaca will find more use of that; I actually don't need to stop anything; he used me to make an example of :-P
<ogra_> *of the
<sergiusens> ogra_: agreed; there's a couple more I'd actually like to move to upstart instead of dbus activation; the first one that comes to mind is telepathy-ofono
<ogra_> right
<ogra_> for all stuff thats long running we should just use upstart
<Chipaca> xnox: sergiusens: Hi :)
<Chipaca> right now if you apt-get install ubuntu-push, you probably want to be able to stop it after tinkering with it a bit
<Chipaca> just because it's there for testing
<Chipaca> and ... well, it's rather cussed
<Chipaca> :)
<Chipaca> i mean: there's nothing depending on it, nothing calling into it, nothing at all that would make me think something is trying to restart it
<Chipaca> maybe the upstart .config thing is bad?
<Chipaca> i just copied usensord's one :)
<ogra_> sergiusens, ergh
<ogra_> stop on runlevel ?
<ogra_> thats a session job
<ogra_> you want to stop on session-end or some such
<ogra_> Chipaca, ^^
<Chipaca> ogra_: is that causing this breakage?
<xnox> Chipaca: no, usensord is fine and ubuntu-push is fine.
<ogra_> we it is causing the daemon not to stop with the session as it should
<xnox> Chipaca: nah, it simply means usensord is killed, rather than stopped on shutdown.
<Chipaca> ogra_: will investigate further
 * ogra_ still thinks we should use system events for session stuff
<xnox> ogra_: session force kills all jobs at the end, so one can even leave out "stop on"
<ogra_> *shouldnt
<sergiusens> ogra_: might be a problem to fix, but it shouldn't restart on a stop request
<ogra_> xnox, right
<ogra_> i dont mind leaving stop on out
<sergiusens> xnox: ah, nice; I'd rather have that; as in no stop stanza and let it do the right thing
<xnox> ogra_: well, the runlevel event on session init appears as "sys:runlevel" thus "runlevel" is never emitted on the session init, thus "stop on runlevel" for a session job is equivalent to no "stop on" at all =)
<ogra_> but stop on runlevel seems just ugly
<ogra_> yeah
<ogra_> thats what i mean :)
<xnox> i can fix that, but that has nothing to do with manually calling $ stop usersensord
<xnox> cause that's not event triggered.
<ogra_> do we actually have a plain dbus event (not started/stopped/starting dbus)
<Chipaca> maybe it shouldn't be 'start on dbus' either?
<xnox> Chipaca: for now, $ stop upstart-dbus-sessin-brdige; stop upstart-dbus-system-bridge; and then stopping usernsord/ubuntu-push should work.
<xnox> ogra_: yes we do, it's the session dbus
<ogra_> ok
<xnox> Chipaca: start on dbus is correct, if your daemon exports itself on dbus and needs dbus running.
<Chipaca> it'll helpfully wait around until dbus becomes available if it isn't :)
<Chipaca> but, yeah, better to wait and start it after
<ogra_> 14:12:34 LOOP 200
<ogra_> wohooo !!!
<ogra_> oops, ECHAN
 * ogra_ goes to #ubuntu-ci-eng instead 
<marga> Hi people.  I've been debugging a trusty issue that has been driving me crazy. initramfs-tools hangs on image generation, calling /libx32/ld-linux-x32.so.2.  I'm running kernel -20, and I've confirmed that on kernel -22 this does not happen.  However, since my initramfs generation failed, I couldn't reboot into the new kernel.  I've now modified /usr/bin/ldd to not call /libx32/ld-linux-x32.so.2, and with that I can upgrade, but I think that
<marga>  anybody in the same situation will also go crazy.
<marga> Since this is a problem with dist-upgrading inside trusty... Is it worth reporting a bug about it?
<ogra_> sounds like a multiarch issue
<xnox> ogra_: no, this is multilib issue, not multiarch.
<marga> Yes, multilib.  Happens because I have gcc-multilib installed
<ogra_> well, some multi* issue :)
<xnox> marga: yes, please still report it. And possibly assign it to infinity https://launchpad.net/~adconrad
<ogra_> you definitely dont want update-initramfs to process any foreign arch stuff
<xnox> marga: it may have been fixed, but if it's transient maybe we'll need to do something such that this doesn't happen again.
<xnox> ogra_: yes you do.
<ogra_> xnox, huh ? what for ?
<xnox> ogra_: our user-space is multilib, thus it needs to work =)
<xnox> ogra_: and we have x32 enabled on our stack.
<ogra_> but it is pointless to have any non native stuff in your initrd
 * ogra_ doesnt see a use case for that 
<xnox> ogra_: the point is that our linker must work, and during initramfs generation we call into linker and ask linker to resolve paths to libraries needed for binaries to generate a full initramfs. And it looks like, marga is reporting that linker got broken and was not resolving libraries.
<xnox> ogra_: a broken linker is bad, however you look at it =)
<ogra_> sure, i know there are hacks in update-initramfs or mkinitrd for that
<ogra_> thought only for amr stuff iirc ...to work around hf vs el
<marga> actually, this was hanging on a copy_exec on a shell script
<ogra_> *arm
<ogra_> yes
<marga> Which is likely a bug as well.
<xnox> ogra_: it's not hacks, but the point is that /usr/bin/ldd should be operational no-matter what for native arch. with or without extra packages, foreign or multlib arches are enabled.
<ogra_> copy_exec is what uses ldd to determine reverse deps of libs for a binary
<marga> But the thing was ld64 was failing, because it was a shell script, and then ldd called ld32
<ogra_> xnox, but you dont want two linkers in the initrd
<xnox> ogra_: and above it shows that it failed.
<xnox> ogra_: we don't have two linkers in the initrd.
<ogra_> right
<ogra_> but you would need an x86 one for x86 binaries, no ?
<xnox> ogra_: a call to ldd failed, at critical operation, and it should not have.
<xnox> (during dist-upgrade / initramfs generation)
<xnox> ogra_: and that's a bug. and has nothing to do with what our initramfs generation does.
<xnox> (has, should have, doesn't have, etc.)
<ogra_> ok, i trust you :)
 * ogra_ goes back to cursing cgmanager vs cgroup-lite issues and watching the 220th reboot of his phone 
<xnox> Chipaca: sergiusens: jodh: the jobs are buggy!
<xnox> Chipaca: sergiusens: jodh: "start on dbus" is start on any system/session dbus event.
<ogra_> heh
<xnox> Chipaca: sergiusens: jodh: "start on started dbus" is start after session/system dbus are available
<xnox> Chipaca: sergiusens: i'll make merge proposals to fix thsi.
<Chipaca> xnox: ah! excellent, thanks
<xnox> Chipaca: where is ubuntu-push code?
<Chipaca> pedronis: we might have another one-liner fix in today's trunk build, then
<Chipaca> xnox: i'm getting thing ready to go into a silo; want me to sneak this in too?
<xnox> Chipaca: well, let me make the merge proposal which project/branch do you use?
<Chipaca> xnox: lp:ubuntu-push/automatic
<Chipaca> xnox: branch from there, mp into there; that goes into /trunk once everything is green in the auto tests
<Chipaca> that is: that goes into a silo that gets needs to pass the on-the-phone test to get to /trunk
<ogra_> sergiusens, so with TheMuso uploading lxc-android-config it got out of sync with a bunch of pre-uploaded PPA versions of lxc-android-config ... if you want to release the telephony PPA to a silo please let me know in advance so i can get the package back in sync first
<sergiusens> ogra_: yeah, we need it in sync
<sergiusens> saw the upload last night
<ogra_> (i'll most likely do an upload of it soon for our desaster phone crashes )
<ogra_> seems i found the issue ... waiting for the 250th reboot to happen
<sergiusens> xnox: heh; the semantics are on a fine line there :-P
<xnox> sergiusens: https://code.launchpad.net/~xnox/usensord/fix-upstart-job/+merge/214225
<sergiusens> xnox: let me get a silo for that, thanks
<infinity> pitti: Are you going to self-accept those langpacks after you've had a poke at a random sampling to make sure they look sane?
<infinity> pitti: Let me rephrase that as a request instead of an inquiry: Please self-accept after you've randomly sampled a couple for sanity. :P
<pitti> infinity: oh, they are stuck in -proposed? yeah, they aren't meant to
<pitti> infinity: will do that (sampling + accept)
<pitti> thanks for the poke
<seb128> infinity, pitti: let me check the french ones
<pitti> looks good enough to me, but sure, let's wait for seb128
<xnox> seb128: damn, the one time we sneak-in en into fr, and fr into en language packs and seb128 notices =)
<seb128> lol
<seb128> xnox, don't worry, I'm not new to this game, pitti already tried to screw french by pretending that they were more german speakers in the world and that de should be ranked before french :p
<xnox> =)
<xnox> seb128: yeah, and mvo is back so pitti has extra mates to gang up with =)
<seb128> indeed
<seb128> pitti, look fine to me, desktop_kubuntu-notification-helper.mo got added to language-pack-fr, is that the right place for kde things? (also it includes ubuntuone-client.mo, which is deprecated)
<seb128> but those are minor details
<pitti> seb128: yes, it is; apachelogger will be happy :)
<pitti> (I think it was apachelogger, anyway)
<pitti> seb128: we don't have -kde langpacks any more, just the tiny kubuntu delta in the main pacakges
<pitti> seb128: thanks, accepting
<seb128> pitti, ok, that makes sense
<seb128> yw!
<tedg> seb128, I'll look at the bug, but usually if it's appmenu and HUD it's something in the app.
<seb128> tedg, Sweetsha1k is going to be happy!
<seb128> tedg, thanks
<xnox> Chipaca: https://code.launchpad.net/~xnox/ubuntu-push/fix-upstart/+merge/214226
<tedg> Uhg, and it looks like the apport hook is broken :-(
<gQuigs> I believe U1 was the last QT4 app on the desktop image.. does that mean qt-at-spi (qt4 accessibility),  sni-qt (indicator support), and libqt4-sql-sqlite can be removed from the image too?
<gQuigs> would save another 30 M (uncompressed)
<xnox> well we still need to sort out appmenu thing, for which a packaging solution was worked out.
<xnox> and then all of above, i think, could go.
<xnox> unless we do want qt4 a11y installed, such that when user installs with a11y enabled those persist and are in use when later user installed 3rd party apps, e.g. skype.
<xnox> i'm not sure how we handled a11y across all toolkits.
<gQuigs> xnox: hmm.. skype would be the big one there.. let me see..
<gQuigs> xnox: skype needs the i386 version of everything anyway.. so it's not helpful in that case at least
<xnox> gQuigs: true.
<jtaylor> fun gdebi is broken :(
<jtaylor> xnox: http://paste.ubuntu.com/7203304/
<jtaylor> II'm pretty sure it worked before the last update
<jtaylor> oh thats barry  change
<jtaylor> bug 1301422, probably related
<ubottu> bug 1301422 in gdebi (Ubuntu) ""Could not open ...deb. The package might be corrupted or you are not allowed to open the file. Check the permissions of the file" with latest 0.9.5 " [High,Confirmed] https://launchpad.net/bugs/1301422
<Chipaca> is it a known issue that unity goes loopy when changing the display's resolution?
<xnox> jtaylor: is this gtk, kde, or cli?
<barry> dang
<jtaylor> cli
<xnox> jtaylor: and you are just launching it without any command, or with *.deb as an arg?
<jtaylor> I'm using it as a pbuilder dependency resolver
<jtaylor> let me check what it actually runs
<jtaylor>  /usr/bin/gdebi --quiet  --apt-line  debian/control
<barry> jtaylor: any .deb in particular?
<jtaylor> probably any deb, just tried openblas
<jtaylor> but fftw3, so probably any
<jtaylor> *too
<barry> i see it
<barry> that *should* be shallow
<barry> hang on
<marga> infinity, can you take a look at https://bugs.launchpad.net/ubuntu/+source/eglibc/+bug/1302605 ?
<ubottu> Launchpad bug 1302605 in eglibc (Ubuntu) "Calls to /libx32/ld-linux-x32.so.2 hang" [Undecided,New]
<marga> I would assign it, but launchpad doesn't let me
<pitti> ev: I sent a reply about your "tag runners for dep8" yesterday; I guess you are busy, but if you think that a coarser "run on any vs. all platforms" is sufficient, that's certainly much easier to maintain
<pitti> but less explicit
<barry> jtaylor, xnox branch pushed.  if mvo is around, maybe he can review/push to debian, otherwise i can do that.  https://code.launchpad.net/~barry/gdebi/lp1301422/+merge/214257
<zyga> mvo: hey, what are you going to work on?
<brendand> mvo, i want to know too :)
<barry> the only thing mvo *can* work on... awesomeness :)
<jtaylor> univeral_newlines, never know of that flag
<mvo> barry: looks good, thanks
<jtaylor> it causes return as unicode?
<jtaylor> in which encoding?
<mvo> zyga, brendand: bugfixing for the release right now :) later click&systemimage I hear
<barry> jtaylor: https://docs.python.org/3/library/subprocess.html#frequently-used-arguments
<barry> locale.getpreferredencoding(False)
<barry> which usually means utf-8
<barry> and it's a classic "porting to python 3" addition. sorry i missed that originally
<xnox> jtaylor: universal_newlines returns str, instead of bytes. In python2 makes no difference, in python3 - big difference =)
<zyga> mvo: nice
<xnox> jtaylor: that's how i understood the flag.
<zyga> mvo: I'm really glad to see you here again :-)
<jtaylor> interesting
<barry> mvo: will you merge and upload?
<xnox> jtaylor: cause python2 casts bytes to string and string to bytes interchangeably, and python3 does not.
<jtaylor> yes I know that, but didn't know that flag
<jtaylor> I always added .decode(...)
<barry> xnox: well, in py2, if you're lucky :)
<xnox> barry: quite! =)
<mvo> barry: sure!
<barry> yep.  i think universal_newlines is safer than .decode()
<mvo> zyga: yeah, I'm very excited as well :)
<barry> mvo: thanks!
<xnox> jtaylor: well the flag was added because - hey most of the things that are Popened actually print text, and text is processed, rather than binary streams.
<brendand> mvo, the 'software install and updates' realm :)
<mvo> brendand: yeah :)
<jtaylor> which version of python has this flag?
<xnox> jtaylor: universal_newlines is better as it's explicit and works in both python2 and python3 and does the right thing.
<jtaylor> I really wish pythons docstrings were as good as numps ...
<pitti> shadeslayer_: I responded to https://code.launchpad.net/~rohangarg/apport/fix-for-1282713/+merge/213492 with a proposed fix that hopefully works (and is very simple)
<dannf> hallyn: i can launch a cloud instance and install qemu-user-static there. what are you looking to see tested, binfmt stuff?
<jtaylor> seems 2.6 already has it, good so it can be sued upstream :)
<hallyn> dannf: mostly i wanted to make sure that installing it on an arm and an arm64 box do not brick the box
<hallyn> dannf: i don't think they will, the packages *look* good...
<dannf> hallyn: ah. sure, i can test that
<mvo> barry: uploaded
<barry> mvo: awesome, thanks.  i'll watch debian and sync it over
<hallyn> Daviey: i'm open to counter arguments...  and i dont *foresee* this happening again since this was due to the switch from qemu-kvm to qemu source
<hallyn> i don't *like* doing this tbh
<pitti> shadeslayer_: ah, so os._exit() plus the setdestroyonexit() hack both together fixes the crash AND avoids the irritating "can't launch web browser" error?
<mvo> barry: great, thank you
<shadeslayer_> pitti: correct
<pitti> shadeslayer_: *phew*, awesome!
<shadeslayer_> yeah :)
<pitti> shadeslayer_: sorry if I caused trouble, but I hate introducing regressions knowingly
<hallyn> zul: kirkland: ^ same with you :)  (if you'd like to counter)  i've never used rhel so have no idea how much of a benefit/pain it turns out to be
<shadeslayer_> pitti: np, I wanted it fixed too, this way we can fix 2 problems in one go :)
<shadeslayer_> but would be nice to get this fixed ASAP
<cjwatson> jtaylor: universal_newlines dates back roughly forever; it's just that it used to be only really useful on non-Unix
<hallyn> Daviey: kirkland: zul: well, i'll be pushing to trusty soon (really i already did last night :) so,
<cjwatson> because it also handles \r and \r\n newline conventions
<pitti> shadeslayer_: committed both; running tests now, and then releasing
<shadeslayer_> pitti: \o/
<zul> hallyn:  reading
<zul> hallyn:  im missing the context
<xnox> ogra_: i received a txt message, and it was full message in the bubble, in the indicators, but when i clicked the bubble and opened it in the app no text is printed only date and time and no content.
<xnox> is this a known bug?
<hallyn> zul: bug #1294823
<ubottu> bug 1294823 in qemu (Ubuntu) "FFE: create a trusty machine type" [High,Triaged] https://launchpad.net/bugs/1294823
<hallyn> biam
<ogra_> xnox, i dont think so, file it against the messaging-app
<zul> hallyn:  im cool with it
<ogra_> davmor2, ^^known ?
<davmor2> xnox, ogra_: that's an old bug I've not seen for ages and was supposedly fixed let me run some tests
<xnox> davmor2: this is a real txt, not faked up.
<davmor2> xnox: yes I send real texts to myself
<ogra_> xnox, do you suggest davmor2 only has fake friends sending him SMS ?
<ogra_> :)
<xnox> davmor2: well, until now i've only used phonesim =))))
<hallyn> zul: ok.  i'm a bit apprehensive, but it was the best solution to our *last* error :)
<hallyn> sorry i'm getting snarky with myself
<xnox> ogra_: davmor2: screenshots http://people.canonical.com/~xnox/sms-fail/
<davmor2> xnox: you can send an SMS to yourself
<xnox> davmor2: this message is comming from a numberless account, it's from the provider however so the originator is "3Alerts"
<xnox> let me self send a message.
<xnox> hm our keyboard has : and ; wrong way around =)))
<xnox> davmor2: sending fresh one to myself works correctly, the 3Alerts one still doesn't print text in the app.
<hallyn> all right then, dannf: ^ long as your boxes turn out all right i'll ask infinity to pull the qemu bck out of rejected :)
<xnox> davmor2: indicator shows both correctly =(
<xnox> ..
<xnox> i wonder about making whatsapp client... it's jabber with phone as id and IMEI as login so it should just work...
<davmor2> xnox: http://davmor2.co.uk/~davmor2/screenshots-phone/device-2014-04-04-152957.png and http://davmor2.co.uk/~davmor2/screenshots-phone/device-2014-04-04-153208.png
<hallyn> now i guess i can push the libvirt one without the qemu one...
<hallyn> so i'l do that
<xnox> davmor2: can you open the app?
<xnox> davmor2: that's the indicator (both)
<dannf> hallyn: works fine for me on armhf/arm64
<hallyn> dannf: \o/  thanks
<xnox> davmor2: also see that beginning is shown in:
<xnox> http://people.canonical.com/~xnox/sms-fail/app-welcome.png
<xnox> but in
<xnox> http://people.canonical.com/~xnox/sms-fail/app.png
<davmor2> xnox: http://davmor2.co.uk/~davmor2/screenshots-phone/device-2014-04-04-153404.png
<xnox> it's empty
<pitti> shadeslayer_: 2.14.1 uploaded, now needs an ubuntu-release member to ack it from the queue
<hallyn> infinity: could you pull the qemu 2.0 out of rejected?  (stgraber put it there last night bc we had to wait on libvirt)
<xnox> davmor2: any logs i can check?
<hallyn> else i can just re-dput...
<davmor2> xnox: also http://davmor2.co.uk/~davmor2/screenshots-phone/device-2014-04-04-153518.png
<davmor2> xnox: cyphermox and awe will be the guys to get in touch with I think
<cyphermox> xnox: latest image?
<xnox> cyphermox: 276
<xnox> cyphermox: from todayish
<cyphermox> ok
<cyphermox> looks cute.
<xnox> cyphermox: my screenshots? =) thanks
<cyphermox> yeah
<xnox> cyphermox: i think it may have to do with the fact that it's a fake alpha sender id, rather than a real phone-number.
<cyphermox> xnox: just to make sure, you don't have phonesim installed right now?
<xnox> cyphermox: i'm not sure how to send those for real.
<xnox> dpkg -l | grep phonesim => returns nothing
<cyphermox> ok
<cyphermox> because phonesim does break stuff majorly if you're not into testing stuff :)
<xnox> cyphermox: this is my real phone =)
<cyphermox> xnox: this goes beyond my knowledge of the sms situation right now; I can check if there was a landing of this stuff recently to explain the failure though, and then possibly who to blame :)
<cyphermox> xnox: were you running 275 before that?
<xnox> cyphermox: well, it's a fresh flash but i didn't wipe data.
<xnox> cyphermox: is there a way for me to preserve sms database somehow?
<xnox> cyphermox: cause the issue is visible if i close and restart the messaging app.
<cyphermox> right, but I'm trying to pinpoint where it could have started to go wrong
<cyphermox> xnox: the sms database should always be preserved...
<xnox> cyphermox: i believe this was the first text message i ever received =)
<xnox> cyphermox: whilst on ubuntu touch =)
<cyphermox> right
<cyphermox> so I think awe_ is more likely to be able to figure it out than I am, I guess it's time to file a bug
<cyphermox> I'll go put my personal sim back into my nexus 4 and try to get sent such a special sms
<awe_> what's the issue?
<xnox> awe_: how can i dump/copy sms database
<cyphermox> awe_: well, really, http://people.canonical.com/~xnox/sms-fail/
<xnox> awe_: http://people.canonical.com/~xnox/sms-fail/app-welcome.png see 3Alerts <From 3:.....
<xnox> awe_: when i tap on it, i get http://people.canonical.com/~xnox/sms-fail/app.png
<xnox> awe_: yet if i pull down indicator i can read the message http://people.canonical.com/~xnox/sms-fail/indicator.png
<awe_> seems like a messaging app bug to me
<awe_> ofono doesn't store any messages, that's done at the telepathy level
<awe_> so it's either a bug in tp-ofono, or the messaging app itself
<awe_> that said, i'm not sure if there's a db that holds the original contents of incoming text messages
<awe_> ( ie. they may just be decoded and stored )
<davmor2> awe_: out of interest has anyone seen what happens if you send an SMS over 140 characters and do you know if network messages can be more than 140?
<xnox> awe_: well, indicator and app access the same source of the message, right?! cause indicator showed it correctly.
<awe_> xnox, sure but they're two different processes doing the rendering
<awe_> and one apparently has a bug
<awe_> ;)
<awe_> and if I was a betting man, I'd put my money on the messaging app
<awe_> I would start with filing a messaging app bug, and let tiago/boiko triage and move if necessary
<xnox> awe_: i'll file a bug. =)
<cyphermox> davmor2: it seemed to work for me
<ev> pitti: I'll have a look after this call. Thanks for raising it - it would've been buried
<awe_> davmor2, nope... I haven't specifically tested that.   I'm also not sure if ofono does the automatic split of messages that are too large, or whether it's the responsibility of the messaging app
<cyphermox> davmor2: theoretically you can send a bit more than 140 characters  on one single network control message, and if it's much more the split is supposed to happen, yeah ;)
<awe_> davmor2, you can send more than 140 chars if the message is 7bit encoded
 * awe_ isn't going to do the math in his head
<cyphermox> awe_: so you think we're not storing the sms outside the sim?
<awe_> davmor2, why do you ask?  Have you seen something weird that needs explanation?
<awe_> cyphermox, we don't store any SMS messages on the SIM
<cyphermox> awe_: right
<awe_> and yes
<cyphermox> awe_: so there has to be a database that keeps them ;)
<awe_> they may be stored outside of the SIM by telepathy
<cyphermox> right
<awe_> not necessarily a db
<davmor2> awe_, cyphermox: hence asking if the network messages can be more that the total number of characters available to a standard sms  which then might explain the message not being handled correctly in the messaging app
<awe_> could be plain text
<cyphermox> well, I'm saying db in the large sense. a text file can be a database
<awe_> davmor2, my guess it that the messaging app is getting screwed up by message content, not length
<cyphermox> OH
<cyphermox> yeah, wasn't it starting with a < ?
<xnox> cyphermox: awe_ it's to do with special chars.
<xnox> i've sent the message with special char and that does not work: <From 3: Your new ebill is now ready to view. For the full bill go to My3 online or on your mobile. For \
<xnox>  a summary click on http://mobile.three.co.uk/sms04 >
<awe_> ;D
<cyphermox> right :)
<xnox> awe_: nevermind the \ and newline break.
<cyphermox> some piece of the puzzle tries to evaluate that as some kind of xml
<awe_> ( or html )
<xnox> cyphermox: awe_: so shall i file a bug against messaging app?
<awe_> yes
<cyphermox> xnox: yeah
<awe_> please
<xnox> ack.
<davmor2> xnox, awe_, cyphermox: confirmed xnox just sent it to me I see it in the indicator and the notification but just get a date stamp in the messaging app
<cyphermox> very cute
<davmor2> xnox: ping me the bug number and I can confirm it do you want me to add images?
<mdeslaur> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Trusty Final Beta released! | Archive: Gated Review | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> saucy | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<pitti> jamespage: the swift autopkgtest failure looks real (pointing out because you probably got a lot of jenkins fail/success spam recently, as the ppc64el boxes keep exploding)
<jamespage> pitti, I'm looking at it now
<jamespage> pitti, rings are being created with odd permissions and I'm not sure why - stops the proxy server from starting
<xnox> awe_: cyphermox: bug #1302652
<ubottu> bug 1302652 in messaging-app (Ubuntu Trusty) "Fails to display special chars in the txt messages" [High,Confirmed] https://launchpad.net/bugs/1302652
<xnox> awe_: cyphermox: please triage / assign as needed.
<xnox> davmor2: bug 1302652
<xnox> davmor2: https://launchpad.net/bugs/1302652
<awe_> xnox, that's outside of my domain.  Please ping Tiago or bfiller
<xnox> sabdfl:
<bfiller> assigned to salem_
<xnox> sabdfl: do we have the next name? =)
<xnox> 13 days left....
<pitti> smoser, infinity: seems wolfe-03 went AWOL? can't reach it with ssh after a reboot (had to reboot the lot as they were segfaulting again, third time in two days :/)
<pitti> jibel: meh, seems they all got stuck now; WTH
<dobey> xnox: why'd you break software-center for?
<xnox> dobey: bug #?
<xnox> dobey: i didn't break anything on purpose =)
<dobey> xnox: i don't know if there's a bug # yet. i just noticed you "disabled the qt build" on ubuntu-sso-client
<xnox> dobey: right, that shouldn't break software-center. Let me check it out here.
<dobey> xnox: which means that there is no more UI
<xnox> dobey: i was told software-center has it's own, cause it only depend on ubuntu-sso-client and not on ubuntu-sso-client-qt.
<dobey> no, it doesn't have its own UI any more
<xnox> dobey: what's ubuntu-sso used for in software-center? comments / U1 login?
<bdmurray> seb128: would it make sense to fix bug 1291862 in gnome-control-center for Trusty too?
<ubottu> bug 1291862 in OEM Priority Project precise "[soundnua]mic volume adjust bar is gray if you open sound-nua input tab earlier than plugging micphone" [Undecided,In progress] https://launchpad.net/bugs/1291862
<dobey> xnox: yes
<seb128> bdmurray, not sure, the GNOME remix guys were talking about updating g-c-c to a newer version and dropping more of the Ubuntu patches to it
<xnox> dobey: it really needs to declare a dependency on ubuntu-sso-client-qt, if it in-fact uses it. As there is nothing else that's pulling that on desktop images anymore.
<seb128> bdmurray, check with them I guess, I'm not even sure it's going to apply to the new version
<dobey> xnox: one of the packages declares a dep on -ui which is only provided by -qt i think
<bdmurray> seb128: okay, I was just curious and won't let it block the SRU.
<seb128> bdmurray, we fixed it in unity-control-center, which is the same codebase as the g-c-c SRU
<seb128> bdmurray, thanks
<xnox> dobey: i don't see such a dep.
<dobey> xnox: anyway, there's nothing in ubuntu-sso-client that is specific to the file sync, so there's no reason its packages should have changed at all, really
<xnox> dobey: found it.
<xnox> dobey: it's pulling in qt4 on desktop images, which is not used anymore.
<xnox> dobey: =)))) it's  a massive debt on the images, which ideally i'd like to drop (~100MB)
<dobey> xnox: it's used by ubuntu-sso-client
<dobey> xnox: you're free to port it to qt5 of course
<xnox> dobey: i thought we have online accounts for u1/sso, which is gtk UI =)
<dobey> :)
<dobey> no
<xnox> dobey: what do you mean, no?
<dobey> we have no online accounts plug-in for u1 on the desktop
<xnox> i do =/
<dobey> then you've installed the phone packages and added on with the qml system-settings app
<dobey> because there is no way you added one with the gtk+ control-center ui :)
<xnox> dobey: well, i was thinking that our control-center should allow Xembeded protocol to embed e.g. qt plugins and python based plugins =)
<dobey> xnox: well, i'm sure mardy will accept your patch for that too :)
<xnox> dobey: indeed i'm failing to login in the software center. Let me resurrect sso-qt thing.
<dobey> i guess oneconf uses sso too, but you also probably only get the login from within software-center as well
<xnox> dobey: with or without -qt installed, clicking "Write your own review" I get a popup which "Failed to log in"
<dobey> xnox: hmm
<xnox> dobey: did we shutdown so many things, that ubuntu-sso-client is logging in into something u1ish instead of login.ubuntu.comish ?
<dobey> xnox: maybe you already have an account in your keyring, but it's invalid?
<xnox> dobey: let me try clearing those!
<xnox> dobey: actually, let me boot a VM that would be easier to test.
<dobey> :)
<xnox> dobey: or maybe you should test it =))) instead of being all smart about this ;-)
<xnox> dobey: i have no clue how oneconf or comments work in the software cneter :P
<dobey> i don't know how oneconf works either
<xnox> dobey: awesome =) together we'll fix everything =)
<dobey> that's didrocks's baby
<xnox> dobey: right, i need to resurect qt bit and respin desktop image, *sigh*
<dobey> xnox: with -0ubuntu4 packages, software-center pops up the signup/login dialog correctly, when i don't have an existing login in keyring.
<dobey> xnox: indeed
<shadeslayer_> Riddell: mind ack'ing apport
<xnox> dobey: oh well qt4 removal will happen in Ubiqutious Unicorn =(
<shadeslayer_> Riddell: from the queue
<Riddell> shadeslayer_: what's new?
<xnox> dobey: ideally we'd be able to use the qml online account =(
<shadeslayer_> Riddell: fixes for apport-kde at the very least, pitti ^^
<xnox> dobey: uploading fix.
<Riddell> shadeslayer_: accepted!
<dobey> xnox: ideally the sso server would have standard oauth2 endpoints
<xnox> dobey: what would that change? being able to use any stock oauth2 GUI client? what about teams, 2fa etc?
<xnox> dobey: thanks a lot for spotting this bug though!
<xnox> dobey: and we totally have python-gi-gtk implemenetation for auth, we had it ubiquity installer. I'll if I can port that to software-center for next cycle.
<dobey> xnox: yes, 2fa would be handled on the web server
<dobey> xnox: if we had oauth2, we wouldn't need to write any special plug-in code. just the simple provider files for uoa
<rbasak> Is there a way I can specify a versioned relationship that describes "anything before this epoch"? Eg. Breaks/Replaces: foo (<< 2:~) or something?
<rbasak> I guess that would work - is there any standard convention for describing this?
<cjwatson> I would probably use "<< 2:0~"
<rbasak> Great, thanks.
 * rbasak does what cjwatson would do
<cjwatson> dpkg: warning: version '2:~' has bad syntax: version number does not start with a digit
<rbasak> Ah OK. I was guessing :)
<cjwatson> So you can't use that
<cjwatson> 2:0~ isn't perfect (you can construct pathological things like "2:0~~1") but in practice it should be good enough
<rbasak> << 2:0~~~~~~~~~~~~~~~~~~~~~~~~ :)
 * hallyn looks around for infinity or slangasek 
<bdmurray> Laney: thanks for digging into that not whoopsie-preferences bug.
<Laney> bdmurray: np, it was weird and hurt my head
<Laney> which was fun at first, then not fun any more
<slangasek> hallyn: hi, what's up?
<hallyn> slangasek: oh hi - would you mind pulling the qemu 2.0.0-rc1 out of rejected?  (it was placed there lst night bc we were waiting on libvirt)
<slangasek> hallyn: ok, will be a bit before I can get to it but yes
<hallyn> slangasek: thanks
<kirkland> hallyn: what were your questions about?
<vlada> Not sure if this a material for devel channel, but I have to try. What could possibly prevent Firefox and Chrome from redrawing window content? It gets redrawn by window resize or minimize/maximize action. It's definitely just refreshing visually since app receives events, but is not showing me "reactions" on screen.
<hallyn> kirkland: about whether introducing a (default) 'trusty' machine type in qemu could end up beign somethign we regret
<kirkland> hallyn: hmm, what does that mean?
<kirkland> hallyn: "machine type"
<hallyn> kirkland: -M trusty akin to -M pc-1.0
<kirkland> hallyn: ah
<hallyn> iti s an alias to the pc-i440-2.0
<kirkland> hallyn: so, why "trusty"?
<hallyn> bc in U it'll alias to something different
<kirkland> hallyn: yeah, I think of machine types as more of a hardware thing
<hallyn> kirkland: but you'd be not quite right :)
<hallyn> kirkland: the problem is pc-1.0 right now means different things whether you're on qemu-kvm or qemu
<kirkland> hallyn: :-)
<kirkland> hallyn: I'm very rarely quite right
<hallyn> and so in trusty, we'll have ppl migrating from precise as well as saucy,
<hallyn> both with pc-1.0 machine types, but meaning different things
<hallyn> and qemu doesn't (to my surprise) adjust itself to the soruce machine, but just bails
<kirkland>        -M [SS-4|SS-5|SS-10|SS-20|SS-600MP|LX|Voyager|SPARCClassic] [|SPARCbook]
<kirkland>            Set the emulated machine type. Default is SS-5.
<hallyn> So the intent is, at 16.04,
<hallyn> we should be able to migrate correctly from both 15.10 and 14.04
<kirkland> (that's from the manpage of qemu)
<hallyn> bc pc-i440-2.0 in 15.10 will be different from in 14.04
<hallyn> kirkland: do 'kvm -M ?' to get list of machine types
<kirkland> hallyn: k
<hallyn> kirkland: sounds like the man page may warrant some updating :)
<kirkland> hallyn: *definitely*
<kirkland> hallyn: honestly, I don't think I have an intelligent opinion here;  should we ask aliguori
<hallyn> oh, perhaps
<hallyn> i' not sure, but the idea may originally ahve come from rharper
<hallyn> kirkland: in part i fear i may be just addressign a non-issue - it was an issue bco f the divergent qemu and qemu-kvm trees
<hallyn> upstream *shoudl* never make pc-i440-2.0 in a later qemu have different defaults
<kirkland> hallyn: yeah
<hallyn> anyway that's enabled in the current qemu in trusty-proposed (well, rejected for now :)
<hallyn> but if we think it's a bad idea i can pull it back out in a new upload
<hallyn> let's think on it over the weekend :)
<hallyn> kirkland: (aliguori isn't on #qemu right now)
<kirkland> hallyn: I sent him an SMS
<hallyn> :)
<kirkland> hallyn: okay, aliguori says he's going to ping you later today
<hallyn> kirkland: ok thanks
<rharper> hallyn: ping me if you chat with aliguori
<jdstrand> hallyn: not sure if you saw, but libvirt landed last night. thanks for being patient with me (we had been testing our stuff for like 4 days straight :)
<hallyn> jdstrand: np!  yeah i pushed the new one earlier this morning
<hallyn> rharper: ok
<jdstrand> cool
<YokoZar> What's the right way to depend on opencl these days?
<YokoZar> Is it to depend on "ocl-icd-libopencl1 | opencl-icd"
<bdmurray> infinity: ping about bug 1296386
<ubottu> bug 1296386 in casper (Ubuntu) "[PATCH] Remove 23etc_modules script" [Undecided,New] https://launchpad.net/bugs/1296386
<AnAnt> pitti: LP #1302331
<ubottu> Launchpad bug 1302321 in systemd (Ubuntu) "duplicate for #1302331 Missing /lib/systemd/systemd-logind-launch (referred to by /usr/share/dbus-1/system-services/org.freedesktop.login1.service)" [Wishlist,Won't fix] https://launchpad.net/bugs/1302321
<AnAnt> hmmm, ubottu is mistaken, the bug is neither a wishlist nor a won't fix !
<Unit193> I clicked the link, I see the same thing.  Changed 3 hours ago.
<AnAnt> Unit193: yes, I was mistaken. it was reporting for 1302321, I was looking at 1302331
<calc> I have a bug I'm not sure what package to report against, it might already be reported as well but I'm not sure, frequently on my system the unity hud shows through the screensaver
<calc> any ideas of where I should report it?
<Noskcaj_> calc, Maybe search launchpad for a bug similar to what you have
<calc> i see something similar that was fixed 2 years ago, but not a current open bug, so I suppose I'll reference that one in a new report for trusty
<Noskcaj_> ok
<Noskcaj_> Use ubuntu-bug to report it so more info is attached
<slangasek> pitti: fyi, infinity is rebooting wolfe, taking down the autopkgtest VMs, to check if this addresses the stability problems
<slangasek> pitti: so if you see suddenly-failed jobs, that's why
<brainwash> can anyone please prepare an abiword bug fix release and upload it? we got 3 pending patches, see https://bugs.launchpad.net/ubuntu/+source/abiword/+bugs?orderby=-id&start=0
<hallyn> slangasek: not in a hurry, don't mean to be pushy, but just making sure it didn't slip your mind - still planning on salvaging qemu 2.0 from the rejected queue today?
<slangasek> hallyn: it's been a busy day ;)  I just managed to pull down the sources now
<slangasek> hallyn: how does this package compare to the last thing you uploaded to the ppa?
<slangasek> hallyn: also, was just checking and it looks like libvirt should be safe to let through in advance of qemu, right?
<hallyn> slangasek: yup, libvirt can go through first,
<slangasek> ok, accepting
<hallyn> the difference between last ppa upload and current one in queue is:
<hallyn> 1. based on a different tarball (built from the upstream release tarball, removing the bioses),
<hallyn> 2. moves qemu-system-aarch64 into qemu-system-arm
<hallyn> that *shoudl* be the only difference (and i debdiffed a few times to look for mistakes)
<slangasek> ok
<slangasek> +    - remove -enable-uname-release=2.6.32
<slangasek> hallyn: ^^ is that because we decided to not try to run this version on the emulated builders?
<hallyn> slangasek: i think so.  but that's already in the archiv ein 1.7 isn't it?
<infinity> slangasek: We most definitely want to run it on the buildds.
<slangasek> hallyn: if qemu-system-aarch64 is a dummy package, the Provides: should have been moved to qemu-system-arm; you're also missing a Breaks:/Replaces: from the new qemu-system-arm to the old qemu-system-aarch64 package
<slangasek> hallyn: (that alone is reject-worthy, so I'll not be un-rejecting this version - but let me see if there's anything else that needs fixing before you reupload)
<hallyn> slangasek: removing -enable-uname-release=2.6.32 was bc it's now done in a better way
<slangasek> infinity: so does that mean this 2.6.32 change is a problem?
<infinity> hallyn: It's now done in a better way for minimum kernel versions (ie: the aarch64 case), but that doesn't fix our buildd issue, I thought.
<infinity> hallyn: You haz binaries with this change, so I can test?
<hallyn> infinity: yup, in ppa:ubuntu-virt/candidate
<slangasek> hallyn: the mail thread I remember said that we couldn't fix it the "better" way until we got rid of the buildd requirement
<slangasek> hallyn: but that we could and should confine the 2.6.32 usage to x86
<slangasek> or x86/arm, or something
<infinity> slangasek: To arm, pretty much, since that's all we care about for our weird usecase.
<slangasek> infinity: I mean "the arm build on x86"
<infinity> Sure.
<infinity> Let me have a look at this current binary and see what it really does.
<infinity> Oh, that would be easier if I had a machine with a hardy kernel.  Hrm.
<slangasek> check in the compost bin
<xnox> lol
<hallyn> slangasek: ok, provides and breaks/repalces fixed (hopefully the right way),
<infinity> So, on my machine, this is reporting 3.13.0-19-generic, which leads me to believe it's the same old leak uname through thing.  Though.  Maybe the new min_kver way can be patched to just bump it up for ARM instead of forcing uname in rules.
<infinity> Lemme look at the source here to see what they did for aarch64.
<hallyn> ./linux-user/openrisc/syscall.h:25:#define UNAME_MINIMUM_RELEASE "2.6.32"
<hallyn> ./linux-user/aarch64/syscall.h:9:#define UNAME_MINIMUM_RELEASE "3.8.0"
<hallyn> all are set to 2.6.32 except aarch64
<infinity> linux-user/arm/syscall.h:#define UNAME_MINIMUM_RELEASE "2.6.32"
<infinity> Ah-ha.
<infinity> That should work for us, then.
<infinity> \o/
<hallyn> but you're saying it is not working??
<slangasek> he's saying on his system, host kernel > 2.6.32 so is passed through
<infinity> hallyn: No, no.  I'm not saying it's not working, I'm saying it's hard to tell without an older kernel to test on. :P
<infinity> hallyn: But I think this should be right.
<hallyn> ah
<slangasek> infinity: don't we have a uname faker somewhere?
<infinity> And yay for upstream picking 2.6.32, since glibc 2.20 won't run on older. :P
<hallyn> LD_PRELOAD :)
#ubuntu-devel 2014-04-05
<hallyn> slangasek: http://paste.ubuntu.com/7205567/ does that look ok?
<slangasek> hallyn: yeah, thought we had an already-prepared uname faker, from back when the kernel versioning scheme changed and older software needed love
<slangasek> hallyn: um, diff please :)
<cjwatson> slangasek: that sounds like setarch --uname-2.6
<infinity> hallyn: Following the code, this should work.
<cjwatson> which is fairly specific to that one case
<infinity> cjwatson: setarch won't let you fake a uname, just set a personality bit to s/3.something/2.something/
<cjwatson> indeed, but I think it may be what slangasek is recalling
<slangasek> cjwatson, infinity: right, that's what I was thinking of; didn't realize it didn't take an argument
<infinity> slangasek: I'm not concerned about this change after reading the code, I think upstream got it right this time.
<slangasek> infinity: awesome
<hallyn> slangasek: uh, i've overwritten the old...  but i can diff with what's in the ppa
<slangasek> hallyn: ok.  what version were you going to use when uploading this?
<slangasek> because Breaks: qemu-system-aarch64 (<= 2.0.0~rc1+dfsg-0ubuntu1) is only right if the version you upload is > 2.0.0~rc1+dfsg-0ubuntu1
<cjwatson> the very existence of setarch --uname-2.6 is kind of an "oh, yeah, our userspace is made of fail" admission, but anyway
<slangasek> cjwatson: yes, but it was our /old/ userspace that we didn't want to fix up just to enable building in chroots :)
<hallyn> http://paste.ubuntu.com/7205574/
<cjwatson> certainly :)
<hallyn> slangasek: d'oh, yeah
<slangasek> hallyn: so you probably just want << there instead of <=, for both the Breaks and Replaces
<cjwatson> I just wish there were some mechanism to automatically telemock the authors of code that broke
<infinity> cjwatson: I found the "all kernerls start with 2" hilarity less disturbing than the "all kernels have (at least) 3 version components" screwups.  Lots of those still exist.
<cjwatson> (although I suspect I may have been responsible for one or two dodgy broken shell scripts ... at least they were dealing with things actually related to the kernel :) )
<cjwatson> infinity: yeah, we've basically elected not to exercise that
<hallyn> http://paste.ubuntu.com/7205588/
<cjwatson> I'd actually forgotten that we use setarch --uname-2.6 in lp-buildd when building for old series
<infinity> Forgetting a hack tends to mean it's working, so I'm okay with that.
<slangasek> hallyn: looks good.  I'm just finding my way to debian/rules now, let me give that a quick once-over before you reupload
<cjwatson> Yup
<hallyn> slangasek: cool, thanks
<slangasek> hallyn: is this build-tested on armhf?
<hallyn> slangasek: yup, dannf built it it on armhf and arm64
<slangasek> k, just checking; some of the diff around arm/aarch64/arm64 in debian/rules is non-obvious
<hallyn> from ppa to archive, or from 1.7 to 2.0?
<slangasek> hallyn: pretty sure line 95 of debian/rules is wrong, isn't that supposed to be 'echo arm aarch64'?
<slangasek> hallyn: from 1.7 to 2.0
<infinity> That should indeed be 'echo arm aarch64'
<hallyn> uh
<slangasek> hallyn: yes, quite certain that this is buggy - please to not be registering an aarch64 binfmt handler on aarch64 systems ;-)
<hallyn> i swear the built version didn't have it, but you're obviously right.
<hallyn> fixing that up
<slangasek> hallyn: that's it
<hallyn> then there's that mips one
<slangasek> the rest looks fine
<infinity> hallyn: Don't worry about the mips one, the Debian mips people can sort it if they care.
<slangasek> the mips was the one we said we were punting until aurel32 cared
<infinity> hallyn: (That is, don't worry about fixing it in Ubuntu, if you want to poke Debian people to care about it there, fine)
<slangasek> hallyn: I'm afk for the next half hour, but drop me a ping here when you've uploaded and I'll pick it up on the rebound (unless infinity intercepts)
<hallyn> slangasek: thanks for the review!
<infinity> I'm about to food and TV, but can pick it up after that, if vorlon doesn't beat me to it. :P
<hallyn> thanks - i'm ust looking over the new debdiff one more time, then i'll dput
<hallyn> slangasek: infinity: pushed.  will bbl.
<slangasek> hallyn, infinity: accepted
<psusi> infinity, I've had a few people asking how util-linux is coming ;)
<Noskcaj_> Laney, Can you finish your review of https://code.launchpad.net/~noskcaj/ubuntu/trusty/xfce4-xkb-plugin/lp-733563 please?
<Logan_> Noskcaj_: hi
<Noskcaj_> hey Logan_
<Noskcaj_> Sorry, i had to do some mowing for dad
<Logan_> Noskcaj_: do you still need help logging into the bouncer? :P
<Noskcaj_> Logan_, yeah
<Noskcaj_> I'm in hexchat
<Noskcaj_> Setting the server to "loganrosen.com" and the password doesn't seem to work
<Logan_> the server password, right?
<Logan_> and your username is Noskcaj?
<Noskcaj_> yes and yes
<Noskcaj_> actually, no
<Noskcaj_> What authentication method should i use, the default is password only
 * Unit193 tries to log in to loganrosen.com, fails.
<Logan_> Noskcaj_: the default
<Logan_> nice try, Unit :P
<Noskcaj> Logan_, Finally works. Thanks
<Logan_> Noskcaj: sweet :)
<hallyn> slangasek: thx, doing one last dist-upgrade locally to check for bad errors :)
<Unit193> Still need SASL though.
<Noskcaj> Is there anyone who works on haskell in ubuntu?
<Noskcaj> haskell-llvm-base probably needs a sync to build
<Logan_> Noskcaj: /ns identify <password>
<Logan_> Noskcaj: also do: /msg *nickserv set <password>
<Logan_> that's for znc
<Logan_> (yes, the asterisk is on purpose)
<Noskcaj> done
<Logan_> sweet
<hallyn> seems all right, as does cgmanager.  /me out
<Noskcaj> It seems haskell-devscripts would need syncing too
<Noskcaj> but i think that breaks most of haskell
<Logan_> yeah, it looks like a sync would fix it
<Logan_> a successful build only takes 4 minutes - I'll try it locally
<Logan_> oh, the changelog implies that the fix was only in haskell-devscripts
<Noskcaj> going offline to play dota
<pitti> slangasek: thanks; I've seen suddenly failed batches of failures all over the week, so by now I'm quite used to it :)
<slangasek> heh :)
<infinity> pitti: Do let me know if the reboot seems to have made things more stable for your guests...
<cjwatson> Noskcaj,Logan_: I'll have a look at haskell-llvm-base once I'm done with sorting out GHC on arm64.
<cjwatson> (which should be this weekend)
<Noskcaj> thanks cjwatson. It's been bothering me just how much of th ftbfs list is haskell stuff
<cjwatson> It's not clear that we need the new haskell-devscripts.  That seemed to be for a different failure.  In any event we should be extremely careful to avoid ending up having to rebuild haskell-*.
<cjwatson> Noskcaj: It's not that much, discounting dep-waits.
<cjwatson> I'll grant you it ought to be empty :-)
<cjwatson> Noskcaj: And (a) arm64 isn't going to get GHCi yet hence no Template Haskell, (b) barring miracles ppc64el isn't going to get GHC at all for 14.04, so it won't empty out in one go or anything.
<Noskcaj> ok.
<darkxst> cjwatson, hey, so yeh those logs were from apt-get. are you saying it should work when installed as a task?
<infinity> darkxst: Yes.
<infinity> darkxst: Which apt-get can do too, just add a ^ to the end.
<darkxst> ok cool, didnt know that
<infinity> darkxst: But Colin added ubuntu-gnome-desktop to tasksel earlier, so picking it from tasksel at the end of the install should also do the trick.
<infinity> darkxst: The apt-get task^ syntax is what's used in livecd-rootfs to build your livefs.
<darkxst> infinity, we still have the case of people cross-grading from ubuntu
<infinity> darkxst: So, if youre livecd is correct, then this should be fine.
<darkxst> infinity, livecd stuff is still a mystery to me ;)
<cjwatson> darkxst: Right.
<infinity> darkxst: cross-grading desktops has always been vaguely problematic (though mostly works) but yeah.  Some better way to do that wouldn't hurt. :/
<darkxst> it used to work reasonably well, before the u/g-cc split
 * infinity nods.
<infinity> darkxst: Thankfully, that's a temporary situation for unity7 and should go away again for 8, AIUI.  Unfortunately, that revelation doesn't help us for 14.04
<infinity> darkxst: If you're okay with the desktops not being coinstallable, you could perhaps make the metapackage conflict against the unity versions of those split bits.
<infinity> darkxst: Not really ideal, but could do the trick.
<darkxst> infinity, probably not really option, if people wanted to use any gnome2-ish desktop in addition to gnome3
<darkxst> we do have users that switch between gnome-shell and gnome-flashback
<infinity> darkxst: I think, realistically, we'll probably have to accept that it's not "real Ubuntu" or "real Ubuntu GNOME" unless people install from the appropriately-named media (or a fresh d-i install with the right task selected) for 14.04.
<darkxst> infinity, right, and probably apart from the extra packages, its not like there are crazy run-time conflicts
<infinity> Oh, I see, gnome-control-center and unity-control-center *can* coexist.  So, yeah, conflicts would be bad.
<infinity> But then how is cross-grading not working?
<infinity> Wouldn't you just end up with both installed?
<cjwatson> Yeah, you should ...
<cjwatson> The -desktop metapackages have explicit dependencies both ways round
<infinity> Now, installing both desktops and then trying to remove unity could be a hard slog.  But having both installed looks like it should Just Work, I think.
<darkxst> infinity, yes it just about the extra packages
<infinity> darkxst: You might need to elaborate on that. :)
<infinity> darkxst: "apt-get install ubuntu-gnome-desktop^" on my unity-based machine seems to want to pull in everything that should matter.  I think.
<darkxst> infinity, right I havent tried the ^ trick yet
<darkxst> but without ^ it pulls in all of u-c-c/u-s-d and UOA. I guess that is irrellevant though if ^ does work
<darkxst> I have to run and get dinner now anyway
<darkxst> infinity, ok, ^ seems to work right
<Laney> Noskcaj: Got a tab open, will look monday (patch piloting then) at the latest
<elias21> Hi, anybody know where can i find the upload status for ppas?
<zyga> elias21: what do you mean by upload status?
<elias21> zyga: hi, i've just uploaded my package but it no appear
#ubuntu-devel 2014-04-06
<Kalidarn> there was an ssh update recently wasn't there?
<Kalidarn> for some strange reason I cannot ssh into any of my cisco routers anymore with the ssh client on ubuntu
<Kalidarn> after this update: openssh-client:    amd64 (6.6p1-1, 6.6p1-2)
<Kalidarn> works with putty but i get connection refused with regular openssh
<Kalidarn> i've narrowed it that it must be the ssh client, because it works from other machines, and works from the same machine if i use putty
<Kalidarn> http://paste.ubuntu.com/7211115/
<Kalidarn> and i know it used to work until very recently.
<Kalidarn> seems to shut straight after debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
<Kalidarn> where as on my other machine this happens
<Kalidarn> debug2: dh_gen_key: priv key bits set: 143/256
<Kalidarn> debug2: bits set: 512/1024
<Kalidarn> debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
<Kalidarn> debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
<slangasek> Kalidarn: "connection refused" is pretty definitively not a bug in the ssh client
<Kalidarn> yeah but if it's because some sort of feature is unavailable that it wants maybe the remote host is refusing
<slangasek> and the only difference between 6.6p1-1 and 6.6p1-2 was a server configuration change
<Kalidarn> doesn't explain why it works on exactly the same machine with putty instead :P
<slangasek> no, you said "connection refused".  "Connection refused" means a failure at the tcp level
<Kalidarn> which means it's not an ACL
<Kalidarn> also ssh to other things work
<Kalidarn> eg ssh into a freebsd or linux server
<slangasek> well, I don't know why you're having problems, but it's not related to the upgrade from 6.6p1-1 to 6.6p1-2
<Kalidarn> hmm.
<Kalidarn> and initially i would have agreed and thought sure could be tcp issue something blocking it
<Kalidarn> but that does not explain why it works with putty on exactly the same system
<Kalidarn> to the same remote host
<slangasek> anyway, your pastebin shows it's not actually getting connection refused; it is getting past the initial negotiation, then the server is hanging up
<Kalidarn> yes which is why i'm rather confused
<Kalidarn> doesn't seem to like me connecting with openssh
<Kalidarn> from this machine
<Kalidarn> works with 6.2p2 from the mac
<slangasek> if it worked with 6.6p1-1, then something's changed on your server
<slangasek> and you'll need to debug it there
<Kalidarn> i reloaded the configuration file so nothign has changed there
<Kalidarn> so nothing has changed there
<slangasek> you can always try downgrading the client using the links on https://launchpad.net/ubuntu/+source/openssh/+publishinghistory to verify the last version of the client (if any) that works
<Kalidarn> i only seem to recall it being an issue today
<Kalidarn> i have a trusty vm so ill try it in that
<Kalidarn> (the downgrade) that is
<slangasek> the diff between 6.6p1-1 and 6.6p1-2 is absolutely trivial and unrelated, so if downgrading that fixes it, then we're looking at a miscompilation somewhere
<Kalidarn> that's what i'm starting to think
<Kalidarn> cos a network related issue makes no sense if it works in putty
<Kalidarn> my originating address would be exactly the same
<Kalidarn> that cisco router does have an ACL that only allows certain local IP addresses to connect (but my local IP has not changed)
<Kalidarn> and as i said I ruled that out by using a different client
<Kalidarn> is there any way of grabbing the older deb file from that page slangasek?
<slangasek> yes, you browse the links to the version you want to download
<Kalidarn> ah here we are.
<Kalidarn> okay so as to be expected that made no difference.e
<Kalidarn> although it is quite well possible i have not tried since installing trusty
 * slangasek nods
<Kalidarn> ill try booting a 13.10 vm
<slangasek> there's a RH bug report about newer openssh (6.3 and later) failing to talk to ciscos: https://bugzilla.redhat.com/show_bug.cgi?id=1026430
<ubottu> bugzilla.redhat.com bug 1026430 in openssh "OpenSSH can no longer connect to Cisco routers/switches" [Unspecified,Assigned]
<slangasek> there are some hints there about how to work around it with client options
<Kalidarn> oh :)
<Kalidarn> the description does sound relvant
<slangasek> (found by searching for '"debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP" cisco', fwiw)
<slangasek> if that turns out to be the problem, please file a bug against the openssh package in Ubuntu, referencing that one
<Kalidarn> yeah
<Kalidarn> slangasek: and i can confirm it works in 13.10
<Kalidarn> i think it might already be lodged as a bug
<Kalidarn> https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/1287222
<ubottu> Launchpad bug 1287222 in openssh (Ubuntu) "openssh-client 6.5 regression bug with certain servers" [High,New]
<Kalidarn> and yes doing that solution works slangasek
<cjwatson> slangasek,Kalidarn: I would say if there are workarounds then we should leave it at that.  I'm not at all keen on weakening the OpenSSH client's defaults due to bugs in embedded servers
<cjwatson> (well, modulo documentation perhaps)
<slangasek> cjwatson: fwiw the workaround in the RH bug indicates that you can /strengthen/ the defaults for the same result
<slangasek> (i.e., it's an issue with a buffer limit on the server for kex options, so dropping the weakest solves the problem fine)
<cjwatson> upstream's welcome to do that, but similarly this is in the class of things I Do Not Mess With in packaging
 * slangasek nods
<cjwatson> (because doing that means potentially dropping support for other systems and I don't want that to be on my head ... it's a domino trail)
<Kalidarn> cjwatson: yeah I just wrote a shell script that i run
<Kalidarn> sshCisco.sh user@host
<Kalidarn> for cisco stuff
<Kalidarn> calls ssh with the necessary options
<Kalidarn> hopefully people who start using buntu 14.04 know what is up :P
<doko_> kirkland, I see your name in a not uploaded facter-plugins tarball. can this package please removed alltogether?
<doko_> Riddell, shadeslayer_ : please merge the changes from korundum 4:4.11.3-2, we need to remove ruby1.8 in trusty
<doko_> https://bugs.launchpad.net/ubuntu/+source/korundum/+bug/1303366
<ubottu> Launchpad bug 1303366 in korundum (Ubuntu Trusty) "korundum needs to remove the ruby1.8 dependencies for trusty" [High,Confirmed]
<doko> geser, libaspectr (0.3.5-3ubuntu2) hardy ... removing now ..
<Logan_> I like how tty1 keeps logging me out as soon as I log in
<doko> Riddell, ScottK, shadeslayer_: it's really bad if you never sync the debian packaging in packages where you are always ahead of debian ...
<psusi> cjwatson_, looks like there's another bug in parted I caused by backporting the loop fixes... I called the fat and ntfs probe code from the msdos label probe code because they can be confused with an msdos mbr.. but I think the old code there can't handle !512 byte sector sizes
<ScottK> doko: We do periodically.  I'll take a look at it tonight or tomorrow if no one else does.
<doko> in this case the period seems to be >= 3 years ;p
<ScottK> Their Korundum/Qtruby packages were made from ours, so debian/changelog doesn't tell all.
<lamont> The following packages have been kept back:
<lamont>   libdb-dev
<lamont> saucy->trusty upgrade didn't get rid of it, and it's still being held back...  I wonder if we care?
#ubuntu-devel 2015-03-30
<janimo> 851256
<pitti> Good morning
<tnkhanh> do people use switch-case nowadays?
<tnkhanh> I always use if-else
<smb> hallyn, thanks
<Laibsch> micahg: do you have a minute?
<micahg> Laibsch: sure
<Laibsch> re bug 1438025. I admit to not being 100% certain about the proposed change, either. But the link you posted makes me believe that it is correct even more.
<ubottu> bug 1438025 in apt-cacher-ng (Ubuntu) "please add security.ubuntu.com to the ubuntu mirrors" [Undecided,Invalid] https://launchpad.net/bugs/1438025
<Laibsch> security.ubuntu.com is only a subset of the packages available in the true mirror network, I believe.  The purpose is to allow for quicker distribution of security-related updates.
<Laibsch> As such, anything available in security.u.c is a subset of the mirror pool.
<micahg> Laibsch: I think the idea is that individuals shouldn't be mirroring security.ubuntu.com and that the updates are actually copied to the -updates pocket within a short amount of time
<Laibsch> Correct?
<Laibsch> the proposed change wouldn't have that effect
<Laibsch> quite the opposite
<Laibsch> it would lower the burden on security.u.c
<Laibsch> at least that is my understanding and experience of acng
<micahg> isn't that list used for pre-caching
<Laibsch> nope, not at all
<Laibsch> it defines a list of equivalents
<Laibsch> so, if a package is already in the cache, then acng will not download it again if requested from a mirror
<Laibsch> let's say user A requests package P version 1.1 from de.archive.ubuntu.com. That package is now cached.  It was a security update so it's available on security.ubuntu.com as well.  User B now requests the same package, but uses security.ubuntu.com for the request.  acng will then download the file over the network one more time (and store it separately.
<Laibsch> it will NOT treat the files as equivalents, unless security.ubuntu.com is listed as a "Ubuntu mirror" (even if only partial mirror).
<micahg> interesting...I'll reopen and subscribe mdeslaur, he can help clarify this I believe as he's more familiar with acng, thanks for the followup
<Laibsch> Thanks
<Laibsch> Again, I'm certainly not 100% certain about the effects of it, either
<Laibsch> We should wait for input from upstream Eduard as well
<Laibsch> precisely, about what happens if one of the mirrors is only a partial mirror
<Laibsch> thanks, micahg. Have a nice day.
<micahg> Laibsch: thanks, you too
<tjaalton> is it just me or can't the kvm instance graphics device be changed from the gui? it just complains that the RAM option is only available for QXL (which seems to be the default on vivid)
<tjaalton> looks like virt-manager is a bit old too, could be fixed upstream so I'll just leave it at that
<zyga> hey
 * zyga still sees wlan0 being used instead of eth0 when both are active on vivid
<zyga> this is my route output http://paste.ubuntu.com/10705612/
<zyga> aww
<zyga> sill me
<zyga> that was after I turned it off
<zyga> http://paste.ubuntu.com/10705615/
<zyga> that's with wifi enabled but I think it's only true on fresh boot
<darkxst> zyga, odd, I get the opposite, like 2 default routes when both wifi and eth are active
<darkxst> that breaks just as bad though
<zyga> darkxst: that might be what I see too, this is after clicking on the indicator applet
<darkxst> zyga, ubuntu GNOME doesnt have indicator applet
<zyga> darkxst: well, it's network manager on the back too
<dholbach> good morning
<darkxst> zyga, in my case only wifi is managed by network manager
<dz0ny> zyga: remove all routes for vmnet
<zyga> dz0ny: how?
<dz0ny> route del :)
<zyga> dz0ny: I see this as a bug in one of the components of the stack, I updated from utopic a few weeks ago and that was not a problem there
<darkxst> don;t see why vmnet routes would cause an issue
<zyga> dz0ny: I can remove them but this should not need to be done each time
<zyga> dz0ny: and I think darkxst is right, traffic goes through wifi, not vmnet*
<dz0ny> vmnet1 is treated as link local
<dz0ny> i think you have some script that does that
<darkxst> dz0ny, they come from vmware
<zyga> dz0ny: vmnet are from vmware workstation,
<dz0ny> it is used to push all packets to vmware palyer
<zyga> dz0ny: though they look okay
<darkxst> may or may not be bridged depending on config
<zyga> they are on different networks
<zyga> vmnet1 is host-only, vmnet8 is nat
<dz0ny> mhm
<LocutusOfBorg1> good morning
<dz0ny> i think its vmware issue
<zyga> dz0ny: how can it be a vmware issue where all the traffic goes through wlan0?
<darkxst> dz0ny, i don't think its vmware issue, Ive seen the double default route issue on my laptop that doesnt even have vmware installed
<Riddell> mvo: so any thoughts on the apt upgrade issue we are having?
<flexiondotorg> cjwatson, Thanks for making the new release of grub-gfxpayload-lists
<mgedmin> will there be a new gfxboot-theme-ubuntu release with updated launchpad translations, before 15.04?
<Odd_Bloke> dhclient is no longer running in the background in the vivid (proposed) images I'm looking at; is this expected because of (network|system)d
<Odd_Bloke> *?
<Odd_Bloke> (It did run at boot; it has output in the journal)
<Odd_Bloke> pitti: ^?
<pitti> Odd_Bloke: no, not expected; but systemd just calls /etc/init.d/networking start, so might be a more recent change in ifupdown or dhclient?
<Odd_Bloke> Ack; I'll have a poke around.
<pitti> Odd_Bloke: I have dhclient -1 on current vivid cloud images
<pitti> (for eth0)
<pitti> and we don't use networkd, at least it has never been discussed and it'd be rather late trying to integrate it now
<flexiondotorg> cjwatson, Is it possible to specific a particular version of a package for a given architecture in a seed?
<flexiondotorg> *specify
<dz0ny>   695 ?        Ssl    0:01 /usr/sbin/NetworkManager --no-daemon
<dz0ny>   788 ?        S      0:00  \_ /sbin/dhclient -d -q -sf /usr/lib/NetworkManager/
<dz0ny>   792 ?        S      0:01  \_ /usr/sbin/dnsmasq --no-resolv --keep-in-foregroun
 * dz0ny vivid
<pitti> flexiondotorg: no, that wouldn't make much sense -- if the version matches the archive it's redundant, and if it doesn't match you couldn't build an image at all
<flexiondotorg> pitti, OK.
<flexiondotorg> pitti, I only ask because Xorg is completely busted for PowerPC since the recent update. I wanted to try reverting in the image build.
<pitti> flexiondotorg: we can't do that, as the previous version isn't even in the archive any more
<cjwatson> Experimentation like that is better done locally.
<flexiondotorg> cjwatson, Yeah, we are doing. I was just try to find an easier for testers to help.
<flexiondotorg> pitti, Have you seen anything like this? - https://bugs.launchpad.net/ubuntu/+source/mate-settings-daemon/+bug/1437722
<ubottu> Launchpad bug 1437722 in mate-settings-daemon (Ubuntu) "ubuntu MATE 15.04: mate-settings-daemon problem with systemd" [Undecided,New]
<flexiondotorg> pitti, I can't reproduce on i386, amd64 or armhf.
<flexiondotorg> pitti, Is systemd-shim still required in 15.04?
<pitti> flexiondotorg: no, I haven't seen that; we use upstart for the session, so that shouldn't change (and sudo systemctl org.mate.settingsd.service wouldn't make sense)
<pitti> unless mate actually does use systemd for the session?
<pitti> flexiondotorg: no, we don't need shim if you run with systemd
<dz0ny> systemctl start org.mate.settingsd.service --user ?
<pitti> but we still want to support booting with pstart
<dz0ny> isn't that user service?
<pitti> yes, it is for sure
<flexiondotorg> pitti, OK. indicator-datetime Depends on systemd-shim
<flexiondotorg> pitti, Which is why I asked if it was required because I couldn't figure out why it is installed.
<flexiondotorg> pitti, Regarding systemd, MATE really only uses logind, if it is available.
<pitti> flexiondotorg: uh, indicator-datetime still depends on systemd-services; that's gone since at least trusty
<flexiondotorg> pitti, The systemd delay in startup seem to be attributed to audio in the forum dicussion.
<Odd_Bloke> pitti: It looks like systemd 219-5ubuntu1 is the cause of dhclient no longer running in the background; it's the only relevant change in the image in which we started seeing the problem: http://cloud-images.ubuntu.com/vivid/20150327.3/unpacked/vivid-server-cloudimg-amd64-20150327.2-to-20150327.3-manifest.diff
<pitti> Odd_Bloke: ok; would you mind filing a bug with the details? it's running here with today's cloud image, so it's not entirely obvious to me what you mean
<Odd_Bloke> pitti: As in `pgrep dhclient` returns something/
<Odd_Bloke> *?
<Odd_Bloke> I am really struggling with question marks today.
 * pitti tosses a shift key to Odd_Bloke
<pitti> yes, I have dhclient -1 running, as expected
<pitti> Odd_Bloke: can I sees the image version in the installed systemd anywhere?
<pitti> argh, and I can't write "system" any more for the life of me
<ogra_> pitti, just use the phone kbd, it reliably turns it into systems
<Odd_Bloke> Yes, you just query ubuntucloudimageversiond. ;)
<Odd_Bloke> pitti: /etc/cloud/build.info
<pitti> build_name: server
<pitti> serial: 20150328.1
<pitti> root       464  0.0  0.3  23468  7784 ?        Ss   13:28   0:00 dhclient -1 -v -pf /run/dhclient.eth0.pid -lf /var/lib/dhcp/dhclient.eth0.leases eth0
<pitti> that's for /etc/network/interfaces.d/eth0.cfg
 * pitti -> lunch, bbl
<Odd_Bloke> pitti: Hmm, I'm not seeing it running in the GCE image built from that cloud image; I'll see if there's anything GCE-specific we're doing that might be messing things up.
<Odd_Bloke> But lunch does sound like a good idea.
<ari-tczew> can someone help with FTBFS on openblas? It's blocking other packages due to dep-waiting. https://launchpadlibrarian.net/200241214/buildlog_ubuntu-vivid-ppc64el.openblas_0.2.12-1ubuntu1_BUILDING.txt.gz
<ari-tczew>  /usr/bin/ld: ../libopenblas_power6p-r0.2.12.a(dcabs1.o): ABI version 1 is not compatible with ABI version 2 output
<tjaalton> so using a tmpfs overlay dir for sbuild seems to break with systemd or so, since it mounts a new tmpfs on top of /dev/shm every time sbuild is run :)
<Odd_Bloke> pitti: How are you launching your system with running dhclient?  I haven't managed to get a running dhclient in any of the environments I've tried.
<pitti> Odd_Bloke: just with qemu, nothing extraordinary
<pitti> $ kvm -net nic,model=virtio -net user -snapshot /srv/vm/adt-vivid-amd64-cloud.img
<pitti> (I usually have some ssh port redirection, -m, virtio drive etc., but those should hardly matter, and it works like this
<pitti> kvm -snapshot /srv/vm/adt-vivid-amd64-cloud.img
<pitti> works with this, too
<cyphermox> good morning!
<mvo> Riddell: hi, sorry for the slow reply, I was trying to reproduce this in a chroot, but failed to trigger the bug with apt-get dist-upgrade --simulate, I try again with a real upgrade now (still chroot). if that does not trigger it I need to create a kubuntu install
<Riddell> thanks mvo
<Riddell> if I need to just remove the baloo4 package I can probably do that fine
<mvo> Riddell: I have no idea right now, sorry. definitely a apt bug though
<mvo> Riddell: still, we probably want to workarond it once its better understood
<happyaron> mvo: "workarond" get my irssi highlights me, lol
<mvo> Riddell: fun, I can not reproduce in a chroot with ubuntu-{minimal,standard}, kubuntu-desktop installed, looks like i need to try harder (i.e. upgrade works just fine)
<mvo> happyaron: haha
<Riddell> meh
 * zyga wonders how to use the company vpn alongside local dns server
<ogra_> very carefully ...
<arges> hallyn: re: bug 1432644, i may need to try a completely clean vivid install, this is my laptop that's been incrementally upgraded since utopic. but at the moment i'm unable to use uvtool to install VMs and that error message was all I had to go by.
<ubottu> bug 1432644 in libvirt (Ubuntu) "VM permanently tries to read /dev/shm/lttng-ust-wait-5" [High,Fix released] https://launchpad.net/bugs/1432644
<arges> i'll upgrade to the latest libvirt and re-try
<tjaalton> hmm, commenting /dev/shm out from /etc/schroot/sbuild/fstab fixes the tmpfs overlays, wonder if that's a proper fix though
<jamespage> arges, hallyn: let me know if you want me to disable the lttng integration in ceph - it appears to be making more problems that it solves right now
<shadeslayer> ogra_: ping
<ogra_> shadeslayer, yo
<shadeslayer> ogra_: can we get a armhf tarball going on for Kubuntu vivid?
<shadeslayer> or whom should I talk to about that
<shadeslayer> I wrote this generic tool that can make RasPi2 images
<ogra_> perferably someone from foundations, you will need to send patches fro the build system though
<shadeslayer> hm ...
<shadeslayer> ogra_: https://github.com/rpi2-stuff/image , maybe you'd be interested in it for Ubuntu
<ogra_> unless oyu only want a rootfs tarball
<shadeslayer> https://github.com/rpi2-stuff/image/blob/master/config/vivid.yml
<shadeslayer> ogra_: I only want a rootfs tarball
<arges> jamespage: I'll let hallyn decide, but I don't use the LTTng integration for ceph and it seems like something that should be optional since it would mostly be used for developers
<ogra_> shadeslayer, that should be relatively straightforward
<shadeslayer> right, so whom do I talk to :)
<ogra_> mvo, ^^^ who does image stuff for distro nowadays ?
<arges> hallyn: also my problem wasn't starting VMs it was creating a _new_ VM via 'uvt-kvm create' maybe try that too
<ogra_> (i know you do snappy ... but i guess there is someone for general distro and flavour stuff)
<jdstrand> tyhicks: hey, what is the status of cache loading for vivid?
<jdstrand> tyhicks: I ask cause if it isn't going to land, someone needs to fix this:
<jdstrand> 1 processes are unconfined but have a profile defined.
<jdstrand>    /sbin/dhclient (634)
<tyhicks> jdstrand: we're still trying to nail down a detail in the libapparmor API
<tyhicks> jdstrand: I'm working on that now
<tyhicks> jdstrand: then the systemd changes need to happen
<tyhicks> jdstrand: I'm thinking that it is all happening a bit too late to land in Vivid
<jdstrand> tyhicks: I think I agree-- but we should land it as soon as 'w' opens
<tyhicks> (when I said that "I'm working on that now", I meant that I'm working on the libapparmor API details and not the dhclient bug)
<tyhicks> jdstrand: yeah, it'll definitely be ready then
<tyhicks> jdstrand: do you have the dhclient bug # handy?
<jdstrand> pitti: I'm filing it now
<jdstrand> err
<jdstrand> tyhicks: ^
<tyhicks> oh
<jdstrand> tyhicks: fyi, I updated bug #1385414 to reflect what you said above. filed bug #1438249 for dhclient
<ubottu> bug 1385414 in AppArmor "provide systemd compatible cache loading library" [Critical,In progress] https://launchpad.net/bugs/1385414
<ubottu> bug 1438249 in systemd (Ubuntu) "/sbin/dhclient is unconfined after switch to systemd (aka, equivalent of upstart's network-interface-security.conf not implemented)" [Critical,Triaged] https://launchpad.net/bugs/1438249
<jdstrand> tyhicks: I'm not sure what the best solution is for bug #1438249-- perhaps discuss with pitti?
<jdstrand> pitti: hi! :)
<tyhicks> pitti: hello - if you have any initial thoughts on how to address 1438249, please let me know. I'll come up to speed on what network-interface-security.conf does in the meantime.
<pitti> hey tyhicks
<pitti> tyhicks: I'll have a look and respond to the bug
<awe_> seb128, hey question for you... every so often on utopic, my desktop freezes during a hangout.  I have a working cursor, and audio, but everything is frozen such that I need to hard-power off my system
<awe_> any suggestions for where I should file and bug and/or debug the problem?
<seb128> awe_, hey, can you go to a vt in those cases?
<awe_> hhhh, didn't try that...
<seb128> I would start there
<seb128> if you can, try to kill compiz
<seb128> it might the wm being locked
<awe_> everything else is frozen hard thought ( indicators, window controls, ... )
<awe_> compiz still lives???
<seb128> right
<awe_> sigh...
<seb128> could be xorg
<seb128> could be compiz
<seb128> could be the input stack/kernel
 * awe_ remember his first Canonical all-hands-meeting where we did a mock technical board session about including compiz by default
<awe_> seb128, ack
<awe_> thanks for the suggestion
<seb128> yw!
<pitti> tyhicks, jdstrand: responded to the bug, WDYT?
<shadeslayer> ogra_: btw out of curiosity, any particular reason why ubuntu-standard isn't installed in the core armhf tar?
<ogra_> shadeslayer, to big ... not needed for embedded
<shadeslayer> I see
<ogra_> we dont use it in the phone images either
<shadeslayer> oh I see
 * shadeslayer checks if his modifications work
<ogra_> (which costs a price though ... extra maintenance and seed management for bit we actually want)
<ogra_> *bits
<shadeslayer> true enough
<shadeslayer> ogra_: my script adds a user to the image it builds, but turns out there is no sudo on the rootfs
<shadeslayer> so I can't effectively do much :p
<rbasak> pitti: strikov and I are confused about bug 1409639. Why do you say Fix Committed in Vivid?
<ubottu> bug 1409639 in juju-core (Ubuntu Vivid) "juju needs to support systemd for >= vivid" [High,Fix committed] https://launchpad.net/bugs/1409639
<pitti> rbasak: the fix landed in trunk apparently?
<jdstrand> pitti: sorry was in a meeting. responded in the bug
<rbasak> pitti: trunk upstream, but it won't be landing in Ubuntu for a while. Needs a major version bump for a version that isn't released yet.
<rbasak> pitti: so I think upstream task Fix Committed makes sense, but not Ubuntu task as we'll be doing uploads that don't include the support in the interim.
<pitti> rbasak: ok; I don't mind much  (that's how I use "fix committed" -- as soon as the fix lands in trunk)
<rbasak> pitti: I wasn't aware of that use. No worries. I don't mind either.
<rbasak> (now I understand that use exists :)
<pitti> rbasak: please use the states as you usually do within juju, I don't want to step on your toes
 * pitti waves good night
<mvo> Riddell: still no luck, did a fresh 14.10 kubuntu install in a VM, then upgraded to vivid (amd64), no error
<Riddell> mvo: um really?
<Riddell> mvo: I'll give it another go tomorrow, maybe it magically fixed itself since beta came out
<mvo> Riddell: hm, maybe I'm wrong, it looks like its incomplete, let me try again
<mvo> Riddell: same result, 14.10 kubuntu/amd64 -> 15.04 dist-upgrade, no error, sorry
<infinity> mvo: Did you mean to add ubuntu to a bunch of groups in that livecd-rootfs upload?
<infinity> mvo: The changelog doesn't mention it.
<mvo> infinity: yes, sorry, I should have documented that, I can double check tomorrow though
<infinity> mvo: Well, I'm less fussy about the changelog mentioning it (though that would be nice) and was mostly concerned that it was an accident, since adding a user to a couple of priviledged groups seems like the sort of thing one wouldn't want to do by accident. :P
<mvo> infinity: oh, I see. the ubuntu user is already part of sudo,docker this is just moving it into a different place, there is a existing 02-add_user_to_groups.chroot that does that. my mistake for not documenting that properly :/
<infinity> mvo: Oh, so did this make 02-add_user_to_groups.chroot obsolete, or do you now do it twice? :P
 * infinity also thinks that syslog user's $HOME is rather suspiciously wrong, but that's not your fault.
<mvo> infinity: *cough* twice!
 * mvo adds a todo to fix that
<infinity> mvo: *smirk*.  Alright, letting it in anyway, assuming that's a no-op and doesn't break.
<mvo> infinity: its tested in our PPA, so it should not break(tm) :)
<infinity> (base)root@cthulhu:~# adduser adconrad sbuild
<infinity> The user `adconrad' is already a member of `sbuild'.
<infinity> (base)root@cthulhu:~# echo $?
<infinity> 0
<infinity> Yeah, looks like it'll work fine.
<infinity> Just a pointless extra bit.
<infinity> pitti: Can we, I dunno, make the systemd autopkgtests actually pass?  You're setting a bad example for everyone else. :P
<shadeslayer> mvo: who's in charge of the foundation bits for flavor images ?
#ubuntu-devel 2015-03-31
<dholbach_> good morning
<pitti> Good morning
<pitti> infinity: yes, on my list to investigate; seems a recent lightdm change during my holidays broke something, but so far I was still caught in backlog
<pitti> bdmurray: does errors.u.c. still use -security indexes from ddebs.u.c.? I'd really like to remove them as they are way out of date and confusing to users
<pitti> Unit193: hey, how are you?
<pitti> Unit193: I'm looking at bug 1431200, and it seems I can't reproduce this any more; can you?
<ubottu> bug 1431200 in systemd (Ubuntu) "daemon-reload runs alsa-restore.service and others" [High,In progress] https://launchpad.net/bugs/1431200
<Riddell> mvo: I still get the problem :(
<Riddell> mvo: how do I tell ubuntu-bug to upload all the logs?
<mvo> Riddell: what base system do you use? anything beyond a stock install of kubuntu 14.10 (this is what I did)?
<mvo> Riddell: how did you upgrade, apt itself or a frontend?
<Riddell> mvo: stock install of 14.10 (no internet during install)
<Riddell> then running /usr/bin/kubuntu-devel-release-upgrade which is a 1 line script to run 'kdesudo "do-release-upgrade -m desktop -f DistUpgradeViewKDE -d"'
<mvo> Riddell: ok, let me try that then, I was doing a normal apt-get dist-upgrade
<Riddell> mvo: you do know we don't support that right? :)
<Riddell> hah seems ubuntu-bug doesn't work anyway because I broke apport, best look at that first :)
<pitti> Riddell: QApplication import failure?
<pitti> I still get that (see https://bugs.launchpad.net/ubuntu/+source/apport/+bug/1436328/comments/3)
<ubottu> Launchpad bug 1436328 in apport (Ubuntu) "FFe apport-kde qt5 port" [Undecided,Fix released]
<Riddell> pitti: failure at "from PyQt5 uic" which I had thought I'd fixed
<Riddell> and I'd expect to have been picked up by pyflakes or something
<pitti> Riddell: that's fixed in 2.17-0ubuntu1, uploaded this morning
<pitti> Riddell: but I still get an import error on QApplication, apparently python3-pyqt5 isn't sufficient
<pitti> Riddell: oh, hmm -- calling apport-kde here actually works now, but the test does
<pitti> --- Testing ui_kde ---
<pitti> SKIP: PyQt/PyKDE not available: cannot import name 'QApplication'
 * Riddell installs to try it
<pitti> ah!
<pitti> from PyQt5.QtGui import QApplication, QTreeWidget, QIcon
<pitti> that ought to be QtWidgets
<pitti> Riddell: so just a bug in test/test_ui_kde.py, I'll fix
<Riddell> thanks pitti
<Riddell> I still can't work out how to report a bug on the release upgrade tool
<pitti> Riddell: done in http://bazaar.launchpad.net/~apport-hackers/apport/trunk/revision/2938
<pitti> Riddell: so vivid is fine now, and the tests will be fixed with the next upload (not urgent)
<Riddell> yay
<tseliot> pitti: is it possible that systemd stops gpu-manager before it can finish?
<pitti> tseliot: what do you mean? killing it on shutdown?
<tseliot> pitti: even on boot
<pitti> tseliot: if an Exec* command like ExecStop= doesn't finish in 90 seconds (by default), it gets killed, yes
<tseliot> pitti: for example, I see that gpu-manager writes the log saying that xorg.conf was written but then I can't find the file at times
<pitti> if a unit fails to start in in 90s, it gets marked as failed, but it doesn't kill anything then
<tseliot> pitti: in this case the unit started but I don't think it took 90 seconds to finish
<pitti> tseliot: easy enough to tell with "systemctl status gpu-manager"
<tseliot> pitti: ah, I'll try that, thanks
<flexiondotorg> pitti, This is is not fixed in 15.04 for all flavours - https://bugs.launchpad.net/ubuntu/+source/ecryptfs-utils/+bug/953875
<ubottu> Launchpad bug 953875 in ecryptfs-utils (Ubuntu Vivid) "Encrypted swap no longer mounted at bootup" [High,Fix released]
<flexiondotorg> pitti, More over boot is significantly delayed while mounting crypted swap tries and fails.
<flexiondotorg> pitti, What can I do to help gather useful information/
<pitti> flexiondotorg: can you please reopen with a current /etc/crypttab, /etc/fstab, and blkid output?
<flexiondotorg> pitti, So branch new bug?
<flexiondotorg> *brand new
<xnox> pitti: https://github.com/juju/juju/commit/2ae93fe45df4b95bedf493adc07ee7049859fb2d is not that good. Checkout out the "shell script" to detect what is pid1.
<pitti> flexiondotorg: reopening is fine
<xnox> pitti: i've commented on it, but imho it still doesn't look trust worthy that juju has systemd support for ubuntu.
<pitti> xnox: eek, yues
<pitti> testing /run/systemd/system is correct, thanks for pointing that out there
<flexiondotorg> pitti, I don't appear to be able to change the bug status.
<xnox> pitti: please raise that further up to relevant people, e.g. gaughen ?
<pitti> flexiondotorg: just follow up with the info then, I'll reopen; thanks!
<flexiondotorg> pitti, I'll gather the info.
<xnox> pitti: and it uses well known temp file.... /tmp/discover_init_system.sh it is security vulnerability right there as well.
<flexiondotorg> pitti, I've added what you requested.
<pitti> flexiondotorg: thanks, reopened
<flexiondotorg> pitti, When I initially test Ubuntu MATE with systemd I mentioned to you that there was no option to eject the media after an install.
<flexiondotorg> pitti, That bug was identified during beta 2 QA and partly fixed.
<pitti> flexiondotorg: I believe cyphermox is working on that
<flexiondotorg> pitti, No it ejects but the system hard locks and since that part fixed was introduced oem-config is somewhat broken.
<flexiondotorg> pitti, Yeah, I've been trying to help cyphermox and wondered if you might be able to lend a hand?
<pitti> he said he's going to ping me this evening about some stuff he wanted to discuss
<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 lucid -> utopic | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: mdeslaur
<debfx> mdeslaur: could you please have another look at bug #1230917? I've attached a debdiff.
<ubottu> bug 1230917 in php5 (Ubuntu Trusty) "[SRU] php5-fpm logrotate errors after package switched to upstart" [High,Triaged] https://launchpad.net/bugs/1230917
 * mdeslaur looks
<debfx> the version needs to be bumped because of the last security update
<debfx> apart from that the debdiff should still apply
<flexiondotorg> pitti, I've updated https://bugs.launchpad.net/ubuntu/+source/ecryptfs-utils/+bug/953875 with just the systemd logs from syslog. Looks useful.
<ubottu> Launchpad bug 953875 in ecryptfs-utils (Ubuntu Vivid) "Encrypted swap no longer mounted at bootup" [High,Confirmed]
<mdeslaur> debfx: uploaded, thanks
<LocutusOfBorg1> Hi dholbach any news about 1424769 ?
<LocutusOfBorg1> nobody replied to me, I don't know how to proceed
<dholbach> seb128, ^ do you maybe know who could help with this?
<LocutusOfBorg1> I'll write again, I would like to have a sponsor for the new virtualbox-lts-utopic package, which is ready for trusty (built against never xorg-lts and mesa-lts)
<dholbach> maybe you could send a mail to ubuntu-devel@ about it too?
<LocutusOfBorg1> I can do whatever you ask me, I would just like to avoid spamming :)
<dholbach> don't worry about it
<dholbach> you're not spamming
<seb128> bug #1424769
<ubottu> bug 1424769 in virtualbox (Ubuntu) "virtualbox-guest-x11 uninstallable with mesa-lts-utopic" [Undecided,Confirmed] https://launchpad.net/bugs/1424769
<LocutusOfBorg1> mail sent on -devel
<seb128> LocutusOfBorg1, dholbach, is that a duplicate of bug #1424466?
<ubottu> bug 1424466 in mesa (Ubuntu Trusty) "Devel package not installable in 14.04.2 (mesa-lts-utopic" [High,Fix released] https://launchpad.net/bugs/1424466
<seb128> that got fixed a week ago
<LocutusOfBorg1> I need to test it then :)
<LocutusOfBorg1> the problem however was also with xorg
<cyphermox> flexiondotorg: please don't mix the oem-config and eject problems, they are separate, different issues
<flexiondotorg> cyphermox, OK.
<cyphermox> pitti: so, yeah, I've been fighting systemd unit files for a bit trying to figure out how to put things in the right place so they'd work correct, I think I have something that works for oem
<cyphermox> but there are some complications with the ejection of the CD on shutdown, from the installer. Looks like plymouth is what is freezing up, unable to get the input to catch the enter key, but it's also possible this is happening (and more visible on qemu) because the input and screen are still used by lightdm/X
<LocutusOfBorg1> seb128, nack
<cyphermox> pitti: do you have a suggestion on what would be the best way to get a script to run very late on shutdown, after plymouth is started but before the system reboots or halts? for now I have Before=shutdown.target reboot.target halt.target, WantedBy=shutdown.target
<LocutusOfBorg1>   virtualbox-guest-x11 : Depends: xorg-video-abi-15
<LocutusOfBorg1>                         Depends: xserver-xorg-core (>= 2:1.14.99.902)
<LocutusOfBorg1> seems still problematic
<cyphermox> hmm. now I can't remember if I tried adding After=display-manager.service Conflicts=display-manager.service
<pitti> cyphermox: display-manager should be kept out of this IMHO
<pitti> cyphermox: shouldn't that be WantedBy=halt.target, and After=plymouth-halt.service (and the same for reboot/poweroff)?
<pitti> cyphermox: similar to plymouth-halt.service itself?
<cyphermox> I believe I tried that too, and it didn't really work any better
<cyphermox> pitti: lemme just test this one thing first
<cyphermox> pitti: can I have this without having to duplicate the jobs like plymouth-halt, plymouth-reboot, etc.?
<pitti> cyphermox: you can have multiple WantedBy= lines
<pitti> (or three targets in one WantedBy)
<cyphermox> hrm, alright, just making sure
<shadeslayer> cjwatson: pingly
<shadeslayer> cjwatson: Could you possibly add a kubuntu-armhf target which generates a rootfs tar like ubuntu-core?
<cjwatson> shadeslayer: Unlikely to have time at the moment, I'm afraid.  Hopefully somebody like infinity or mvo can help you
<shadeslayer> would be nice :)
 * shadeslayer creates tarball for debian manually meanwhile
<Unit193> pitti: Noticed the netbook didn't hit 1431200, but the computer I reported that about did last I remembered.  I'll try it again, and if so try after a reboot.
<bdmurray> pitti: no, it doesn't look like it
<bdmurray> mvo: could you upload unattended-upgrades?
<sidi> Laney, hiya, are you the person who built the glib2.0 Ubuntu packages?
<pitti> apw: I have a better fix proposed in bug 1438612; I'd appreciate if you could give it a spin?
<ubottu> bug 1438612 in dbus (Ubuntu) "remote file systems hang on shutdown, D-BUS stops too early" [High,Confirmed] https://launchpad.net/bugs/1438612
<mvo> bdmurray: yes
<bdmurray> mvo: thanks
 * shadeslayer looks at mvo with puppy dog eyes
<shadeslayer> mhall119: we have a thing in a few mins right?
<mvo> shadeslayer: hm? oh, tarball, I'm in a meeting right now, what exactly you need, a tarball?
<shadeslayer> mvo: ubuntu-core tarball + kubuntu-desktop^ more or less
<mhall119> shadeslayer: in an hour and a few minutes, I've been told
<shadeslayer> oh right
<shadeslayer> 1600 UTC
<shadeslayer> not 1500
 * shadeslayer goes back to blasting music
<mhall119> shadeslayer: yeah, DST changes have thrown me off too
<shadeslayer> Yeah, quite annoying
<shadeslayer> I keep wondering why it's still so bright at 7 PM
<ericsnow> pitti, xnox: thanks for the feedback on the juju init system code
<pitti> ericsnow: I just replied again (explanation of the vulnerability, and how to simplify this)
<ericsnow> pitti: thanks
<ericsnow> pitti: the presence of /run/systemd/system doesn't guarantee systemd is running (PID 1), does it?
<pitti> ericsnow: it does; as I said, that's the officially blessed way to check if you run systemd
<mbiebl> http://www.freedesktop.org/software/systemd/man/sd_booted.html
<ericsnow> pitti: k
<pitti> ericsnow: note that checking readlink /sbin/init is not robust
<pitti> ericsnow: e. g. you could have upstart running, install systemd-sysv, and then your code would wrongly say "systemd is running"
<pitti> ericsnow: or vice versa, with running systemd and installing upstart-sysv
<ericsnow> pitti: what a pain
<ericsnow> pitti: thanks for following up on this
<pitti> ericsnow: yeah; I still think that "ssh remote.server test -d /run/systemd/system" should do exactly what you need, with minimum effort and avoiding writing tmp files
<ericsnow> pitti: we have to run something similar for upstart as well
<pitti> ericsnow: I mentioned some initctl command in the comment
<ericsnow> pitti: k
<pitti> $ initctl --system list >/dev/null 2>&1; echo $?
<pitti> 1
<pitti> ^ on a systemd syste
<pitti> m
<pitti> and it shoudl succeed on upstart
<ericsnow> pitti: thanks, that helps
<pitti> ericsnow: although we only really support systemd or upstart; you can't install anything else
<ericsnow> pitti: sure, but we are getting juju working on other platforms too :)
<pitti> ericsnow: ah, right
<ericsnow> pitti: and I've heard that docker does it's own init system
<infinity> In its purest form, docker doesn't do init systems at all, since the containers are single applications.  Or, you could say docker *is* the init system, depending on whether your world view is inside or outside the container.
<ericsnow> infinity: good point
<doko> zul, jamespage: any idea about the swift autopkg test failure?  my change to python-greenlet was only to fix the powerpc build, which should be unrelated to the amd64 build
<jamespage> doko, will look
<jamespage> doko, I think this was the issue with the missing service file - despite the fact we don;t have then in swift
<doko> ahh
<pitti> infinity, kees, stgraber, slangasek, mdeslaur: TB meeting now-ish, right? (even though we have an empty agenda)
<mdeslaur> pitti: yep!
<pitti> mdeslaur: wow, I got the time right even right after DST change :)
<slangasek> indeed
<jamespage> pitti, are any extra steps requires in packages which just ship init files to work with systemd?
<jamespage> pitti, "Failed to restart swift-proxy.service: Unit swift-proxy.service failed to load: No such file or directory."
<pitti> jamespage: as long as the init.d script works, no
<jamespage> init script is present and should work
<mdeslaur> pitti: hehe :)
<pitti> jamespage: systemctl status swift-proxy.service says "not found" too, I presume?
<jamespage> pitti, yes
<jamespage> (Reason: No such file or directory)
<jamespage> pitti, if I do a daemon-reload, systemd sees the init script
<pitti> jamespage: right, but update-rc.d defaults should call that
<jamespage> pitti, oh wait - all of the dh_installinit calls are done with --no-start
<pitti> ah, it's invoke-rc.d which does the daemon-reload
<pitti> update-rc.d only does daemon-reload for actual .service units, not for init.d scripts
<debfx> mdeslaur: thank you
<jamespage> pitti, that does not sound quite right
<pitti> jamespage: so, if we need this to work with --no-start, we could fix update-rc.d to also call daemon-reload
<jamespage> pitti, installing init files, and then not starting the daemon is not that common but is the case here - swift needs lots of config
<jamespage> pitti, I guess that would work
<pitti> jamespage: right, which is why it hasn't come up yet
<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 lucid -> utopic | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<ricotz> chrisccoulson, hi
<ricotz> chrisccoulson, did you notice the GCC bump to 4.7 for firefox beta? seems to be a problem for precise
<chrisccoulson> ricotz, yeah, we discussed it before they made the change
<chrisccoulson> ricotz, https://launchpad.net/~ubuntu-mozilla-security/+archive/ubuntu/ppa/+sourcepub/4870120/+listing-archive-extra
<ricotz> chrisccoulson, i see, i guess an official gcc backport wont work
<ricotz> but yeah, this seems like a clean way
<ricotz> chrisccoulson, maybe name it a bit more generic? since this would help building libreoffice too
<infinity> ++ExecStop=/bin/true
<infinity> ++KillMode=none
<infinity> pitti: ^-- Gross, is there really no better systemd declarative way to do that?
<pitti> infinity: there are several ways (see the upstream bug that I opened), but I'd like to discuss a "proper" solution with upstream first
<infinity> pitti: Fair enough.
<pitti> infinity: I also tested this with shifting around the boot order and it worked for me; but these are notoriously prone to causing dependency cycles, hence that quick fix to stop annoying people until we have a better fix
<pitti> infinity: like, starting it earlier/stopping it later coudl again cause dependency loops with /usr or /var on NFS and the like (it shouldn't, but at this point in the release cycle I rather don't want to completely shift this around)
<pitti> infinity: but it's actually not that evil -- stopping/restarting dbus has never ever worked
<pitti> it brings down your whole session and half of the plumbing services
<infinity> pitti: Sure.  I noted a little while ago that since the upstart->systemd move, we're stopping way too many services anyway.
<pitti> infinity: so if I had any PR/marketing skills, I could sell this as a safety measure or so :)
<infinity> pitti: Many years ago, keybuk went through our shutdown sequence and neutered everything that didn't *need* a clean shutdown, we seem to have lost all that, and my laptop has gone from 2s shutdowns to 30s shutdowns.
<pitti> infinity: heck, 30s? it should be 5 or so
<pitti> anything beyond that is an actual bug
<infinity> pitti: Anyhow, I wasn't referring to "not stopping dbus" as being icky, it was the specific "ExecStop=/bin/true" which looked hackish. :)
<pitti> and with all the things that are currently complaining about "OMG my dbus went away" this might actually help your's too :)
<pitti> infinity: ah, I see; I acutally think KillMode=none should suffice
<infinity> pitti: Having to fork /bin/true for a no-op feels a lot like a gap in the declarative config syntax.
<infinity> pitti: But, yeah, I guess you can experiment over time, accepted for now.
<Laney> pitti: interesting, wonder if this fixes my shutdown hang
<pitti> infinity: yeah, as we come closer to the release with Easter holidays and an extra sprint, and so many bugs to address still, I guess I'm more and more prone to stopping debugging after half a day when I found some solution that got confirmed to work; sorry ..
<pitti> (at least I did start discussing it with upstream, to clean up in the future)
<pitti> but oh well, kdbus will save us all :)
<infinity> pitti: Heh, that's fine, as long as there's a running list of hacks to revisit somewhere on your desk.
<infinity> pitti: Forking true is hardly the worst of our problems. :P
<pitti> infinity: yeah, there is; it's not that bad still, there's only three hacks that make me want to put a paperbag on, the rest was quite okay
<pitti> (that dbus one, disabling one systemd test because I can't reproduce the jenkins failure for the live of me, and the workaround for bug 1423811); but they are all tracked
<ubottu> bug 1423811 in systemd "219-1ubuntu1 regression: boot hangs, logind fails" [Undecided,New] https://launchpad.net/bugs/1423811
<infinity> pitti: After this dbus lands, I'll retest my laptop's shutdown a bit, and see how things fare.
<pitti> infinity: FTR, /usr/share/doc/systemd/README.Debian "Debugging boot/shutdown problems"
<infinity> pitti: I'm positive that it won't be as fast as our upstart "don't actually stop anything unless it actually needs to fsync/close" sequence, but I agree that 30s can't be right.
<pitti> yeah; so far we spent zero time on making things efficient, just making them work, and pretty much copying upstart scripts 1:1 and such
<pitti> infinity: that's pretty much what happens, though -- stopping a service is pretty much "kill the whole cgroups" for most stuff (i. e. everything without an explicit ExecStop=)
<pitti> my VMs poweroff in a split second
<pitti> and my desktop in < 5, just sometimes modemmanager hangs
<pitti> (but that sounds like another fallout of the above dbus issue)
<infinity> pitti: Well, my laptop has a very slow and VERY fragmented disk, so that amplifies a lot of bugs.  Like I said, I'll see how things look after an upgrade to the new dbus, and whine at you later if it still seems unforgivably crap.
<pitti> infinity: sounds like a plan
<pitti> with that, /me waves good night; with that headache I won't be much useful any more today
<infinity> 'Night.
 * infinity throws pain killers at pitti.
<roaksoax> stgraber: do you maintain http://images.linuxcontainers.org//meta/1.0/index-system ?
<stgraber> yep
<roaksoax> stgraber: is it down?
<roaksoax> stgraber: doesn't seem accessible
<stgraber> roaksoax: hmm, appears to be hanging at the moment, let me check
<roaksoax> stgraber: thanks!
<stgraber> fixed
<stgraber> apache 2.4 being unhappy again... I really need to track down that bug
<roaksoax> stgraber: awesome! thanks!
<Riddell> tseliot: are you the dude who knows about nvidia-prima? how do I know if it's working with sddm? (I have no hardware)
<Riddell> tseliot: you seem to have removed my sddm alternate addition :(
<Riddell> mvo: any luck on bug 1426132 ?
<ubottu> bug 1426132 in apt (Ubuntu) "baloo is not replaced by baloo-kf5 on dist upgrade breaking release-upgrade" [Critical,Triaged] https://launchpad.net/bugs/1426132
<mvo> Riddell: yes, I reproduced it
<Riddell> that's good I suppose :)
<mvo> Riddell: it is, I might even have a idea for a workaround, testing this just takes a awful amount of time
<mvo> Riddell: I uploaded a potential fix, it worked locally, but lets see if it works once uploaded :)
<Noskcaj> What packages still need rebuilding for osm-gps-map to migrate?
<Noskcaj> gpxviewer should probably be RMed, like in debian
<xnox> ubottu: help me test
<ubottu> xnox: I am only a bot, please don't think I'm intelligent :)
<AdvaitaZen> Suggestion: With a mouse, the side bars should be like auto-hide... or there should be a toggle to drag.... long drags don't seem to function at all for mice. Hard to try the desktop when you can't get past the tutorial...
<dobey> i literally have no idea what that was about
<ericsnow> pitti: you still around?
<ericsnow> cherylj: did I just see the last 1.23 fix merge for the LICENCE files? :)
<cherylj> ericsnow: yes, just have to do master!
<ericsnow> cherylj: sweet!
<sarnold> dobey: I suspect advaitazen's comments is similar to this from #ubuntu-desktop: < rcarlos> has anyone skipped unity8 intro tutorial on desktop next ?
<tseliot> Riddell: I don't recall doing that. Maybe send me an email to refresh my memory?
<tseliot> Riddell: oh, you did. I'll get back to you in the morning
#ubuntu-devel 2015-04-01
<pitti> good morning
<pitti> cking: good morning!
<cking> hi there
<pitti> cking: I read through the logind code a bit and now have a local build with debugging enabled; could we do another round of ssh?
<cking> pitti, sure, let me get the machine up and running, it will take  a few minutes
<peat-psuwit> I'm compiling pulseaudio for armhf on amd64 using chroot and qemu-arm-static. But thread-mainloop-test, thread-test and sigbus-test fail. Any advice?
<sidi> I've got a ubuntu package that contains a "ubuntu-patches" folder on top of the usual "debian/patches". What am I to do with it? Is there a way to integrate the outcome of those patches with quilt? i.e. quilt push obviously doesn't apply those patches, but i dont wanna have to apply them to work on my package, and then unapply them to generate clean diffs for my own patches. I'm also curious how they're handled when automatically building packages
<rbasak> sidi: why aren't these patches in a place where quilt maintains them?
<sidi> rbasak, i have no idea. i'm actually here to understand whether that is a normal thing or an issue with that package
<sidi> it's lp:ubuntu/vivid-proposed/gpaste, for the record
<rbasak> sidi: I've not seen that before. Looks like upstream is keeping those files around - not the Debian maintainer.
<sidi> rbasak, oh, right! thanks for checking up. interestingly the package doesn't build (syntax errors on the Makefile which I suspect are linked to those 2 patches not being applied)
<rbasak> sidi: it's currently built on Vivid. You mean it fails to rebuild now?
<sidi> rbasak, hm you're correct. bzr bd -- -b works, but ./autogen.sh && ./configure && make doesn't.
<sidi> i'm not a debian/ubuntu packager so i don't understand what exactly builddep or debuild do differently
<sidi> i'm starting to suspect the app just has a buggy configure.ac, missing dependencies though
<cjwatson> The entry point used by debuild etc. is debian/rules, not directly via ./autogen.sh etc.
<sidi> i did have to install one more builddep (appdata-tools), and it seems the ubuntu-patches remove that dependency for old ubuntus but are unapplied by default
<LocutusOfBorg1> good morning developers!
<LocutusOfBorg1> pitti, how is going the systemd progress? I see it going nice, I hope to have it in vivid ;)
<pitti> hey LocutusOfBorg1
<LocutusOfBorg1> I'm using it since a month for my embedded yocto sytems and I LOVE it :)
<pitti> LocutusOfBorg1: looks ok so far; I'm crawling through the bugs, but we are now at the level of "happens in rare circumstances and needs lots of debugging"
<LocutusOfBorg1> I hope you won't revert the change for vivid
<pitti> so far nobody asked for that
<LocutusOfBorg1> wonderful! I see the last debian rc have been squashed
<pitti> it has certainly been a lot of pain, and I'm grateful for the vivid testers for bearing with it
<LocutusOfBorg1> I'm also testing vivid right now
<LocutusOfBorg1> I don't bother unless I see bugs :)
<LocutusOfBorg1> BTW pitti I have an eth.network file, how can I say "try udhcpc and if DHCP fails take this ipv4 address?"
<LocutusOfBorg1> this is the file https://github.com/gumstix/meta-gumstix-extras/blob/dizzy/recipes-core/systemd/files/eth.network
<LocutusOfBorg1> maybe you can give me a pointer, adding Address below doesn't work
<pitti> LocutusOfBorg1: sorry, I haven't done anythign with networkd yet, I'm afraid; can you try asking in #systemd?
<LocutusOfBorg1> yes, I'll debug something more and then ask :)
<LocutusOfBorg1> thanks
<LocutusOfBorg1> question: is it normal that "reboot" on vivid doesn't require sudo anymore?
<LocutusOfBorg1> pitti, ^^^
<LocutusOfBorg1> :)
<pitti> LocutusOfBorg1: if you are in a local desktop session, there's a polkit rule which allows that
<pitti> pkcheck --action-id org.freedesktop.login1.reboot   --process $$
<LocutusOfBorg1> thanks!
<pitti> this requires a "challenge" (i. e. entering your admin password) on remote sessions, but is currently allowed locally it seems
<pitti> similar to mounting usb sticks, setting the clock, etc.
<pitti> (or rebooting through the indicator)
<LocutusOfBorg1> thanks
<mdeslaur> pitti: thank you very much for fixing my nfs at boot, and the subsequent shut down hang! Very appreciated!
<pitti> mdeslaur: *beam* good news!
<mdeslaur> :)
<Riddell> dpm: why is launchpad still recommending translating utopic a month from releasing vivid?
<dpm> Riddell, probably because we did not change the translation focus, let me check
<dpm> Riddell, fixed. Seems like we hadn't changed the translation focus when we opened vivid translations a while ago
<Riddell> dpm: lovely thanks
<dpm> np
<seb128> "Object: <lp.registry.model.personproduct.PersonProduct object at 0x2afba3735ad0>, name: u'pin-dbusmock'"
<seb128> thanks lp, useful error :p
<seb128> oh, somebody deleted the merge request while I had it open that's why it couldn't post on it
<pitti> infinity, didrocks: FYI, the systemd test regression (most of it) is now tracked down, I filed bug 1439191
<ubottu> bug 1439191 in xserver-xorg-video-cirrus (Ubuntu) "[vivid regression] X.org fails to start on i386 cirrus" [Undecided,New] https://launchpad.net/bugs/1439191
<pitti> worked around by running the test with -vga vmware, like vivid's qemu does now by default
<didrocks> pitti: great!
<pitti> simple to reproduce in qemu
<infinity> pitti: Yay.
<pitti> it'll still fail on another test, didrocks is bisecting
<pitti> that looks like an actual regression
<pitti> so, yay tests
<infinity> Now to get the kernel people to fix their tests on i386...
<infinity> apw: ^
<apw> infinity, those look to be a testbed failure on i386, and are being rerun
<infinity> apw: I noticed the re-run, I didn't look at the logs, just remembered that it's been failing on i386 for ages.
 * infinity reads a log.
<apw> apw, the results i looked at looked like success up to that point, though it may yet fail again genuinly
<apw> the logs having no summary near the end does not help any
<infinity> Indeed, lots of hunting with find.
<infinity> pitti: I don't suppose autopkgtests have a concept of "why"?
<infinity> pitti: As in, "I was triggered because of a change in package-foo".
<pitti> infinity: not at the moment with our really crappy setup
<apw> infinity, to my reading all the ' END ' statements are ' END GOOD ' so i think that means it would have been green
<pitti> quite easy to do once we move to something sensible with AMQP
<infinity> pitti: These kernel build tests are completely pointless (and take forever) for kernel uploads themselves, but very necessary for toolchain uploads, for instance.
<pitti> apw: right, it failed on copying the results back up, which sometimes triggers this odd tar EOF error which I've never been able to reproduce (but it happens quite frequently on the CI machines)
<pitti> infinity: right, this is known and has been discussed a lot of times; but the current setup is fragile enough as it is, I really don't want to spend a lot of time changing and breaking it
<infinity> Yeah, fair enough.
<pitti> heck, in that time I could probably get my AMQP prototype to work reliably enough :)
 * apw hands pitti a doughnut as encouragement
<infinity> Mmm, doughnuts.
<infinity> pitti: I'm well aware that the current autopkgtest infra is far from what you'd like it to be, which is why I try to refrain from talking shit about it. :)
<infinity> pitti: But once it morphs into what it's meant to be, I might have some input into all the ways it sucks. :P
<pitti> infinity: oh, yes :) (there are lots of ways indeed..)
<infinity> pitti: Mostly, my obvious complaint (if we ignore Jenkins) is just reliability.  Comparing to our buildd network, which rarely (at least, in a comparison of failures per number-of-builds) needs attention, this all seems rather fragile.
<pitti> right; the biggest machinery related ones that I see are (1) that tar EOF thingy, (2) apt hash sum mismatches, and (3) uninstallable packages
<pitti> and there are tons of flaky tests which need regular retries
<infinity> pitti: Yeah, flapping tests are obviously not your fault, though maybe we should try to build a small army of people to drive that closer to zero so we can actually have a good clean baseline for future comparison.
<pitti> we do have some defence against (2) by retrying automatically once after 15 seconds, but that might need some improvement too
<pitti> as for (3), that's a case for detecting that from the logs and auto-retrying half an hour later or so
<pitti> some kind of "transient error" result code which makes adt-britney just retry in the next run
<infinity> pitti: Yeah, I was going to suggest auto-retrying for known infra bugs.  Wasn't sure if you, like me, once held the opinion that forcing yourself to manually intervene reminds you that there's a bug that needs investigating, but as I get older and wiser(?), I'm realising that's BS, and all it does is train me to do the busywork every day, not fix the bug.
<pitti> infinity: yeah, that sounds terribly familiar
<pitti> I tried to investigate and understand the tar EOF bug like 5 times and wasted a day or so on that in total, but I'm none the wiser
<pitti> and it won't actually matter for the nova/cloud tests that CI is now running in parallel
<pitti> ev: ^ incidentally, how does that go?
<pitti> lol @ https://com.google/
<pitti> apw: oh, you were saying you use libvirt under systemd? I wondered how urgent bug 1312304 was
<ubottu> bug 1312304 in libvirt (Ubuntu) "[systemd] libvirt-bin needs a unit file" [High,Triaged] https://launchpad.net/bugs/1312304
<apw> pitti, i am using it, it seems to work as is, it may be one of the slownesses, but not exploding m
<apw> me
<pitti> apw: ack, thanks
<ev> pitti: the majority of the work is done, but proving that this doesn't introduce failures that weren't present in the Jenkins adt infra remains: https://trello.com/c/MelDDUma/193-2-ue-staging-testing-infrastructure-to-cope-with-increased-load-of-tests
<ev> It's at the top of the proposed backlog. If this is important to QA and Foundations, I ask that you send your stakeholder reps to our backlog meeting Thursday the 9th to lobby for it.
<ev> ^ Ursinha heads up
<infinity> ev: I'm all for proof and testing, but I'll also cautiously say that it would take deliberate action to create something worse than the current shoestring and bubblegum infra. :P
<ev> lol
<ev> can I rise to that challenge?
<infinity> I'd prefer you didn't.
<ev> hahaha
<cjwatson> pitti: Hm, so I tried running a cleanup on the ddebs a-f database in the same kind of way that Launchpad now does regularly to maintain reasonable performance, and this doesn't look good: http://paste.ubuntu.com/10718827/
 * cjwatson tries for rtm
<pitti> cjwatson: hmm, I remember clearly that I worked on vacuuming the database the other day, but I indeed got some errors there
<pitti> which is why I didn't roll it out
<pitti> but not these errors
<cjwatson> Heh, for RTM this gives me an 8K resulting DB, I might not have got it quite right
<pitti> some weird bdb "out of memory"-like message
<pitti> cjwatson: I tried with http://ddebs.ubuntu.com/clean.conf
<cjwatson> This screams of "time to nuke the db and start from scratch" to me
<pitti> yeah, can do; it takes ~ 1.5 days
<pitti> but oh well
<cjwatson> pitti: OK, there's definitely something wrong with this cleanup procedure, http://paste.ubuntu.com/10718856/
<cjwatson> Ah, needs to be run in the right directory because the paths in the cachedb aren't absolute, unlike in LP
<cjwatson> (Which is a bit of a timebomb really ...)
* Raccoon changed the topic of #ubuntu-devel to: HAPPY APRIL FOOLS DAY! | #ubuntu-devel 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 -> utopic | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
* cjwatson 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 -> utopic | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<seb128> barry, hey, is https://errors.ubuntu.com/problem/44254dfe1ed3a5acdec9c4e4172b009e905dcd89 still on your todolist? it seems the issue started with your python3 port of oneconf
<cjwatson> pitti: I'll see if the BDB repair tools can fix it ...
<barry> seb128: yeesh.  first i've seen of it.  no clue what's going on but it looks like it's going to be a python3-apt problem perhaps
<cjwatson> pitti: For RTM, this reduces the DB size from ~44MB to ~15MB.  You do want the more complete architecture list from my paste, though (it should be the union of all architectures in any published suite)
<pitti> cjwatson: ack, thanks
<pitti> cjwatson: updated clean.conf
<barry> seb128: i'll keep a tab open on it, but no promises.  i'm fully saturated trying to finish up worky-work before pycon next week. ;)
<cjwatson> pitti: This is all yak-shaving because I was looking for a plausible place to stick a timestamp of the BPPH threshold from LP :)
<pitti> cjwatson: if it's broken, just rm'ing it shoudl suffice, the next cron run will then run for ages and rebuild it
<cjwatson> pitti: (I don't think I need to keep a separate map of which ddebs it already knows about, though; whether they exist in pool should be sufficient)
<cjwatson> pitti: You don't feel like moving ddeb-retriever to a real project so that I can use MPs, I suppose?
<pitti> cjwatson: we can do that; it just never came up so far
<pitti> but it seems it might live a whole lot longer still :)
<teward> under the current freeze an upload which just enables position independent building for a given application wouldn't get past freeze would it?
<pitti> cjwatson: (can't do it right now, sorry; can on on Tuesday, unless you or someone else beat me to it)
<pitti> I'll be on vac tomorrow and national holidays Fri/Mon FTR
<cjwatson> pitti: Sure, not a desperate rush.  I'll be on nat holiday Fri/Mon and vac Tue
<seb128> barry, thanks
<cjwatson> Ah, good, db5.1_dump | db5.1_load fixed the ddebs a-f cache
<doko> http://bugs.python.org/issue23842
<ovidiu-florin> hello world
<ovidiu-florin> doko: are you around?
<teward> so, stupid question, but i'm getting FTBFS on nginx on ppc64el and powerpc because a change (from Debian) to enable PIE isn't recognized, has anyone seen this before and got an idea for how to fix?
<sarnold> teward: can you pastebin the relevant compile line and error message?
<teward> sarnold: http://paste.ubuntu.com/10719958/  <-- errors from the build logs (this was the latest upload, and using the changes as-is from Debian).  http://paste.ubuntu.com/10719968/  <-- from debian/rules
<sarnold> teward: hunh I wouldn'thave expected those to be configure flags..
<teward> sarnold: i didn't make the change, Debian did
<teward> sarnold: suggestions to fix?
<sarnold> teward: maybe that means a newer auto* is needed to provide a newer ./configure ?
<sarnold> teward: (that's a wild-ass-guess)
<teward> sarnold: considering this is in Vivid, IDK if that'd help
<teward> sarnold: this is quite literally the output and information from the builders after the upload - no idea how to resolve
<mdeslaur> if it works on other archs, I doubt it needs a new conf*
<infinity> teward: There's no way those are configure flags.
<infinity> teward: And it's broken on all arches, not just ppc...
<teward> infinity: yes i know that
<teward> infinity: i'm ahead of you, with a build in local sbuild to try and resolve
<teward> (it'll be uploaded to fix the global FTBFS)
<teward> infinity: i think someone up in Debian who made the change was drunk
<mdeslaur> teward: you upload stuff without building it locally first?
<teward> mdeslaur: that was a mistake, yes.
<mdeslaur> the archive isn't your ppa
<infinity> teward: Probably.  I assume he meant to add -pie to ldflags and -fPIE to cflags.
<teward> infinity: yes, indeed.
<teward> mdeslaur: i misread the diff, assumed they changed the cflags, not configure flags
<teward> mdeslaur: hence the failure in my part
<teward> (yes it's not a PPA, it was a failure on my part to be thorough)
<teward> (so sue me)
 * infinity sues.
 * teward counter sues with the argument that everyone makes mistakes and to not berate one person for one occasional mistake
 * infinity sues harder, and in several jurisdictions.
 * teward yawns
<infinity> Anyhow, it happens.  Patiently awaiting the new upload in the queue.
<teward> infinity: it'll be there as soon as I berate Debian for being drunk, and my own sbuild schroot to update
 * teward is raising hell :P
<infinity> teward: dpkg-buildflags might be more helpful here.
<teward> infinity: mmm... probably. the rules file is set to have a different variable used in the compile time...
<teward> debian_cflags:=$(shell dpkg-buildflags --get CFLAGS | sed 's/-O3/-O2/') $(shell dpkg-buildflags --get CPPFLAGS) <-- currently that defines the cflags for building
<infinity> teward: Right, so it's already using dpkg-buildflags, you just need to pump up the fancy.
<infinity> teward: Note the difference between "dpkg-buildflags" and "DEB_BUILD_MAINT_OPTIONS=hardening=+all dpkg-buildflags"
<infinity> teward: That gets you PIE/pie and z,now, the two things noted missing in that bug report.
<teward> yep
<infinity> teward: So, probably exporting DEB_BUILD_MAINT_OPTIONS=hardening=+all above the current dpkg-buildflags calls would do the trick.
<teward> infinity: right, i was about to do that just now
<teward> urgh i hate gpg2 >.<
<teward> it doesn't remember i unlocked the keys :/
<teward> infinity: in the sbuild schroot it seems that it's working and not FTBFSing.  going to run the hardening-check against it after build though, because thoroughness
<infinity> teward: Good deal.
<teward> assuming it doesn't burn my CPU up in the process >.<
<teward> urgh, now it's failing on perl
<infinity> teward: Testing here to see if it makes sense to me.
<teward> infinity: the failure looks like it's in the extras package
<teward> god i hate perl
<teward> ... have i said i hate perl yet?
<infinity> teward: It might just be that the PERL_LDFLAGS bit needs to be less restrictive.
<teward> MMM
<teward> mmm*
<teward> infinity: build logs from sbuild here: http://paste.ubuntu.com/10720164/
<teward> LOVELY thing about sbuild: logs are there :P
<teward> infinity: please let me know if you have any insights, if it were up to me the third party modules would be gone but it's not up to me since so many users use -extras still
<teward> (I can at least say nginx-core would not fail xD)
<teward> infinity: any chance the hardening flags caused the failures?
<teward> cause without them on ubuntu1, it worked fine apparently (from a build perspective)
<infinity> teward: Yeahp, probably.  I'm testing a bit here.
<teward> infinity: ack.
<ovidiu-florin> doko: ping
<infinity> teward: Hrm, this is slightly more annoying than I assumed it would be.
<teward> infinity: indeed.
<teward> infinity: in theory we could *manually* add the -fPIE -pie flag...
<teward> infinity: the problem is that -extras has a lot of extra modules that... aren't core
<teward> which is why we had to create -core for the MIR
<teward> and i think the problem will trace back to the perl module
<infinity> ovidiu-florin: Asking what you want to know might be more helpful than sending random pings out into the ether.
<ovidiu-florin> infinity: I've been told to talk to doko, that's why I'm not asking
<teward> infinity: i'm going to take a wild test and see if this happens with -fPIE added to only CFLAGS and not LDFLAGS - if it builds then great, if not, then we know the perl module is blocking PIE
<teward> (if not other hardening flags)
<infinity> teward: It's more likely that the perl modules are accidentally getting the PIE cflags, when they're libraries and should be PIC.
<teward> infinity: i think it is since -fPIE is being passed in the LDFLAGS
<teward> (at least, when i poke it on a Trusty system with that variable, running the command that generates the flags)
<infinity> teward: Still playing here.  Whee.
<teward> infinity: well, stupidly, building with cflags only of -fPIE and not including -fPIE -pie in LDFLAGS seems to make the build succeed, but that doesn't help the perl side
<teward> infinity: thanks for the assistance though, it helps having two people attacking the problem xD
<teward> infinity: i think PIC and PIE are incompatible with each other because of shared objects...
<teward> (I wonder if it's even possible to achieve this cause of the perl parts)
<infinity> teward: Yes, I said as much up there.
<teward> i missed that sorry
 * teward yawns
<teward> i need sleep i guess :)
<infinity> teward: Libraries are PIC, executables are PIE.
<infinity> Fundamentally, it's pretty much the same thing, I wish the toolchain were a bit smarter and just turned pie into pic when -shared was specified.
<mdeslaur> mmm...pie
<teward> infinity: heh.
<teward> well i'm running a... hackish... test... :/
<teward> locally of course
<teward> i hate hackish solutions though :/
<teward> nice clean solutions, they work better... :/
<infinity> Hrm.  I did something that built, but I'm not convinced it should have.
<infinity> And still didn't link the nginx binary properly anyway.
<teward> i don't think there's a clean method given Perl
<teward> but we'll see, i'm curious if this thing i just did builds.
<teward> it's still updating the schroot for the build deps heh
<teward> infinity: i'd like to see what you did, if only to satisfy curiosity
<teward> (kinda curious how you tested the linking too)
<infinity> teward: I'd rather do something less buggy first.  The linking failure clearly pointed at me being dumb. ;)
<teward> heh
<teward> infinity: ok.  well again, i dont' want to detract from your likely busy schedule, but I do appreciate the help :)
<infinity> teward: I need a distraction sometimes.
<teward> heh
<teward> infinity: i'm up to my 'hope it doesn't fail again' state :/
<infinity> There we go, that went better.
<teward> infinity: mine built as well, question i had was how did you test linking of the binaries.
<infinity> teward: hardening-check
<teward> ... wow sbuild didn't put the .debs :/
<teward> infinity: well it'd be nice if sbuild had KEPT the .debs :/
<infinity> teward: http://paste.ubuntu.com/10720546/
<infinity> teward: That worked for me.
<infinity> teward: With these results: http://paste.ubuntu.com/10720549/
<teward> infinity: that's effectively what I do but slightly different, I export +all,-pie and then add -fPIE to the debian_cflags separately
<teward> (per the manpage explaining what buildflags adds for +pie)
<infinity> teward: Needs to have -pie in ldflags, though, or it won't actually link pieishly.
<teward> mmm good point
<infinity> teward: -fPIE just sets some CPP defines.
<teward> infinity: OK, i'll use yours, if you don't mind.
<infinity> teward: Be my guest.
<teward> want credit?
<teward> this is ultimately going up to Debian too
<infinity> Don't care.  My name's all over the place.
<teward> cool
<teward> infinity: could we do what you did with line 28 in that diff on line 23 instead?
<infinity> teward: If you wanted to make it entirely upstreamable (or moreso), there's some flag-mangling in the perl setup bits, they already sed out some CFLAGS, wouldn't be unreasonable to sed out -fPIE and -pie as well from CFLAGS and LDFLAGS.
<infinity> teward: No, doing it on line 23 entirely defeats the purpose.
<infinity> teward: The build (except the perl modules) *must* have -pie in LDFLAGS.
<teward> infinity: ok
<infinity> teward: You might want to test that it actually works built this way, mind you. :P
<infinity> It load enough to tell me I don't have a config file at least.
<teward> infinity: it's the perl module, I have no use case to do a thorough test
<teward> the only reason it's included is because 'highly demanded'
<teward> i'll run standard testing though, with default site setups, etc.
<teward> but that's a given test
<teward> ... i need a vivid vm :/
<slangasek> infinity, chrisccoulson: I just got the firefox landing page in Turkish now
<sarnold> not arabic?
<slangasek> infinity, chrisccoulson: that's not a setting in my browser; firefox doesn't appear to have been upgraded here since March 6; it previously was working just fine in English
<slangasek> sarnold: nope
<slangasek> just hit refresh and now it's in English again
<bkerensa> slangasek: what version of FF?
<slangasek> bkerensa: the current version in the archive
<chrisccoulson> I thought we'd established that this was a bug with the startpage?
<slangasek> chrisccoulson: was that established?  It certainly seemed that way to me but I got the impression not everyone was convinced.  If it is a bug in the start page, where should I report that?
<chrisccoulson> slangasek, https://bugs.launchpad.net/ubuntu-start-page/
<slangasek> chrisccoulson: cheers
<slangasek> looks like it's reported already, bug #1427844
<ubottu> bug 1427844 in Ubuntu Start Page "Ubuntu search page comes up in wrong language from time to time" [High,Triaged] https://launchpad.net/bugs/1427844
<bkerensa> chrisccoulson: Does Ubuntu's Firefox have a prebundled addon?
<bkerensa> chrisccoulson: for the bookmarks and unity stuff?
<PartNAS> rww: you in here?
<chrisccoulson> bkerensa, yes
<bkerensa> chrisccoulson: you know about the upcoming requirement for addon signing I assume? :)
<chrisccoulson> bkerensa, yes
<bkerensa> chrisccoulson: I'm sure we will have a flag for distros though
<bkerensa> distros / esr etc
<chrisccoulson> fingers crossed!
<bdmurray> tedg: didn't you right write some binary or library instead of calling /usr/share/apport/recoverable_problem?
<flexiondotorg> bdmurray, Regarding https://bugs.launchpad.net/ubuntu/+source/software-properties/+bug/1434579
<ubottu> Launchpad bug 1434579 in software-properties (Ubuntu) "Unable to install VirtualBox Guest Service in 15.04" [High,Incomplete]
<flexiondotorg> bdmurray, Looks like multiverse was removed from the repo list when the Ubuntu MATE meta packages were imported and uploaded.
<flexiondotorg> bdmurray, I did have multiverse enabled by default.
<flexiondotorg> bdmurray, Are you able to do a little sponsoring and update the ubuntu-mate-meta package to add multiverse please?
<infinity> flexiondotorg: How would multiverse relate to your metapackages?
<infinity> flexiondotorg: Or, rather, if your meta is mangling sources.list, you've done something a bit scary.
<flexiondotorg> infinity, I've not done anything scary :) Let me just check...
<flexiondotorg> infinity, http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/vivid/ubuntu-mate-meta/vivid/view/head:/update.cfg#L14
<flexiondotorg> flexiondotorg, When I was hakc my unofficial version of Ubuntu MATE the line referenced above had 'multiverse' on it.
<flexiondotorg> infinity, I was wondering if adding 'multiverse' back in there would enable the multiverse repos?
<infinity> flexiondotorg: That won't relate to what's available in sources.list.
<flexiondotorg> infinity, OK.
<infinity> flexiondotorg: All that does is define which components your seeds should be looking for packages in.
<flexiondotorg> infinity, Thanks. Understood.
<flexiondotorg> infinity, bdmurray Therefore, until recently virtualbox-guest-x11 could be install via software-properties without manually enabling multiverse. That is no longer the case.
<infinity> flexiondotorg: Hrm.  So, I have multiverse enabled in a default install here...
<flexiondotorg> infinity, So, I've just checked using a daily in a new VM. I have multiverse enabled too.
<flexiondotorg> By default.
<infinity> And I assume you can select the fancy non-free driver?
<flexiondotorg> infinity, I'll double check in this new VM. One sec.
<flexiondotorg> infinity, No. Still unable to install virtualbox-guest-dkma via the "Additional Hardware" tool.
<flexiondotorg> infinity, See https://bugs.launchpad.net/ubuntu/+source/software-properties/+bug/1434579 and the screenshot I've attached there.
<ubottu> Launchpad bug 1434579 in software-properties (Ubuntu) "Unable to install VirtualBox Guest Service in 15.04" [High,Confirmed]
<infinity> flexiondotorg: Curious.
<infinity> flexiondotorg: Grabbing a daily to see this for myself.
<flexiondotorg> infinity, Thanks.
<flexiondotorg> infinity, I think this started happening around the time Xorg 1.17 landed.
<infinity> flexiondotorg: Yeahp, it could be that the driver doesn't support the new xserver.
<flexiondotorg> infinity, BTW, Xorg is completely busted for PowerPC :(
<flexiondotorg> infinity, Working with upstream...
<lathiat> on a totally unrelated note, glibc source (nss) is something special.
<lathiat> so much legacy
<flexiondotorg> infinity, I cat apt install virtualbox-guest-x11 and it works just fine.
<infinity> flexiondotorg: Fun.  Okay, can totally reproduce, not sure where the bug lies just yet.
<flexiondotorg> infinity, Thanks for looking.
<flexiondotorg> Time for sleeping...
<infinity> flexiondotorg: It was an excuse to learn something new.  I've never looked at this bit before.
<flexiondotorg> :)
<flexiondotorg> Z Z Z z z z zzzz...
<infinity>         if page == self.vbox_drivers:
<infinity>             self.button_revert.set_visible(False)
 * infinity blinks.
<infinity> Oh, totally not virtualbox, just a badly named variable.
<infinity> flexiondotorg: Oh, that's why.  The dkms driver was pulled into the kernel, things need to change a bit to accomodate this new world order.
#ubuntu-devel 2015-04-02
<RAOF> Hey, doko_! Is there any SRU review I could trade you to get a small, upstream reviewed patch applied to libstdc++? :) https://bugs.launchpad.net/gcc/+bug/1439451
<ubottu> Launchpad bug 1439451 in gcc-4.9 (Ubuntu) "std::uncaught_exception() returns true after catching an exception thrown with std::rethrow_exception" [Undecided,New]
<sarnold> why does errors.ubuntu.com still show 12.10, 13.04, and 13.10 things on the front page? none of those have been supported in ages..
<sarnold> and poor trusty and utopic are missing entirely
<MrHeavy> The OpenStack repository at http://ubuntu-cloud.archive.canonical.com/ubuntu/ has a package (openstack-dashboard) with dependencies that don't exist. Is there anywhere in Launchpad that I should look around for them in queue?
<MrHeavy> The packages in question are: python-xstatic-term.js, python-xstatic-angular-irdragndrop
<MrHeavy> I can't even find Debian spkgs for these :/
<flexiondotorg> infinity, Saw you update on the bug. Thanks for investigating.
<jhenke> morning
<jhenke> any firefox maintainer here?
<jhenke> I am looking for someone to get into the reason for this bug after todays firefox update (afaik only affects vivid) https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1439532
<ubottu> Launchpad bug 1439532 in firefox (Ubuntu) "Firefox 37 does not enable MSE required for YouTube HTML5 player" [Undecided,New]
<asac> jhenke: chrisccoulson might be around later
<asac> shouldnt be that long unless he is on vacation or something
<jhenke> asac thanks, will wait for him
<jhenke> chrisccoulson are you online?
<Laney> what creates /run/network/ifstate ?
<ogra_> Laney, the networking upstart job ?
<ogra_> (not sure)
<Laney> upstart? what's that? :)
<ogra_> haha
<ogra_> yeah, living in the past here :)
<lfrlucas> Why is policykit-1 still on proposed (trusty)?  28 days have passed
<mgedmin> Laney, isn't it ifupdown?
<Laney> I don't see where it's supposed to be done under systemd
<Laney> It seems that ifup does create it when it's bringing an interface up but nothing makes an empty file on boot
<Laney> probably just wants a tmpfiles.d entry
<peleg> Hi there. I have installed ubuntu 14.04.2 on a new Dell Latitude E7450, and there seems to be a BIOS bug which makes keystrokes randomly repeat. This is an old known issue, at least in the forums. See for example http://en.community.dell.com/support-forums/software-os/f/3525/p/19618638/20748484
<peleg> I have posted a question in ubuntu-certified launchpad: https://answers.launchpad.net/ubuntu-certification/+question/264500
<peleg> and in askubuntu as well: http://askubuntu.com/questions/604382/dell-latitude-e7450-repeating-keystrokes-issue
<peleg> Since canonical works closely with Dell, I was thinking that perhaps they should (a) publish a warning and (b) get a formal announcement from Dell about it
<nrosvall> Hi, I'm working on a quite big software project. Now when Unity 8 is coming and all that new stuff I'm wondering how much Unity 7 and 8 api will be different
<nrosvall> say indicators? will indicators written for unity 7 work with unity 8?
<nrosvall> (not sure if this is the right place to ask)
<rbasak> nrosvall: try #ubuntu-desktop maybe?
<smoser> hey. i need some systemd help
<smoser> bug 1438520
<ubottu> bug 1438520 in cloud-init "cloud-init on vivid upgrade causes sigterm, which aborts 'runcmd' execution" [Undecided,Confirmed] https://launchpad.net/bugs/1438520
<smoser> one of cloud-init's jobs runs apt-get dist-upgrade, and that job upgrades cloud-init (if there is one available).
<smoser> something in that interaction with systemd means that subsequent cloud-init jobs aren't run.
<smoser> this worked with upstart, and its important for us to get right (because otherwise you can't have clodu-init safely upgrade for you)
<smoser> xnox, maybe or i know that didrocks has some experience with systemd also.
<xnox> yo
<xnox> smoser: so what happens? cloud-init service gets killed, and not started on post-upgrade... remaining cloud-init services don't run either?
<Riddell> tseliot: hola?
<xnox> hm. =/ i don't have time to dig into that at the moment, sorry.
<tseliot> Riddell: hey,
<smoser> xnox, yes. i'll try to put an explanation of the problem into the bug. then maybe if you have time you can read.
<didrocks> smoser: just ping me once you have the explanation's summary into the bug, I'll try to have a look by EOW
<smoser> didrocks, ok. thanks.
<Riddell> tseliot: oh, so sddm can probably do the thing on starting X
<Riddell> tseliot: but there's no hook to run a script on shutting X down
<Riddell> tseliot: what happens if nvidia-prime gets set up but not removed?
<tseliot> Riddell: yes, I had to implement that myself in lightdm
<Riddell> does it mean nvidia and intel do eternal battle for the graphics?
<tseliot> Riddell: hybrid graphics (as in disabling the discrete GPU) won't work on log out. Switching between GPUs will require a reboot
<Riddell> tseliot: so that sounds better than not working at all?
<tseliot> Riddell: sure but users will complain
<Riddell> tseliot: right but will they complain more than if they can't install it without breaking sddm
<Riddell> and who are all these users with two GPUs? they seem like a very fussy lot :)
<tseliot> Riddell: the nvidia settings panel will tell them to log out to switch to the other GPU, then they log out, log back in, and everything will be broken, as you'll get the driver using the wrong libriaries
<tseliot> *libraries
<tseliot> Riddell: yes, I think there are a lot of users
<tseliot> Riddell: it should be relatively easy to add that feature to sddm
<Riddell> tseliot: reported it for now https://github.com/sddm/sddm/issues/393 https://github.com/sddm/sddm/issues/394
<Riddell> tseliot: how do I change nvidia-prime packaging to have sddm alternate?
<tseliot> Riddell: it already does this: Depends: lightdm (>= 1.9.1) | gdm | kdm. I can add a simple "|sddm", assuming that's the package name
<tseliot> Riddell: does kubuntu use systemd?
<Riddell> tseliot: yes please add |sddm .  yes we use systemd
<smoser> GunnarHj, can you take a look at bug 1439711
<ubottu> bug 1439711 in language-selector (Ubuntu) "cedilla-brazil.sh writes errors on login: line 21: [: too many arguments" [Undecided,New] https://launchpad.net/bugs/1439711
<tseliot> Riddell: ok, I'll do that now. Furthermore I've just written some untested code that should give you the same feature on log out
<Riddell> tseliot: ooh?
<tseliot> Riddell: the one that executes a script after X is stopped
<cjwatson> smoser: Wasn't that fixed by https://launchpad.net/ubuntu/+source/language-selector/0.142
<cjwatson> ?
<Riddell> tseliot: that's exciting :)
<cjwatson> smoser: Should be closed I think.
<Riddell> tseliot: let me know if you have something I should add to the sddm package
<tseliot> Riddell: sure. In the meantime, let's see if I got it right. Is the DisplayCommand entry meant to be set in the Xsetup script? If so, my code should work as expected
<Riddell> tseliot: DisplayCommand entry?
<tseliot> Riddell: that's the entry for the command to execute after X starts: https://github.com/sddm/sddm/blob/master/data/man/sddm.conf.rst.in
<tseliot> Riddell: so I'm wondering if adding DisplayCommand="path_to_my_script" in the Xsetup script would work
 * tseliot has never used sddm
<tseliot> if that works, then I have code to add another entry
<Riddell> tseliot: DisplayCommand is "A script to execute when starting the display server"
<Riddell> tseliot: I don't think setting DisplayCommand in Xsetup will do anything, it gets set in sddm.conf
<tseliot> Riddell: aah, so there is an sddm.conf file. Ok, it should work then
<Riddell> tseliot: sddm --example-config  will Print the complete current configuration to stdout
<tseliot> Riddell: ah, so that shows that DisplayCommand=/usr/share/sddm/scripts/Xsetup . I think we really need to get something like https://github.com/sddm/sddm/issues/217 first
<tseliot> Riddell: as you don't want to have the scripts executed for users who don't need them
<Riddell> tseliot: that would obviously be nicer but is it a problem if it's executed for users who don't need it?
<tseliot> Riddell: luckily, it's not. As we check the hardware
<Riddell> phew :)
<tseliot> Riddell: after I add my code, you will have to add two entries: DisplayCommand and DisplayStopCommand, pointing to Xsetup and Xstop respectively
<tseliot> Riddell: or, rather, point to the same scripts that we have in nvidia-prime and be done with it
<Riddell> tseliot: DisplayCommand points to Xsetup by default, I guess your code will point DisplayStopCommand to Xstop by default and that can run nvidia-switch
<tseliot> Riddell: yep. You will have to ship a custom .conf file if you want hybrid gfx to work
<tseliot> Riddell: I'll try to compile sddm with my patch. Hopefully the packaging is relatively simple
<infinity> Laney: Really, you want to wrap my C gnome-terminal with a python script and triple the startup time? :/
<Laney> I want to not break existing configurations
<Laney> I forgot to add new Depends though, whoopsie
<infinity> Laney: I don't suppose you could just reintroduce the option in C instead?
<infinity> Laney: I guess for "normal" people who never see the terminal, it's a non-issue, but for people who hit Ctrl-ALt-T more than anything else on their keyboard, it's a noticeable performance regression to fire up a python interpreter first.
<Laney> It's not as easy as that, you have to start a second server instance and connect to this one
<tseliot> Riddell: my patch built :)
<tseliot> Riddell: and this is what sddm --example-config says now: http://paste.ubuntu.com/10724675/
<Adri2000> is anyone moderating devel-permissions@ ?
<tseliot> Riddell: I've made a pull request for my code: https://github.com/sddm/sddm/pull/395
<bdmurray> tedg: Didn't you create some code for calling apport's recoverable_problem some where or generating RecoverableProblem reports?
<infinity> tseliot: Why do you have a .patch in nvidia-prime that does nothing?  Accidental cruft?
<tseliot> infinity: in 0.8.1?
<infinity> tseliot: Yeah, 0001-debian-control-add-sddm-and-systemd-as-alternate-dep.patch in the base directory.  Doesn't need to be there, it's obviously applied to debian/control already.
<tedg> bdmurray, We have some cut-and-paste code that we've been passing around, I started an MR for it, but it needs tests: https://code.launchpad.net/~ted/whoopsie/recoverable-problem/+merge/219066
<tseliot> infinity: aargh I forgot to remove it
<infinity> tseliot: Go ahead and delete it and reupload the same version.
<tseliot> infinity: ok, thanks
<infinity> tseliot: On a side note, why the dependency on "upstart | systemd" at all?
<bdmurray> tedg: right, I found that mp. Where can I see the cut and paste code?
<tseliot> infinity: it's no longer there. It's only in that patch
<tedg> bdmurray, It's there, the recoverable error file. I cleaned up the API for that MR, but it's basically the same.
<infinity> tseliot: Daemons don't generally depend on init systems.  And, even if they did, you're not getting the *system* init with that dep.
<tedg> bdmurray, It's in a bunch of different projects.
<infinity> tseliot: Oh, indeed, it's not there in the real debian/control.  Check.
<tseliot> infinity: reuploaded
<bdmurray> tedg: Could you name one of those? I'm trying to sort out some issues with the DuplicateSignature.
<infinity> tseliot: Better, and accepted.
<tedg> bdmurray, Sure, UAL. https://bazaar.launchpad.net/~indicator-applet-developers/ubuntu-app-launch/trunk.15.04/view/head:/libubuntu-app-launch/recoverable-problem.c
<tseliot> infinity: thanks
<tedg> bdmurray, Are you looking for the duplicate signature we're using?
<bdmurray> tedg: Also do you know of a way to create a recoverable problem in an app? Just calling recoverable_problem does that I think it should.
<hallyn> jodh: hey,
<tedg> bdmurray, It does, yes, but you have to pass the additional parameters to the stdin of the utility. Which isn't that friendly for most app developers, hence the wrapper.
<bdmurray> tedg: I'm trying to figure out why bug 1316763 isn't work
<ubottu> bug 1316763 in apport (Ubuntu Trusty) "bucketing of recoverable problems is done poorly" [Medium,Triaged] https://launchpad.net/bugs/1316763
<jodh> hallyn: hi
<hallyn> so for bug https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1432683 i'm going to be needing systemd and upstart packages
<ubottu> Launchpad bug 1432683 in lxc (Ubuntu) "apt-get install lxc doesn't load required apparmor profiles" [Critical,Triaged]
<tedg> bdmurray, I think the issue is that we have the same duplicate signature for different apps
<hallyn> moving /lib/init/apparmor-profile-load from cgroup-bin to init-system-helpers.
<hallyn> jodh: do you have planned uploads soon for those?
<tedg> bdmurray, For instance "bad-url" can come from anyone
<bdmurray> tedg: right, and I modified recoverable_problem to change that and it works for me
<bdmurray> "Use package name in duplicate signature for recoverable problems. "
<hallyn> jodh: if not i'll happily push later today
<jodh> hallyn: nothing planned from me, no.
<hallyn> jodh: do you know if pitti had anything planned?  there's no team bzr tree or anything i should go through?
<infinity> hallyn: Hrm, I thought rbasak was going to finish that move, did he get distracted?
<infinity> rbasak: Didn't you have pending uploads for the /lib/init/apparmor-profile-load thing?
<hallyn> infinity: yeah he had to move on
<infinity> hallyn: Ahh, kay.
<hallyn> afaik.  let's see what rbasak says
<hallyn> the apparmor package did get pushed, that was step 1...
<rbasak> Yeah sorry, been distracted.
<tedg> bdmurray, Hmm, I hadn't see that patch. Not sure why that wouldn't be working.
<rbasak> I can aim to push the rest in the next week or two if you want me to.
<hallyn> rbasak: i'd menat to do it, just got sick.  i'm back and was planning to push the next steps today
<bdmurray> tedg: Right, I've no idea either. So do you know of a way to cause a recoverable problem in the web browser or something?
<tedg> bdmurray, We're gonna have a bunch from Utopic though, is that in Utopic?
<hallyn> either way
<rbasak> hallyn: OK - I'll leave it to you then? I was aware you were sick but also didn't want to step on your toes (and had been occupied with Docker)
<tedg> bdmurray, Just launch a bad URL: "url-dispatcher foo://bar"
<bdmurray> tedg: yes, it made it into utopic and I tried it on RTM
<hallyn> rbasak: i'll do it then - thx, ttyl
<bdmurray> tedg: okay, great
<tedg> bdmurray, You might need to do that with a longer living process ID though, so it has time to grab info.
<tedg> bdmurray, The command line utility might be too fast for apport
<doko> RAOF, discussing with upstream. I don't like to apply patches which are not yet upstream.
<bdmurray> tedg: whenever I launch url-dispatcher I receive "** (process:3928): WARNING **: Unable to get name 'com.canonical.URLDispatcher'"
<tedg> bdmurray, Not the service the command line util. Thought it was on the image...
<hallyn> rbasak: i'm looking at http://paste.ubuntu.com/10725004/.  except that the apparmor patch was wrong (the new script isn't executable) so i'l lhvae to wait for one more push :(
<rbasak> hallyn: ah yes. We discussed that. Can't transfer executable bit in a debdiff. Sorry!
<tedg> bdmurray, It basically does: gdbus call --session --dest com.canonical.URLDispatcher --object-path /com/canonical/URLDispatcher --method com.canonical.URLDispatcher.DispatchURL foo://bar " "
<infinity> hallyn: No one's stopping you from uploading an apparmor with the +x bit set...
<bdmurray> tedg: "Error: GDBus.Error:com.canonical.URLDispatcher.BadURL: URL 'foo://bar' is not handleable by the URL Dispatcher
<bdmurray> (According to introspection data, you need to pass 'ss')"
<doko> bdmurray, wgrant: could you have a look at https://bugs.launchpad.net/ubuntu/+source/pywbem/+bug/1434991 ? you touched these packages for trusty-updates
<ubottu> Launchpad bug 1434991 in pywbem (Ubuntu) "python attributeError 'SSLTimeoutError' after upgrade" [Undecided,Confirmed]
<bdmurray> doko: don't you mean caribou?
<doko> bdmurray, ohh, maybe, you just signed
<bdmurray> doko: yeah, looking at the changelog it was caribou's SRU
<infinity> LocutusOfBorg1: Hey, regarding vbox dkms stuff, I'll push you some patches when I've got it all unwound.  I have great motivation for the package to be in sync between Debian and Ubuntu, and zero interest in maintaining a fork. :P
<teward> infinity: thanks again for the assist yesterday :)
<teward> and apologies on the delay in uploading the nginx change, i got busy last night, then my internet crapped again.
<hallyn> infinity: yup, i was just waiting to make sure there's no competing upload comigng from security.  ther eisn't
<gQuigs> does snappy or ubuntu core follow the same release cycle as normal releases?  or is the current version permanently dev rolling?
<ogra_> gQuigs, #snappy is a better place for such questions i guess
<ogra_> (currently it is rolling, like the phone ... not sure what will happen after vivid release though)
<smoser> Laney, what bug were you talking about ? un-breaking and gnome-terminal
<gQuigs> ogra_: thanks
<tedg> bdmurray, That's correct, you want the error that it wasn't handlable, because that's when it files the recoverable error.
<aeoril> darkxst I am back now.  I looked at bug 1315442 - you may remember this is the last bug I was working on with you. It is status "new" and "confirmed" but not triaged.  I had a fix ready for it some time ago, but was wondering if I needed to do anything to the status before I submit a merge proposal since it is not triaged.  Also, since I have been away so long, I will have to re-orient
<aeoril> myself on it and re-test the fix because I do not remember exactly where I left of on it
<ubottu> bug 1315442 in gdm (Ubuntu Trusty) "Extra "fi" in /etc/init.d/gdm" [Undecided,Confirmed] https://launchpad.net/bugs/1315442
<aeoril> off on it*
<darkxst> aeoril, hi, just submit you merge proposal or debdiff
<darkxst> technically it could be marked triaged, but if your going to fix it, status doesnt matter too much
<aeoril> darkxst ok.  I think I was going to do a debdiff - last thing I had to you in my IRC log files was:
<aeoril> [17:30] <aeoril> darkxst oh, ok - so no problem then.  So, just to make sure, 'dhc -i' (add my comment to ChangeLog), (make my code change), 'sudo apt-get build-dep gdm', 'builddeb -S', 'debdiff old.dsc new.dsc > debdiff_name.debdiff', then attach debdiff to bug ... /??
<darkxst> aeoril, yes, debdiff is fine for gdm
<aeoril> ok, cool - I will try to remember now everything I need to do!  It has been a while, and am a little foggy. Thanks!
<aeoril> darkxst just to remind myself, when I use "dhc -i" and add a new version number, then "run builddeb -S", it will create a new new .dsc file with my changes in it with the name based on my new version number in ChangeLog, so I will have the original .dsc and the new one to run debdiff against, which will then only have my changes shown in it, then attach that to the bug and make a comment
<aeoril> to the effect "I have fixed this - look at the attached debdiff" or whatever?
<aeoril> well, add a comment with and attach the debdiff to it ...
<aeoril> darkxst also, I need to do all this on a vivid machine, not trusty?
<darkxst> its `dh -i`, but yes
<darkxst> you need to fix the vivid package first, but you can do that from trusty and test in a vivid VM
<GunnarHj> smoser: infinity fixed it yesterday, as you already have noticed. Sorry for making that stupid mistake.
<aeoril> darkxst isn't it actually "dch -i"? (to update the changlog)
<aeoril> changelog*
<darkxst> aeoril, yes, seems I can't type before coffee
<aeoril> darkxst just now having coffee?  You must be in Australia or something! :)
<aeoril> darkxst I am having to remind myself - bzr branch lp:gdm will get the latest code from launchpad, which will be a vivid package?  Then I "dch -i", update the changelog, make my code changes, then I "sudo apt-get builddep gdm" then "run builddeb -S" on it to create the .dsc and other necessary stuff, then the appropirate sbuild commnad to build for vivid, then test the binaries created by
<aeoril> sbuild on a vivid vm after installing, then if it all works, 'debdiff old.dsc new.dsc > debdiff_name.debdiff', make a new comment "I fixed it!" and attach debdiff to comment on bug?  (sorry to ask so many questions - I want to make sure I am understanding/remembering how to build on trusty and test on vivid correctly)
<bdmurray> barry: If you are about could you merge https://code.launchpad.net/~brian-murray/aptdaemon/bug-1436725/+merge/255152
<barry> bdmurray: i'm almost eod and trying to finish something before then.  if you haven't gotten it merged by tomorrow, please ping me
<bdmurray> barry: I'm on holiday tomorrow, its a 5 character string change and isn't a huge bug anyway
<infinity> aeoril: I wouldn't guarantee that lp:gdm will be what you want.  If your intent is to produce debdiffs as your final product, not merge proposals, just stick with "pull-lp-source gdm", which is going to more reliably get you the current archive version.
<barry> bdmurray: i'll keep the tab open, but i may not get to it until tomorrow ;)
<aeoril> infinity then don't I need to do that on vivid?  darkxst mentioned I could build a vivid package on trusty then test on vivid - wouldn't "pull-lp-source gdm" on trusty bring me a trusty package?
<infinity> aeoril: No, pull-lp-source defaults to the current devel release.  You could also explicitly say "pull-lp-source gdm vivid" though.
<aeoril> infinity oh, ok - I did not understand.  I thought it pulled for the version of the os you were running it from.  Thanks!  I will read the man page on it now
<aeoril> infinity "If no  version  or  release  is  specified,  the  latest  version  in  the development release will be downloaded." (from the man page) - thanks! :)
<aeoril> infinity but, just to clarify, I would need to use the appropriate sbuild command for vivid (I have the sbuild environment already set up for vivid) to build the binaries from that source for vivid to test on my vivid vm?
<aeoril> In other words, was the rest of what I said accurate in my list of what I need to do other than the part about how to get the source code?
<aeoril> (to build on trusty)
<infinity> aeoril: Well, for sbuild, you can set the default target in .sbuildrc
<infinity> aeoril: Mine is always set to the devel release, you can set yours to whatever you like.
<infinity> $distribution = 'vivid';
<infinity> aeoril: But if you prefer not to set a default then, yes, you'd need to "sbuild -d vivid foo.dsc"
<aeoril> infinity I used "sbuild-launchpad-chroot" to make my sbuild environments, so I would use (IIRC) something like "sbuild --dist=vivid --arch=amd64 -c vivid-proposed+restricted-amd64-sbuild <dsc>" to do my build - see https://lists.ubuntu.com/archives/ubuntu-devel/2013-October/037726.html
* FatBack changed the topic of #ubuntu-devel to: penis
<cyphermox> @pilot out
* udevbot changed the topic of #ubuntu-devel to: penis | Patch Pilots:
<cyphermox> boo udevbot.
* Unit193 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 -> utopic | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<cyphermox> Unit193: thanks.
<Unit193> cyphermox: Sure, though he's still in here.  (BTW, DalekSec == me)
<cyphermox> ah,
<cyphermox> well, I'm attempting to take care of that but I don't have access
<cyphermox> cjwatson: kees: lamont: ^?
<sarnold> thanks hggdh
<wgrant> Has someone reported him to staff?
<wgrant> He's crossed project boundaries now, so a K-line is in order.
<hggdh> sarnold: welcome.
<teward> wgrant: i know sarnold hopped into #freenode briefly
<wgrant> Ah, great.
<teward> wgrant: and i'm trying to find a live staffer to get heavy weapons upon the user asap, but...
<hggdh> wgrant: not yet, in the middle of a meeting
<sarnold> wgrant: I did, but I suspect little will come of it. :/
<aeoril> darkxst infinity I have run into a problem - I used "pull-lp-source gdm" to get the latest source for gdm, and have made my changes and am ready to build, but it is not a bazaar branch, so I cannot run "bzr builddeb -S" to create the new .dsc file.  Should I make it a bazaar branch using "bzr init" or whatever so I can do that, or is there some other better way?
<aeoril> (I looked all over the Internet and found nothing so far)
<wgrant> aeoril: debuild -S
<wgrant> bzr builddeb is a wrapper around debuild.
<aeoril> wgrant ok, thanks :)
<aeoril> wgrant yay!  and debdiff worked great!  Now, just to sbuild and test on vivid machine! :)
<hggdh> wgrant: for the record, no staff seems to be available. Ah well, we tried.
<teward> hggdh: i grabbed hold of one
<hggdh> teward: cool. Let's see what will come of it.
<teward> hggdh: they only just woke up afaict, but if you want, you can poke kloeri, the one who i grabbed hold of
<teward> lurking the gab channel still helps xD
<hggdh> kloeri already saw the beast
<teward> hggdh: and i believe they're going to handle it
<teward> although i suggested the use of IRC operator heavy weapons, the response i got was "I'm handling it"
#ubuntu-devel 2015-04-03
<aeoril> darkxst ugggh.  I've been fighting this for a while.  Google finds lots of stuff, but not what I need.  I cannot install my gdm package:  http://paste.ubuntu.com/10727964/
<aeoril> darkxst I am installing to Ubuntu-Gnome vivid live-cd "Try Ubuntu"
<aeoril> (In a virtual machine)
<sarnold> aeoril: gir1.2-gdm-1.0 appears to be built from the gdm source package: Y
<sarnold> aeoril: https://launchpad.net/ubuntu/+source/gdm
<sarnold> aeoril: did you copy over those binaries too when testing?
<aeoril> sarnold no
<sarnold> you'll need to include it onthe same dpkg -i command..
<aeoril> sarnold omg I see now - there are several .deb files created from sbuild - I guess I need to install all of them, not just he one for gdm?
<sarnold> aeoril: in this case, yes; sometimes they'll spit out cohnflicting packages, like nginx-full vs nginx-tiny, etc. and picking just the ones you want to test is the right answer..
<sarnold> aeoril: but it's surprisingly easy to miss other binary packages that don't match source*deb glob :)
<aeoril> sarnold there are 4 of them - gdm_3.14.1-0ubuntu3_amd64.deb libgdm1_3.14.1-0ubuntu3_amd64.deb gir1.2-gdm-1.0_3.14.1-0ubuntu3_amd64.deb libgdm-dev_3.14.1-0ubuntu3_amd64.deb - do I instal all four of those?
<darkxst> you only need the first 3
<sarnold> aeoril: you can skip the -dev package unless you want to compile code on the test machine that links against libgdm..
<aeoril> sarnold ok, thanks
<aeoril> sarnold cool!  That worked, and thanks again!  Tested, and now I can attach the debdiff to the bug and claim victory! :)
<sarnold> :D
<sarnold> aeoril: very nice :)
<aeoril> sarnold the bug has not been set to "triaged" - it is still confirmed, undecided, unassigned.  Does someone need to set it to triaged?  I don't think I can
<aeoril> sarnold should I just make a new comment - "Fixed - see attached debdiff" and let others take care of all that?
<aeoril> sarnold (I will add proper info to the comment of course)
<sarnold> aeoril: be sure to detail what testing you've done in the comment..
<sarnold> aha good ;)
<aeoril> sarnold this is my third!
<sarnold> aeoril: the actual bugstate is probably less important than getting the fix attached and describe the testing done, etc
<sarnold> aeoril: dude!
<sarnold> aeoril: that's awesome :) you've been busy
<aeoril> sarnold no, not at all - I had to stop from March 1 until today, but am back at it as of this afternoon
<sarnold> aeoril: wow, was that really so long ago?
<sarnold> I have no idea how it became april so quickly. or march..
<aeoril> sarnold yah, a month and a day since March 1!
<sarnold> aeoril: well I'm glad to see you're back, then :)
<aeoril> stuff happens :)
<aeoril> I just took up exactly where I left off - kind of amazing how it all fell into place on this bug today.  But darkxst has been giving me "trivial" bugs so I can get myself aquainted with packaging and stuff like that, so they really have not been too bad
<sarnold> after the firstone, most bugs will feel more trivial .. :)
<aeoril> sarnold I have really learned a lot, but it takes some time.  I have had to test each bug differently and that has been probably the biggest challenge
<aeoril> learning how to build and test and all that
<sarnold> aeoril: yeah, quite often each one requires something slightly different
<sarnold> it's a fun way to stay flexible :)
<aeoril> sarnold you want to look over my patch/comment?  https://bugs.launchpad.net/ubuntu/+source/gdm/+bug/1315442
<ubottu> Launchpad bug 1315442 in gdm (Ubuntu Trusty) "Extra "fi" in /etc/init.d/gdm" [Undecided,Confirmed]
<aeoril> sarnold darkxst I may not be done with this - it needs to be fixed in trusty too - however, the line number is different that needs removing - line 78 in trusty, not line 73.  How would I go about doing that?  Just make the fix and debdiff for trusty, then add another comment/patch to the bug and indicate it is for trusty?
<sarnold> aeoril: the patch is nice and short.. I do wonder if the 'right' fi was removed, so the indenting is left nice and pretty.. I don't see a similar gdm.init on sources.debian.net though, hehe
<sarnold> aeoril: exactly that :)
<aeoril> sarnold yes, I specifically elided the correct 'fi' to leave indenting correct :)
<sarnold> aeoril: sometimes you can get a patch to apply "with fuzz" to different versions, but since this patches a file in debian/ there isn't a standalone patch to work with.. and for one line, it isn't a big deal to recreate it..
<sarnold> aeoril: yay :)
<aeoril> sarnold ok, I'll do that tomorrow
<sarnold> aeoril: I always like to hand-inspect the debdiff.. sometimes it includes a lot of unrelated stuff. it's a good habit to get into to skim the raw debdiff, when it makes sense to do so..
<sarnold> (for simple fixes it almost always will make sense :)
<aeoril> sarnold I carefully checked the debdiff manually
<sarnold> :D
<infinity> slangasek: Around?
<slangasek> infinity: hi
<infinity> slangasek: Sanity check on http://paste.ubuntu.com/10728501/ before I upload and self-accept?
<infinity> slangasek: Context, swift (and other packages, I'm sure, but swift is where I noticed) installs init.d scripts with --no-start, and systemd isn't aware of them existing as "services" until either a reboot or a daemon-reload, which then causes swift's autopkgtests to fail.
<slangasek> infinity: is there a bug report for this?
<infinity> slangasek: Originally, I was going to fix this in the autopkgtests as a hack, but then it just seemed obvious to me that an init.d script that systemd isn't aware of is a bug in systemd, hence the trigger.
<infinity> slangasek: Dunno.  Maybe.  I was cleaning up test failures.
<infinity> slangasek: Anyhow, tested and does what I expect for both old and new triggers.
<slangasek> infinity: I'd rather not be hasty with changes here; it's quite possible that pitti or someone is already planning to fix this somewhere else.  Is the test failure currently blocking?
<infinity> slangasek: It's blocking one other package, and now that I know the root cause, I could let that package pass.  *shrug*
<slangasek> infinity: I'd highly prefer to have pitti review this before upload, I don't want folks working at cross-purposes
<infinity> slangasek: But the only other place this could be fixed is dh_installinit, which would require a rebuild of every --no-start init-script-shipping package, which seems silly.
<slangasek> not necessarily; maybe update-rc.d should be doing it?
<infinity> And if you install an init script without rc.d links?
<infinity> Which isn't a terribly normal thing to do, granted, but...
<slangasek> then you're in violation of policy, go directly to policyjail do not collect 200 policydollars
<infinity> slangasek: To be fair, I just skimmed, but I don't actually see anythign that says I must have links, only that I must control them with update-rc.d if I do.
<infinity> slangasek: Still, a weird thing to do, and yes, update-rc.d would cover the places I've run into the bug.
<infinity> slangasek: Though it would actually run more often than the trigger.
<infinity> slangasek: So, not exactly an optimisation. :P
 * slangasek nods
<infinity> slangasek: Anyhow, I'll give pitti a poke for a review and his thoughts on the matter, maybe with some copy and paste from this conversation.
<slangasek> infinity: ok, cheers.  fwiw I feel like I did hear something about this exact issue recently, but can't pin down the context of it
<infinity> slangasek: I'd been chalking the swift failure up to "the tests don't systemd correctly" until I got annoyed enough to investigate today, and instead came to the conclusion that systemd (as implemented in Debian/Ubuntu) doesn't sysv correctly.
<infinity> slangasek: But yeah, I wouldn't doubt it's come up before.
<darkxst> aeoril, trusty would need  a seperate debdiff , although I not entirely sure it warrants an SRU, it is only a warning isnt it?
<mbiebl> slangasek, infinity: we discussed that on #debian-systemd a while ago when another DD ran into this issue
<mbiebl> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=774799
<ubottu> Debian bug 774799 in sysv-rc "sysv-rc: Unit my-service.service failed to load: No such file or directory, using install from source + update-rc.d" [Important,Open]
<mbiebl> I think I slightly prefer that update-rc.d calls daemon reload
<mbiebl> let's see what pitti thinks
<infinity> mbiebl: Any reason for the preference?  It's more performant as a trigger.
<mbiebl> infinity: someone might install a non-deb package, still using update-rc.d to register the init script
<mbiebl> I also vaguely remember, dpkg-triggers were somewhat problematic with conffiles
<mbiebl> (although that might be outdated nowadays)
<infinity> mbiebl: The trigger worked fine in my testing, but I guess the non-deb thing maybe applies.  I figure that's about as likely as a crappy in-house deb that installs an init script and doesn't use update-rc.d, though.  ie: both are somewhat likely, neither are worth catering to.
<infinity> mbiebl: I'm not super picky about the solution, mind you, but I do think it's RC for both vivid and jessie.
<mbiebl> infinity: have you seen the bug report?
<mbiebl> it was about git cloning fusionforge
<infinity> mbiebl: Yeah, I read the report just now.
<mbiebl> running make post-instlal
<mbiebl> i.e., no dpkg involved here
<infinity> mbiebl: Right, fair point.
<mbiebl> infinity: I agree about the RC-ness of the bug though
<infinity> mbiebl: One could perhaps argue for both the trigger and update-rc.d involvement, to catch both not-normal-package cases, but there's always the corner case of unpackaged-and-also-not-using-our-tools.
<infinity> mbiebl: The RCness, IMO, is only for it misbehaving with Debian packages, mind you, I think it's just Very Unfortunate if we can't fix a few non-archive cases at the same time.
<infinity> mbiebl: The only way to catch them all would be an inotify watch in systemd itself, which I assume you'd object to, or upstream would, or both.
<mbiebl> inotify is not without problems
<mbiebl> and yes, upstream, rejected that so far
<infinity> The only real inotify problem I run into is overlayfs not implementing it.
<infinity> But it still beats "you must know this magic invocation if you install an init script".
<infinity> Whether the magic is update-rc.d or sysctectl daemon-reload or whatever.
<infinity> THough, I suppose most would just get frustrated and reboot, and it would magically work. :P
<mbiebl> iirc, for native services, systemd will implicitly check if you start a service which is not loaded yet
<infinity> mbiebl: But I take the point about github-style deployments that think package managers suck.
<mbiebl> and do a reload then
<mbiebl> we could maybe do the same for sysv init scripts
<mbiebl> that wouldn't catch changed init scripts though
<mbiebl> only new ones
<infinity> mbiebl: Yeah, for native units, it checks for the file.  I suppose one could extend that to "if the native file isn't found, see about an init script, you doofus".
<infinity> mbiebl: Does it actually cache init scripts?  That would be insane.  I assume it just maps an internal service to the path on disk, and still forks them.
<infinity> mbiebl: So, changing them should work fine.
<infinity> mbiebl: I could be wrong, but the idea that it's caching /etc/init.d/* seems insane.
<mbiebl> for /etc/init.d, it runs a generator
<mbiebl> see /run/systemd/generator.late/
<aeoril> darkxst it is a "Syntax Error"
<infinity> mbiebl: Right.  Ahh, sure, it wouldn't catch changes to LSB headers, I guess.
<darkxst> aeoril, does it break the sysv init script?
<infinity> mbiebl: But that's a small and unfortunate corner case that doesn't matter much at runtime anyway, only at boot.
<infinity> mbiebl: And at boot, it'll re-run the generator.
<mbiebl> infinity: at this point, I'd prefer a least invasive change. running daemon-reload in update-rc.d would fit that bill imho and be good enough
 * LocutusOfBorg1 hugs infinity 
<aeoril> darkxst not sure - how would I check that?
<LocutusOfBorg1> infinity, so the kernel module will be available on debian too?
<darkxst> aeoril, you'd need to boot with sysv instead of upstart or systemd
<aeoril> darkxst (googling - no idea how to do that)
<infinity> mbiebl: Yeah, I'm all for minimally invasive so close to both releases.
<infinity> mbiebl: But I think the "right" solution would be for systemd itself to do the moral equivalent of "if no native unit; then if [ -x /etc/init.d/service ]; systemctl daemon-reload; service action"
<infinity> mbiebl: Obviously natively in C where it's doing the native unit check.
<mbiebl> infinity: btw, do you know dpkg file triggers and conffiles can you used safely nowdays?
<mbiebl> the doc still contains: http://paste.debian.net/164615/
<infinity> mbiebl: Define safely.  I think there's still a chance overtriggering, but I've not noticed under-triggering.
<infinity> mbiebl: That's basically saying "a modified conffile won't get twiddled on upgrade, so won't generate a trigger, and if you were hoping for that, sucks to be you".
<infinity> mbiebl: But that's not the case I'm triggering for.  If the init script is already there, I don't need to trigger again on package upgrade.
<mbiebl> infinity: I agree, it would be nice if systemd would pick up the (new) sysv init script automatically
<mbiebl> that would mean though, pulling sysv specific code into the core
<mbiebl> so it's unlikely, that this would be accepted upstream
<mbiebl> where it was moved into a generator a few releases ago
<infinity> Fairly unlikely, yeah, but also not a heavy patch to carry.  I imagine it's all of a few lines to do it well.
<infinity> Anyhow, I agree that a non-C approach is likely best for now.
<infinity> Just worth thinking about a better way.
<infinity> LocutusOfBorg1: No, which is why vbox-guest-dkms should also provide that virtual package.
<infinity> LocutusOfBorg1: I'll work up a nice Debian-and-Ubuntu-friendly diff when I'm done testing how this all fits together.
<infinity> LocutusOfBorg1: Which is waiting on the current kernel to be built and published.  And maybe me having a nap. :P
<infinity> darkxst: An unmatched fi is going to be more than just a warning, it'll halt parsing.
<infinity> darkxst: Likely the only reason it was never noticed was because everyone was booting with upstart and never used the init script.
<didrocks> infinity: (catching up), on the inotify point, one of the issue was that "you may want to install a set of units, and only then commit their existence" (as you are unsure in which order they are unpack, and so, deps are maybe not present yet)
<infinity> mbiebl: Anyhow, if pitti gets back to me over the weekend, I'll CC you in on it, but I'm inclined to take this discussion to a JFDI conclusion in both distros if he's off having a proper vacation and ignoring email. :)
<darkxst> infinity, yes agreed on both points, I'm exhausted from painting all day, clearly not thinking straight!
<infinity> didrocks: But registering a unit's existence doesn't imply immediately starting it, does it?  It certainly doesn't in the case I'm dealing with anyway.
<infinity> didrocks: I guess there's a race there where the sysadmin could try to start a service while apt is still running, but that seems like a "he gets to keep both pieces" situation.
<didrocks> infinity: right, as long as you don't start them, it's fine, but upstream doesn't want to create gap for race if something else on the system pulls that new unit which doesn't have its deps
<didrocks> right
<infinity> didrocks: Anyhow, I'm not a fan of inotify because of the "some filesystems suck" argument, it was just a talking point.
<infinity> didrocks: I think we've settled on update-rc.d and/or trigger to paper over things for now (we just need to settle on the and/or), and then examining maybe a clever fallback in systemd itself later, if we don't mind carrying the patch.
<didrocks> infinity: sure, just giving you more context that the "inotify on some fs doesn't work" isn't the only blocker in upstream's POV
<infinity> mbiebl: ^-- Sound about right?
<didrocks> the trigger is in addition to the generated postinst daemon-reload, right?
<didrocks> (as we start/restart units there)
<infinity> didrocks: I wouldn't consider my inotify argument a blocker upstream at all, they seem pretty keen on positions like "if your system doesn't have feature X, it's not proper Linux" statements.
<infinity> didrocks: There is no postinst reload if you install with --no-start, that's the bug.
<infinity> didrocks: Because there is no postinst reload at all, it's actually in invoke-rc.d
<didrocks> oh right, I just played with this for cloud-init this morning
<didrocks> yeah
<infinity> And while I could make an argument that that's wrong too, it's WAY too late to rebuild literally everything that uses dh_installinit.
<infinity> So, not going down that road.
<didrocks> I guess the trigger is fine, at least conceptually
<infinity> But a trigger fix or update-rc.d fix will paper over just fine.
<didrocks> yeah, not the time to request a mass rebuild of everything using dh_systemd :p
<infinity> And both solve different corner cases that the other misses, which is why I'm slightly inclined toward both.
<infinity> Neither catches every case, but I don't think we can afford to hold out for perfection and avoid progress.
<didrocks> infinity: do we really care about git installation using systemd when someone doesn't know how to use it properly?
<didrocks> I guess there is the arg of backward compat with update-rc/invoke-rc
<infinity> didrocks: Well, the git installation method in the bug report was using update-rc.d, which is the Debian-approved way of doing things.
<infinity> didrocks: So, that seems like it should DTRT.
<didrocks> fair enough
<infinity> didrocks: And, conversely, I think a simple/crappy/non-policy-compliant in-house deb that ships an init script and doesn't use update-rc.d should probably also work.
<infinity> didrocks: We can cover both of those, and then we just miss the "non-packaged and non-update-rc.d" case, which isn't an insiginificant case, but also more invasive to solve. :/
<didrocks> indeed, the solution sounds sane enough to me
<infinity> Although, the non-packaged/non-update-rc.d init script is also less likely to source LSB functions, which then doesn't land it in systemd land.
<infinity> I know I have a few of those lying around. :P
<infinity> Like... All my firewalls.
<mbiebl> infinity: yeah, sounds about right and please keep me posted
<infinity> mbiebl: Do any of your team have carte blanche (within reason) to upload sysvinit in Debian for the update-rc.d fix, or do we need to coordinate with Roger too?
<mbiebl> within the pkg-systemd team, no
<mbiebl> slangasek is the closest to an official sysvinit maintainer aside from roger, petter and hmh
<mbiebl> the latter 3 being very busy/occupied otherwise afaics
<infinity> mbiebl: Alright.  I'll wait on pitti for a day or two, and if he has no input on the matter, I'll consider concensus between you, me, and didrocks good 'nuff, and talk to Roger about the update-rc.d bits.
<infinity> mbiebl: Or talk to Steve, if he's happy pushing it.
<LocutusOfBorg1> infinity, thanks a lot :)
<mbiebl> it's in collab-maint, so we might consider pushing the changes directly
<infinity> mbiebl: Yeah, I'd be happy to push the changes, just less happy about uploading without someone's approval.  People tend to be twitchy about ownership of base packages still here and there.
<infinity> mbiebl: And, usually with good reason.
<mbiebl> nod
<mbiebl> looks like Petter is the most active one just looking at the recent history
<mbiebl> getting an ack from Steve or Petter looks like the most promising approach
<infinity> Right.  I'll chase that up tomorrow before I lose context on all of it.
<infinity> mbiebl: And thanks for the input, the Debian bug lent insight.
<mbiebl> np
<aeoril> darkxst How do I start using sysv?
<darkxst> aeoril, I don't know
<aeoril> darkxst neither did my googld search ... :(
<infinity> aeoril: You don't in Ubuntu.  We only support upstart and systemd.
<infinity> aeoril: But running the init script seems to be enough to trigger the bug, doesn't it?
<aeoril> infinity I can trigger the bug by just running /etc/init.d/gdm
<infinity> aeoril: Right, then no need to do a whole sysv boot, really.  Between running the script and a visual confirmation by someone who can count opens versus closures, it should suffice.
<aeoril> infinity good.  The current debdiff works for vivid.  I will add a new debdiff after doing the fix for trusty and attach it to the bug as well, indicating it is for trusty.  Then, we will have a debdiff for vivid and another for trusty.  The bug is the same, the difference is that in trusty I need to remove the "fi" line 78 while on vivid it is line 73.  Does that all seem reasonable?
<infinity> aeoril: Yeah.  Should probably be fixed in utopic too, FWIW.
<aeoril> infinity ok, will do.  Thanks
<aeoril> (tomorrow)
<seb128> @sponsor on
<udevbot> Error: "sponsor" is not a valid command.
<seb128> @pilot on
<udevbot> (pilot (in|out)) -- Set yourself an in or out of patch pilot.
<seb128> @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 -> utopic | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: seb128
<infinity> seb128: Heh.  That's what you get for trying to operate IRC on a holiday.
<seb128> lol
<seb128> yeah, I was off yesterday afternoon so doing some sponsoring today in exchange :-)
<infinity> seb128: Yeah, I'm in a similar "I slacked a bit, and making up for it" boat.
<seb128> infinity, ogra_, cyphermox, can one of you merge/upload https://code.launchpad.net/~darkxst/ubiquity-slideshow-ubuntu/vivid/+merge/254490 ? it looks fine but coredev seems to not have access to that vcs...
<Riddell> tseliot: am I right in thinking your sddm patch is still a work in progress and not ready for upload?
<tseliot> Riddell: yes, I'm still waiting for a reply from David Edmunson
<tseliot> especially about the two leaks that I fixed
<tseliot> (one was already there)
<Riddell> tseliot: thanks, I've pinged him :)
<tseliot> Riddell: thanks
<aeoril> I have a machine I am running trusty 14.04.1 LTS on.  I use it to do builds using sbuild when doing bug fixes.  Should I upgrade this to 14.04.2 for any reason?
<darkxst> aeoril, it will already be 14.04.2 if you do the regular updates
<aeoril> oh, ok - will do then
<darkxst> (minus the HWE stack) which is opt-in and probably not much use if X is working fine for you
<infinity> aeoril: "lsb_release -a" should say 14.04.2 already, unless you never upgrade.
<aeoril> infinity yes, I just did that already - it is indeed 14.04.2 ...
<aeoril> thanks, guys!
<Riddell> tseliot: have you actually tested sddm with nvidia-prime? does it work for you?
<seb128> Riddell, hey, speaking of sddm, there is https://code.launchpad.net/~dan-mcgregor/ubuntu/vivid/sddm/fix-zsh/+merge/255127 in the sponsoring queue ;-)
<darkxst> infinity, Ive seen crash reports on errors.u.c of people that have never upgraded once since trusty was realeased!'
<tseliot> Riddell: I haven't had the chance to test it yet (but I will). My work is based on what I did for lightdm though, and it reuses code that was already there in sddm (for the DisplayCommand parameter), so, in addition to building fine, it should also work.
<Riddell> ooh thanks seb128
<seb128> Riddell, yw!
<dz0ny> ok why is this triaged as invalid https://bugs.launchpad.net/ubuntu/+source/gparted/+bug/1432176
<ubottu> Error: malone bug 1432176 not found
<aeoril> Is this OK with apt-get upgrade on 14.04.2? "The following packages have been kept back: liboxideqt-qmlplugin linux-generic linux-headers-generic linux-image-generic"
<infinity> aeoril: You want "apt-get dist-upgrade"
<infinity> aeoril: "upgrade" refuses to add/remove packages.
<aeoril> ok, thanks - should I always use "dist-upgrade" instead of "upgrade" then?
<infinity> aeoril: Generally, yes, just pay attention to what it wants to do.  If it's asking to remove a bunch of things, something may have gone wrong and you might want to say "no". :)
<aeoril> ok, will do ... :)
<infinity> dz0ny: Because, due to outdated packages, it was impossible to generate a useful stack trace, so it's not particularly debuggable.  If you can provide exact reproduction steps to make the crash happen on a current version, reopening it would be fine.
<infinity> dz0ny: Oh, and you also have non-Ubuntu packages installed, which is almost certainly the source of the bug, based on the limited stacktrace we did get.
<dz0ny> infinity: mhm, I realized that last bit now. I have gnome staging ppa and that seems to be the cause
<aeoril> infinity thanks, that worked!
<LocutusOfBorg1> seb128, hi, since the trusty release is an LTS and I did a mistake in non using the standard patch notation in the previous upload I would like to rename it if possible
<LocutusOfBorg1> I hope you understand, if not possible, feel free to filter that part :)
<seb128> LocutusOfBorg1, hey, ok, wfm
<LocutusOfBorg1> thanks!
<seb128> LocutusOfBorg1, can you make the bug SRU compliant? (impact/test case/regression potential in the description)?
<LocutusOfBorg1> in a few minutes
<LocutusOfBorg1> done!
<seb128> LocutusOfBorg1, thanks
<aeoril> I seem to be unable to edit my comment on bug 1315442 - #7 - I want to change it to mention the fix is for the vivid version specifically
<ubottu> bug 1315442 in gdm (Ubuntu Trusty) "Extra "fi" in /etc/init.d/gdm" [Undecided,Confirmed] https://launchpad.net/bugs/1315442
<seb128> smoser, hey, could you review https://code.launchpad.net/~niedbalski/ubuntu/vivid/curtin/fix-1263181/+merge/250163 it's in the sponsoring queue for a while (and the reported seems a bit grumpy on the bug by the lack of feedback, he states that things are just not working at the moment)
<seb128> aeoril, I don't think you can edit commit, just add a new one?
<aeoril> seb128 ok, will do - thanks - I cannot find anyway to edit the comment
<seb128> aeoril, right, you can't
<aeoril> ok, thanks seb128
<LocutusOfBorg1> thanks to you seb128 :)
<LocutusOfBorg1> I'm wondering if dholbach is on VAC :)
<LocutusOfBorg1> seb128, BTW I would like to have a feedback for https://bugs.launchpad.net/ubuntu/+source/virtualbox/+bug/1424769
<ubottu> Launchpad bug 1424769 in virtualbox (Ubuntu) "virtualbox-guest-x11 uninstallable with mesa-lts-utopic" [Undecided,Confirmed]
<LocutusOfBorg1> if possible :)
<aeoril> sarnold or infinity or darkxst would you mind looking here?  I added the patch for trusty:  https://bugs.launchpad.net/ubuntu/+source/gdm/+bug/1315442 (comment #9)
<seb128> LocutusOfBorg1, today is an holiday in Germany (good friday)
<ubottu> Launchpad bug 1315442 in gdm (Ubuntu Trusty) "Extra "fi" in /etc/init.d/gdm" [Undecided,Confirmed]
<darkxst> aeoril, probably ok from a quick glance, will sponsor over the weekend when I find time
<aeoril> darkxst ok, thanks - this is starting to get easier! :)
<aeoril> darkxst I still need to do the utopic fix - will do soon
<darkxst> aeoril, time to find your own bug to fix ;)
<aeoril> darkxst this is a lot of fun! :D
<aeoril> darkxst I need to do a fix with some good coding in it!
<seb128> LocutusOfBorg1, I don't know the package much but I think added -lts variants makes sense in the context of the renamed xorg stacks
<aeoril> s/good/real/
<LocutusOfBorg1> seb128, thanks, but he wasn't there also yesterday maybe :)
<seb128> LocutusOfBorg1, yeah, maybe it's taking some extra days for a long easter w.e
<LocutusOfBorg1> I hope he is having a good time then ;)
<aeoril> darkxst I have my own bug to fix!  I just don't have the ability to fix it! (that one I worked on forever about vim/gnome-terminal)
<seb128> @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 -> utopic | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<darkxst>  aeoril I meant for you to find a bug you can fix
<aeoril> darkxst as opposed to you finding them for me?
<darkxst> yes
<aeoril> darkxst will do, thanks for all your help :)
<darkxst> aeoril, np, Im off to bed now
<aeoril> darkxst night!
<aeoril> darkxst I am going to look for a fix that has some c code in it
<aeoril> (I have not coded in C for a while)
<didrocks> @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 -> utopic | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: didrocks
<aeoril> didrocks I see you are my patch pilot!  Just looked up what that was!
<aeoril> s/my/our/
<didrocks> aeoril: the gdm thing? I'm unsure to understand how that impacts the ubuntu gnome guys as there is an upstart job (gdm.conf) for it, right?
<aeoril> didrocks not sure, actually - I am new
<aeoril> didrocks I was just commenting that I noticed you were the patch pilot - I did not know there was such a thing
<didrocks> aeoril: ah ok, no worry! I saw you were discussing about the gdm bug, I'll let the ubuntu gnome team deciding on it, but it's a bug fix that debian may benefit from, not ubuntu as we only support upstart and systemd
<aeoril> didrocks if they wanted to manually use /etc/init.d/gdm to start/stop/whatever the service, it would affect them though
<didrocks> aeoril: not something that they should do (because a lot of other things will be broken, even if it works), and not something that we support at all
<aeoril> didrocks oh, ok - what do I do to make the patch available to debian, if anything, or will the ubuntu-gnome people do that?
<didrocks> aeoril: if you want to handle it and push to debian, that would be rocking, there is a wiki page about it, one sec
<darkxst> aeoril, you don't, there is a massive delta on gdm between debian and ubuntu
<aeoril> didrocks I might as well!  If I never do it, I won't learn!
<aeoril> darkxst oh, ok
<didrocks> darkxst: you think the gdm init script is different?
<darkxst> didrocks, I need to finish my gdm3 merge first ! before that is possible
<didrocks> let me look at the init script, one sec
<didrocks> aeoril: for reference (I'll tell you here if the bug applies to them in a sec): https://wiki.ubuntu.com/Debian/ForUbuntuDevelopers#Forwarding_bug_reports
<didrocks> aeoril: attaching a patch to the forwarded bug report
<aeoril> didrocks ok, thanks for the link :)
<didrocks> aeoril: yeah, they don't have that bug
<aeoril> didrocks ok, thanks anyway :)
<didrocks> (their init script is different, which is normal, as they support sysv)
<didrocks> aeoril: yw!
<aeoril> didrocks yah, I would figure if they support it, it probably works better already!
<didrocks> yeah ;)
<aeoril> didrocks why do we have the sysv stuff at all if we don't support it?  I mean, if you cannot even use it manually even, what is the point?
<didrocks> aeoril: debian supports multiple init system, ubuntu always supported one (upstart until now, and systemd but on some flavors)
<didrocks> we removed most of the init scripts in the past
<didrocks> but TBH, that was more a burden than anything in the end, to keep a delta with debian just for this
<didrocks> and under systemd, sysv init scripts are ignored if there is a systemd unit
<aeoril> didrocks why did we not remove all the sysv scripts if we cannot even use them?
<didrocks> aeoril: as told, we did it in the past, but as we merge regularly from debian, a lot of packages only had those removals as a delta
<didrocks> so we couldn't sync automatically
<didrocks> and it introduces uncessary diff
<didrocks> noting that the size on disk is really negligeable
<aeoril> didrocks oh, sorry - I misunderstood.  I think I understand now.
<didrocks> (472K for instance on my machine, which has a lot more packages than the standard installation)
<darkxst> didrocks, gdm is way out of sync, but I was trying to go to bed half an hour a go
<darkxst> really going now
<didrocks> darkxst: enjoy your long week-end :)
<aeoril> didrocks so, we removed them in the past, but now we just leave them in because they come from debian?
<didrocks> right
<darkxst> didrocks, it already started and I am exhausted after day 1!
<aeoril> didrocks ok, gotcha.  Thanks for the explanation
<didrocks> darkxst: 3 more days for you to rest!
<didrocks> aeoril: yw, do not hesitate if you have any other questions :)
<aeoril> darkxst thanks for all your support!  Good night! I hope you have a nice holiday!
<aeoril> didrocks I do have one question - you mentioned this earlier, but I want to clarify - this whole fix may be pointless, because we cannot use the scripts, but you leave it to the ubuntu gnome people to decide?
<didrocks> aeoril: exactly, they are the ones touching the most of those packages, so if they want to add that fix to other changes in an upload, that's fine. I just don't think it worthes an upload on its own
<didrocks> (especially when fixing older releases, where the process is way more involved)
<aeoril> didrocks ok.  I have put the patches for vivid and trusty into the bug report.  I will go ahead and do utopic as well for completeness - it is easy at this point and does not take much time
<didrocks> sure :)
<aeoril> didrocks caffeine is amazing ... I can do the utopic patch now ... lol
<aeoril> (until I crash)
<didrocks> ahah ;)
<seb128> barry, hey, could you look at https://code.launchpad.net/~brunonova/oneconf/lp1165104/+merge/198429 ? it's waiting for feedback from you since 2013, the contributor seems a bit disappointed since :-/
<seb128> cyphermox, (or somebody else looking at foundation things, maybe infinity?) could be get https://code.launchpad.net/~tj/ubuntu/trusty/grub-installer/lp1354730/+merge/230222 merged or rejected?
<seb128> it's a one liner, it feels like we should be able to do the tweak Colin suggested and merge in if the change is right
<seb128> tyhicks, kirkland, hey, could you review https://bugs.launchpad.net/ubuntu/+source/ecryptfs-utils/+bug/1406940 ?it's in the sponsoring queue waiting since january 1st
<ubottu> Launchpad bug 1406940 in ecryptfs-utils (Ubuntu) "ecryptfs does not work for domain users (AD, likewise/powerbroker)" [Undecided,New]
<cyphermox> seb128: I'm off today but since I've looked, I might as well review this :)
<cyphermox> ah, that one
<seb128> cyphermox, thanks, and that can wait next week, sorry for the ping on a day off, I assumed you would just get the backlog when you are back next week, I didn't meant to nag you on a vac day
<cyphermox> no, rejecting; I had applied it in vivid and it broke things
<seb128> k
<seb128> thanks
<seb128> cyphermox, btw, did you do something about the nm-applet issue from the other day?
<cyphermox> seb128: which?
<cyphermox> the crash, yes
<seb128> cyphermox, the segfault
<seb128> right
<seb128> great
<cyphermox> should be in archive now
<seb128> cyphermox, oh, I somewhat didn't notice the upload on vivid-changes, great, thanks ;-)
<seb128> cyphermox, did you upstream the fix? the patch has no header, but I think it impacts upstream as well since fedora had similar reports
<cyphermox> oh, no
<cyphermox> but it really looks like something broken by indicator, not by upstream
<cyphermox> ie. fails because of hows things get started when you initialize the indicators
<cyphermox> I'll get back to this on Monday
<seb128> cyphermox, weird, https://retrace.fedoraproject.org/faf/reports/352711/ seems similar
<cyphermox> hmm, it really does
<cyphermox> in any case, I think this should help a whole lot, but it's indicator-specific anyway
<seb128> cyphermox, that's why I suggested upstreaming it the other day :-)
<cyphermox> I'll discuss the details with dcbw on monday
<seb128> thanks
<seb128> isn't monday off for you?
<cyphermox> maybe there is a something else to do
<cyphermox> nope
<seb128> k
<cyphermox> maybe it's off for him though
<cyphermox> most things already assert that devinfo is there (it being null causes the crash)
<seb128> tuesday is fine a well :-)
<cyphermox> and it's expected to be set when devices are initially discovered
<cyphermox> but I can't assert in this case, maybe just ignoring the device if it doesn't have the devinfo struct
<seb128> k
<seb128> doko_, hey, could you review https://bugs.launchpad.net/ubuntu/+source/openjdk-8/+bug/1411630 ? mitya57 pointed on the bug that the change should probably be including in Debian as well, it's waiting in the sponsoring queue since january
<ubottu> Launchpad bug 1411630 in openjdk-8 (Ubuntu) "Build-Depends cannot be fulfilled in precise" [Undecided,New]
<doko_> seb128, sure, next free work day, which is Thu or Mon in a week
<doko_> and I'm not keen on mitya57's patches ... there are still syncs initiated by mitya57 which ftbfs in -proposed
<seb128> doko_, no hurry, should I just unsubscribe sponsors and assign to you?
<doko_> seb128, sure, I can have a look
<seb128> doko_, thanks
<seb128> doko_, enjoy the easter days ;-)
<smoser> seb128, that was on my list fl things to do today.
<seb128> smoser, great, thanks :-)
<smoser> infinity, didrocks took a look at bug 1438520 and got a fix going forward, but we are wondering if there is a way to skip old prerm.
<ubottu> bug 1438520 in cloud-init (Ubuntu) "cloud-init on vivid upgrade causes sigterm, which aborts 'runcmd' execution" [High,Confirmed] https://launchpad.net/bugs/1438520
<smoser> so that we could allow an upgrade to actually fix a system right now, rather than only future systems that don't have broken cloud-init.
<smoser> anyone else is welcome to suggest fix also, it doesn't have to be â
<strikov> smoser: okay, so cloud-init gets restarted during upgrade, but maybe we can simply re-run initialization if (a) cloud-init start and (b) doesn't see 'init was successful' marker in /var/lib/<don't remember>?
<smoser> strikov, so the problem is that cloud-init is in the image, and running 'upgrade'.
<smoser> that upgrade triggers cloud-init upgrade.
<smoser> which causes the series of maintainer scripts described at https://wiki.debian.org/MaintainerScripts
<smoser> (upgrade)  to run.
<strikov> smoser: yep; cloud-init gets stopped (restarted)
<smoser> and the pre-rm script there says "stop"
<strikov> smoser: but why it doesn't finish initialization next time it runs?
<smoser> so didrocks fix, which is right is to tell packaging "you dont want to stop or start or restart" (which is actually the behavior we want).
<strikov> smoser: i.e. stop/start, oops i didn't finish init last time, let's do it now
<smoser> but we have to deliver that configuration and have no way other thna packaging to do it.
<smoser> strikov, it does finish next time.
<smoser> but "next time" is on reboot
<smoser> the problem will go away when we have images with cloud-init at this next (non-broken) version inside them.
<strikov> smoser: yeah, that's the point; maybe we need to re-init not on reboot but every time with *start* cloud init but 'init finished' marked doesn't exist
<strikov> smoser: then, it does everything needed when upgrade starts it after upgrade
<smoser> hm.., yeah, so why didn't that happen....
<smoser> oh i thikn maybe because its a "one shot" service (Type=oneshot)
<smoser> that the 'restart' only did a 'stop'.
<smoser> effectively.
<strikov> smoser: if we fix this (somehow) i think that upgrade will work fine; it stops during prerm, then starts on postint, cloud-init re-inits and we're done
<smoser> i think i'm just going to upload the fix, an then we'll try to get "beta3" images made . so that only people that run the beta2 (out of date) image will see the issue.
<smoser> it seems the least invasive, and i can think of further problems by it (basically it will then be behaving like upstart did)
<smoser> strikov, your solution could definitely work though.
<strikov> smoser: by uploading the fix you mean didrock's one or oneshot?
<smoser> didrocks solution.
<smoser> right now it *is* oneshot. (which it should be, its essentially a task not to be restarted when it exits)
<didrocks> yeah, it should be oneshot
<smoser> and i think that is why it doesn't get started on 'restart'
<smoser> it just gets stopped
<strikov> smoser: yeah, it should work i think; hope we don't meet oneshot issue later
<strikov> smoser: ah, btw, does it mean that cloud-init is not upgradable?
<strikov> smoser: because we basically use the old one even if we have upgrade available?
<aeoril> didrocks Lintian questions:  http://paste.ubuntu.com/10730634/ should I worry about this error and warning?
<strikov> smoser: can we meet some issues if 'data' gets unpacked from new cloud-init but 'code' is from the previous one
<smoser> strikov, well, it could . its just the 'cloud-config' portion that upgrades itself. so those modules.  you're right though.
<smoser> if there was a data format change, new versions would have to find they were using the old version's data and support it.
<aeoril> didrocks also, the debdiff had a change in it I did not make - it appears the .dsc included with the utopic gdm package has an out-of-date .dsc in it???
<smoser> we have done some thing slike that before. when modules change names, it will rename the marker files.
<didrocks> aeoril: no, that's fine (the utopic is due to your version of some packages not backported) and the standard-versions is not updated to latest, but you don't want to do that in a released version
<didrocks> aeoril: you can use lintian-info --tags <the tag shown> to get more info btw
<aeoril> didrocks what about the debdiff having an extra change in it that I did not make?
<didrocks> aeoril: that's weird, do you have it handy?
<didrocks> like pastebin it
<aeoril> didrocks sure:  http://paste.ubuntu.com/10730665/ lines 15-26 should not be there ... it looks like the .dsc included in the package is out of date ...
<didrocks> ah that
<didrocks> aeoril: don't worry, the uploaders lines are autoupdated (this is for debian)
<didrocks> no incidence in ubuntu in practice :)
<aeoril> didrocks not sure what you mean ... do you mean that this fix will only be used by debian?
<aeoril> (per our previous discussion)
<didrocks> aeoril: it's not really a "fix", it's a field used in debian to determine who can upload a package when some of the packages are co-maintained
<didrocks> aeoril: after a while if someone didn't upload that package, he/she will be stripped out of the Uploaders: list
<didrocks> but this is really just used in debian, not ubuntu
<aeoril> oh, ok - thanks - I understand now
<didrocks> aeoril: more information on https://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-Uploaders
<smoser> didrocks, i've updated that bug with 2 comments, one describing what we decided to do and why, and the other showing how i tested that the solution fixes this problem.
 * didrocks looks
<didrocks> smoser: looking good, thanks for summarizing :)
<smoser> ugh
<smoser> except for i didn't actually test it.
<smoser> the ppa build failed
<smoser> https://launchpadlibrarian.net/201943285/buildlog_ubuntu-vivid-amd64.cloud-init_0.7.7%7Ebzr1088-0ubuntu2%7Esm1_BUILDING.txt.gz
<smoser> the build environment doesn't have /sbin/ip i guess. :-(
<smoser> that recently changed
<didrocks> argh
<didrocks> @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 -> utopic | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<aeoril> didrocks thanks for all your help.  I got the final patch attached for bug 1315442.  It is up to darkxst now.
<ubottu> bug 1315442 in gdm (Ubuntu Trusty) "Extra "fi" in /etc/init.d/gdm" [Undecided,Confirmed] https://launchpad.net/bugs/1315442
<seb128> hallyn, tyhicks, do you think https://bugs.launchpad.net/ubuntu/+source/click/+bug/1427264 is likely to be fixed for vivid?
<ubottu> Launchpad bug 1427264 in click (Ubuntu) "using ecryptfs, creating frameworks fail to bind mount issues" [High,Triaged]
<hallyn> seb128: no idea, i wasn't looking at it
<hallyn> i thought tyhicks was working on it
<hallyn> infinity: http://paste.ubuntu.com/10731209/   have you ever seen this?
<hallyn> my program just does a fork() and seems to hit an assert inside fork inside libc and get hung
<hallyn> i'll do some extra bookkeeping so i can kill that task if/when that happens, but it'd be nicer if that didn't happen :)
 * hallyn tried to peek inside libc's fork but got lost somewhere on the minotaur level
<hallyn> it's libnih-dbus so maybe it's an at_fork handler i didn't know was being registered
<hallyn> jinkeys, looks like
<hallyn>       assert (THREAD_GETMEM (self, tid) != ppid);
<hallyn> may be failing, bc pid is 0
<hallyn> no, ppid is listed as 605.  but that's wrong bc we had just done a setns(/proc/pid/ns/pid) before the fork, so pid is iddferent
<hallyn> so presumably that's why this is racy - fork happens to have given me in the new pidns the pid of the parent in th eparent pidns
<tyhicks> seb128: that fix stalled while I was investigating other issues that smoser reported to me which were similar symptoms but different causes
<hallyn> yup that's what's going on.  is there a way to force libc to update it's cached values i wonder
<tyhicks> seb128: I hope to circle back to all the systemd/schroot/sbuild/ecryptfs bugs next week and prepare fixes
<seb128> tyhicks, ok, great, thanks
<kirkland> tyhicks: did you happen to track down that boot/login critical problem?
<seb128> tyhicks, sorry for being naggy about that, but vivid release is soon, and that issue is quite annoying for dev who want to write apps for the phone
<tyhicks> kirkland: no, I'm about to start debugging it again
<hallyn> arguably libc's setns should just do that for us
<tyhicks> seb128: I understand - sbuild/schroot internals are outside of my comfort zone
<tyhicks> kirkland: I created bug #1439849 for that issue
<ubottu> bug 1439849 in linux (Ubuntu) "BUG: unable to handle kernel NULL pointer dereference at 0000000000000010" [Critical,Confirmed] https://launchpad.net/bugs/1439849
<smoser> seb128, sorry i took tyhicks off on a wild goose chase.
<smoser> (well, not entirely wild)
<seb128> tyhicks, yeah, seems it's difficult to find somebody who has those in their confort zone though :-/
 * tyhicks nods
<seb128> smoser, no worry, I'm sure you have good reasons :-)
<tyhicks> kirkland: will you be able to https://bugs.launchpad.net/ubuntu/+source/ecryptfs-utils/+bug/1406940 ? There's no chance that I'll get to it before release.
<ubottu> Launchpad bug 1406940 in ecryptfs-utils (Ubuntu) "ecryptfs does not work for domain users (AD, likewise/powerbroker)" [Undecided,New]
<tyhicks> s/will you be able to/will you be able to review/
<mitya57> doko: Which of my syncs FTBFS? It seems to me that I am not aware of that.
<doko> mitya57, https://launchpad.net/ubuntu/+source/webkit2gtk/2.6.2+dfsg1-4
<doko> also a good idea to watch http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html
<mitya57> doko: I will look ASAP (maybe tomorrow). And I am watching that page, but it has a lot of entries so it's easy to miss something.
<doko> heh, sure, but don't you get emails for build failures too?
<mitya57> No, I don't see any mails about webkit2gtk in my inbox, except the "accepted into proposed" one.
<mitya57> I think they are not sent to the sync sponsor.
<tseliot> Riddell: apparently I also need to check (in gpu-manager) that sddm is the default. How do I do that? There's no /etc/X11/default-display-manager
<tseliot> or gpu-manager will refuse to configure the system
<Riddell> um, I don't know
<Riddell> tseliot: I guess there should be /etc/X11/default-display-manager ?
<tseliot> Riddell: I've just installed today's image and it's not there
<tseliot> Kubuntu 15.04 daily
<Riddell> tseliot: yes I confirm there's not, I guess it's a bug in the sddm packaging
<tseliot> Riddell: ok, I hope this can be fixed soon. I'll write the file manually for now
<tseliot> Riddell: does sddm have a log that I can use for debugging?
<tseliot> Riddell: as it seems to ignore my settings in /etc/sddm.conf
<Riddell> tseliot: /var/log/sddm.log ?
<tseliot> Riddell: oh, I see the problem now. Thanks
<sarnold> aeoril: there's a debian/control change in your utopic debdiff that I don't understand but the fix and changelog look good in both
<aeoril> sarnold thanks for looking at it - I figure the .dsc must have been out of date on that "pull-lp-source" package.  I did not make that debian/control file change
<aeoril> sarnold I think it was didrocks that told me it was ok - just a debian thing, doesn't matter in Ubuntu???
<aeoril> sarnold three down, thousands to go!
<sarnold> aeoril: yeah it probably doesn't actually matter; it just seemed out of place
<sarnold> aeoril woo :)
<aeoril> lol fun fun!
<aeoril> darkxst informed me it is time to find a new bug on my own :)  I want to find one with a non-trivial code change, preferably in C
<aeoril> sarnold well, off to lunch ... thanks again ... :)
<tseliot> Riddell: I had to make DisplayCommand blocking too (being a qprocess), or the script would get killed too soon. At least I'm not getting a black screen now (it all works on login). Something goes wrong on log out. I'll have another look at it next week
<sarnold> aeoril: bon apetite :)
<Riddell> tseliot++ thanks so much
<tseliot> np
<sarnold> aeoril: a pal ran into this bug yesterday.. lshw crashes when reading his uefi FAT filesystem.. https://bugs.launchpad.net/ubuntu/+source/lshw/+bug/1437681
<ubottu> Launchpad bug 1437681 in lshw (Ubuntu) "lshw-gtk assert failure: *** stack smashing detected ***: lshw-gtk terminated" [Medium,Confirmed]
<aeoril> sarnold ok, thanks - I'll look into it after I get back from lunch ... I'm hungry for food and bugs to kill!
<aeoril> sarnold sweet - stack smashing!
<sarnold> :)
<mitya57> doko: webkit2gtk fix is in archive, already built on one architecture
<mdeslaur> cyphermox: so network manager no longer shows the dumb bridge devices, but I still got a notify osd "You are now connected to virbr0"
<doko> mitya57, \o/
<mdeslaur> cyphermox: bug 1440166
<ubottu> bug 1440166 in network-manager-applet (Ubuntu) "network indicator displays notifications for virtual devices" [Undecided,New] https://launchpad.net/bugs/1440166
<aeoril> sarnold is this the "correct" place to get the source files for lshw-gtk? http://packages.ubuntu.com/source/vivid/lshw
<sarnold> aeoril: I've found cases when packages.ubuntu.com data wasn't up to date; I prefer looking in launchpad.net/ubuntu/+source/<sourcepackagename>
<sarnold> aeoril: so in this case, https://launchpad.net/ubuntu/+source/lshw
<sarnold> aeoril: pull-lp-source should dtrt though
<aeoril> sarnold pull-lp-source said "pull-lp-source: Error: The source package 'lshw-gtk' does not exist in the Ubuntu primary archive in vivid, vivid-security, vivid-updates or vivid-proposed" - is there any way to configure it so it finds the right source for lshw?
<aeoril> sarnold oh, I know - "pull-lp-source lshw" ... right?
<sarnold> aeoril: no, the best way I know to find the source package is to use apt-cache show lshw-gtk | grep ^Source
<sarnold> yeah, exactly
<sarnold> aeoril: if there's no Source: line, then its source package is named the same..
<aeoril> sarnold I just found out lshw and lshw-gtk were the same source package
<aeoril> sarnold I do not understand your last comment
<aeoril> sarnold Source: line where?
<sarnold> aeoril: it's difficult to find the correct source package for a given binary package; the apt-cache show ... | grep ^Source: trick willtell you the source package name unless the name of the binary package matches the name of the source package, in which case the Source: line is absent
<aeoril> oh, ok - I see now
<aeoril> sarnold I'll tuck that away
<aeoril> sarnold when I use pull-lp-source, it won't work unless I sudo it.  This leaves all the entire contents with root as owner/group.  I always have to do chown and chgrp so I can use them as myself.  Is this normal?
<sarnold> aeoril: probably you're running it from a root-owned directory; if you run it in a directory you already own it ought to work unprivileged
<aeoril> sarnold no, I am running it from my home directory - I just checked, and the directory in which I just ran it is owned by me
<sarnold> aeoril: well, the next step is to figure out why :) "strace -o /tmp/pull -f pull-lp-source lshw" and then look through /tmp/pull to find the permission denied messages that indicate you needed to use privileges to run it..
<kirkland> barry: howdy!  still around?
<kirkland> barry: wanna help me snapify ssh-import-id?
<kirkland> barry: doesn't that sound like the perfect day to end the week?  :-)
<barry> kirkland: hi.  i need to leave a little early today, but i have a few minutes
<kirkland> barry: sweet
<barry> :)
<kirkland> barry: is this the best channel to hold this conversation?
<barry> kirkland: maybe #snappy-devel
<barry> er, #snappy
<mdeslaur> cyphermox: I've attached a debdiff to bug 1440166 for your approval
<ubottu> bug 1440166 in network-manager-applet (Ubuntu) "network indicator displays notifications for virtual devices" [Undecided,New] https://launchpad.net/bugs/1440166
<aeoril> sarnold I had root owner/group on ~/.launchpadlib - not sure why - I am guessing the first time I ran pull-lp-source, I ran it as root and it created that directory structure as root???
<aeoril> sarnold anyway, everything working now
<aeoril> sarnold thanks :)
<Unit193> kirkland: Oooh, speaking of such, did you get the paste?
<aeoril> Unit193 hey, I have fixed three bugs now!  Long time no chat!
<Unit193> Howdy.
<aeoril> Unit193 you remember me from #ubuntu-beginners-team?
<Unit193> Of course.  Congrats.
<aeoril> Unit193 yes, I am actually doing some meaningful work and have finally started contributing after all these years.  Hope all is well with you.
<aeoril> Unit193 I took a detour for 3 years into Javascript/Web development, but am back now
<Unit193> Heh, you were playing with websockets back then too.
<aeoril> Unit193 yes, I started getting into a little node stuff even back then.  Had a great time doing Javascript - fascinating stuff!  It was amazing to see the technology unfolding rapidly in just the three years I was involved - simply amazing, actually!
<aeoril> Unit193 the development tools and pretty much everything in browsers was just changing so fast and really good stuff
<kirkland> Unit193: hiya -- the bitbucket stuff -- yeah, I need to create a bitbucket account so I can test it myself
<kirkland> Unit193: it's on my list, haven't gotten to it yet
<Unit193> kirkland: Ah, sorry about that.  In case you didn't have it https://bitbucket.org/snippets/unit193/q8My I left the copyright stuff there since it was minimal changes.
<kirkland> Unit193: very good, I'll get it
<Unit193> Sure, no rush at all.
<Unit193> kirkland: And, poked them about being able to retrive keys not owned by you.
<kirkland> Unit193: yeah, no kidding -- they really should remove the auth requirement on that
<kirkland> Unit193: it's a friggin PUBLIC key!
<infinity> smoser: Sure you sorted this out while I was asleep, but old-prerm is the very first thing called in an upgrade, you can't override it.
<infinity> hallyn: I've never seen lll explode on a simple fork, no.  I assume it's not actually all that simple, once the entire thing is unwound.
<hallyn> yeah it's not "that" simple - but surprisingly easy to make happen
<hallyn> part of hte problem is containers start with lowe rpids so it's almost guaranteed to eventually happen if you keep trying
<sarnold> aeoril: aha! nice :)
<aeoril> sarnold yes, I saw that on the stack trace dumped immediately to the screen, but misread the line and thought that that file was in the directory I was pulling hte source into.  Once I looked at it again and saw it was in the root of my home directory, it became obvious after checking permissions.
<darkxst> aeoril, you deleted the vivid patch from the bug?
<aeoril> darkxst no - I deleted a misbegotten utopic patch (wrong debdiff) then reuploaded the correct utopic patch - there should be three now - vivid, trusty and utopic ... let me check ...
<aeoril> darkxst apparently, I somehow deleted the vivid patch.  Not sure how that could have happened.  I will upload it again.  Sorry.
<aeoril> darkxst sorry about that - you can check it again now.  I have re-uploaded it:  https://bugs.launchpad.net/ubuntu/+source/gdm/+bug/1315442
<ubottu> Launchpad bug 1315442 in gdm (Ubuntu Trusty) "Extra "fi" in /etc/init.d/gdm" [Undecided,Confirmed]
<aeoril> darkxst I am just trying to up my karma, or at least my subconscious is ...
<psusi> so with the release of vivid getting so close now I am growing concerned that this critical bug that prevents installation on uefi systems is going to go unfixed... is anyone looking at https://bugs.launchpad.net/bugs/1418706
<ubottu> Launchpad bug 1418706 in ubiquity (Ubuntu) "Vivid: UEFI: blank drive incorrectly detected as existing BIOS-mode install" [Critical,Triaged]
<psusi> it looks like there is a severe underlying breakage in ubiquity and how it is running the partman scripts int he wrong order or in parallel
<infinity> hallyn: Ahh, the upstream bug is an enlightening read.
<infinity> hallyn: And also clear that it's not a regression from trusty, at least, so that's nice.
<psusi> it will be *really* bad if vivid is released with this bug unfixed
<infinity> cyphermox: Can you put investigating LP: #1418706 on your post-holiday TODO?
<ubottu> Launchpad bug 1418706 in ubiquity (Ubuntu) "Vivid: UEFI: blank drive incorrectly detected as existing BIOS-mode install" [Critical,Triaged] https://launchpad.net/bugs/1418706
<infinity> hallyn: I'm not sure I'd go so far as calling that a glibc bug, so much as a missing feature.  The assertion seems entirely sane in a world where our parents' PID doesn't magically go away. :P
<infinity> hallyn: But yeah.  Icky.  Would be nice to see patches from the container crowd with an implementation they feel would be both historically correct and also deal with the brave new world.
<darkxst> aeoril, can you add the SRU paperwork to the bug also (https://wiki.ubuntu.com/StableReleaseUpdates#SRU_Bug_Template)
<aeoril> darkxst ok, will try
<aeoril> darkxst do you mean just adding a comment with the SRU Bug Template filled out?
<darkxst> aeoril, edit the bug description
<aeoril> darkxst ok, will do my best
<hallyn> infinity: eh, what you say is probably more fair than what i say, but i guess i'd be more charitable if the end-result wasn't a mysterious hung task hung in assert()
<hallyn> it wasn't a bug befor epid namesapces, but it's been a bug for a long time now
<infinity> hallyn: I'm entirely on board with the behaviour being suboptimal. :P
<hallyn> i'd still like to know whether anyone is working on the pthread mutex fixup to allow us to fix this
<infinity> hallyn: The bug log doesn't imply a great deal of care-factor, but I can poke around and see if anyone's working on it internally.
<infinity> hallyn: I wouldn't object to the "skip the assert if PPID == 0" bandaid, I don't think, but if it's already been worked around in software hitting the bug, I'd rather take some time and think about implications of a "correct" fix, whatever correct looks like.
<hallyn> infinity: the ppid isn't registered as 0 though, unfortunately
<aeoril> darkxst do you mind if I create the SRU paperwork and bpaste it for you to look at first then paste it into the bug description once it looks ok?  Also, when did you need this?  I have been working on bugs since 2:30 am my time and it is now 5:00 pm
<aeoril> (getting played out)
<darkxst> aeoril, just write it straight into the bug, you can always change it later if really needed
<darkxst> I'm going to upload it soon, so should be done as soon as you can
<infinity> hallyn: Oh, there was an imlpication of such in the bug.  Definitely needs a bit more unwinding to understand, I guess.
<aeoril> darkxst I have to cook right now for dinner, but I can do it after that - maybe a couple of hours max?
<Unit193> And in case you missed it, lot of backlog in #debian-devel about ddebs.
<darkxst> aeoril, sure, even tomorrow would be fine
<aeoril> darkxst oh, good - I'll plan on tomorrow afternoon then, if that is ok - maybe later this evening if I get a nap in
<darkxst> aeoril, ok
<infinity> darkxst: Did you sponsor that gdm upload I just rejected? :P
<infinity> darkxst: You had some patch cruft in debian/-p2 which was obviously an oops.
<darkxst> infinity, yes, hmm
<darkxst> how did that get there!
<darkxst> fixed now
<aeoril> darkxst infinity was that bug 1315442 ?
<ubottu> bug 1315442 in gdm (Ubuntu Trusty) "Extra "fi" in /etc/init.d/gdm" [Undecided,Confirmed] https://launchpad.net/bugs/1315442
<darkxst> yes
<aeoril> I guess I am not the only one who "oppsed" on it, although I did it several times ...
<aeoril> "oopsed" ...
<darkxst> seems I oopsed not you
<aeoril> darkxst yes, I understand, but I had several "oopses" of my own on that silly thing
<aeoril> My Gosh!  Release is the 23rd of this month for vivid?
<ClevrPwn> anyone know why UCK is having problems with GFXBOOT? (this seemed like the best room from the list to ask.
#ubuntu-devel 2015-04-04
<doko> apw, ogasawara: would be nice to announce such changes ... https://launchpadlibrarian.net/201982759/buildlog_ubuntu-vivid-amd64.armhf-cross-toolchain-base_1.107_BUILDING.txt.gz
<infinity> doko_: They didn't change anything, I slimmed down the chroots a bit and there's a missing build-dep, apparently.
<infinity> doko_: Looks like the kernel correctly build-deps on cpio, FWIW, it's just missing for *-toolchain-base, because our chroots used to have initramfs-tools in them (because of upstart), and do no longer.
<doko_> infinity, ahh, ok. can you fix these? (and maybe apply multilib-stage1.diff before)
<infinity> doko_: If it turns out to be a more widespread problem in the rebuild, I'll re-add cpio to vivid's chroots (and pull it out again in vivid+1)... I already readded the non-Essential procps because too many things seem to expect it.
<infinity> doko_: And yeah, I can play with *-toolchain-base.  I should have done so right after I got glibc 2.21 in anyway.
<aeoril> darkxst are you not going to release the fix for bug 1315442 for vivid?
<ubottu> bug 1315442 in Ubuntu GNOME "Extra "fi" in /etc/init.d/gdm" [Undecided,New] https://launchpad.net/bugs/1315442
<sarnold> aeoril: looks like 0ubuntu3 was released 57 minutes ago: https://launchpad.net/ubuntu/+source/gdm
<aeoril> sarnold oh, foolish me - I just saw that!  Thanks!
<aeoril> sarnold and now the paperwork ... :)
<aeoril> sarnold I saw this - "I have uploaded to trusty and utopic, please add the SRU paperwork when you can." and only now realize those two were in there and not vivid because they are backports, I guess
<aeoril> darkxst ^
<sarnold> aeoril: right, though as vivid gets closer to release, at some point I think they'll start requiring the full sru dance for uploads for it, too
<sarnold> ..maybe it's just an okay from the release team. I don't normally work on the devel branch, much there is new to me :)
<aeoril> sarnold lots of fun, though - I am digging this!  It feels good to be starting to get used to some of the tools - feeling more oriented
<sarnold> aeoril: woot \o/
<aeoril> sarnold \o/ :)
<darkxst> aeoril, its already released in vivid
<darkxst> see the bots comment, above mine
<aeoril> darkxst yes, I saw that - I was confused by that one email, but got it now.  Thanks!
<darkxst> SRU's only start after the final release
<sarnold> oh, thanks
<aeoril> darkxst also, now I know when I reply to the generated e-mails, they make comments, so I will watch that as well.  I am a little shell-shocked tonight from a long day - going on 18 hours now today.  Time for some relaxation - the SRU paperwork looks like tomorrow afternoon, but it will get done.
<aeoril> darkxst I did the SRU "paperwork", but in doing so am a little worried whether I always called the script with "sudo" in my testing.  I think so, but am a little nervous about that - I did not put "sudo" in the test descriptions as I wrote them when I uploaded the debdiff patches and made the comments, so I am a little worried about that
<aeoril> darkxst I think not putting "sudo" was an oversight, but just not absolutely sure
<aeoril> (in the comments when I uploaded the debdiff patches)
<aeoril> darkxst anyway, please let me know if the sru info seems good to you
<darkxst> aeoril, wouldnt worry about, anyone reviewing the sru, is likely going to know when or not to use sudo
<aeoril> darkxst ok, thanks.  I'll be interested what you think of how I wrote the SRU stuff - I hope I did it right
<darkxst> its good, way more verbose than needed, but thats fine
<aeoril> darkxst unfortunately, throughout my career I have fought the tendency to be highly verbose and almost always lost :(
<aeoril> darkxst anyway, I will keep that in mind next time and try to keep it shorter ...
<aeoril> darkxst basically, when writing, words flow out of me like a sieve lol
<darkxst> aeoril, I noticed!
<aeoril> darkxst lol I have always been (in)famous for that (inequity)quality ;)
<aeoril> darkxst I'll try better to put a cap on it
<aeoril> darkxst when I am not a computer guy, I do writing and editing on the side, so it can actually be good that I a lot easily for those pursuits
<aeoril> write a lot*
<darkxst> I don't suppose it matters too much, just makes it take longer for your to write it!
<aeoril> darkxst the problem is it also makes it longer for the reader to slog through it!
<aeoril> (or, just give up and not read it at all)
<darkxst> yes, I barely read it, just skimmed over and picked out the relevant bits
<darkxst> most of my SRU's are around 20lines ;)
<aeoril> darkxst yes, that is what most people do with my writing lol - I am quite aware of it after almost 30 years of experience with myself
<aeoril> darkxst I can keep a cap on it if I remember to watch out for it, though - just my natural self if I do not watch out is very verbose
<darkxst> the human minds seems pretty good at sifting out the important bits from the faff!
<aeoril> faff?
<aeoril> "wheat from the chaff"
<darkxst> all the extra details that arent really required
<darkxst> aeoril, 3 lines ;) http://pastebin.com/PJ63JbKv
<darkxst> but the extra details don't hurt
<aeoril> darkxst thats too funny! :)  But, there are some gotchas that need to be considered in the testing that I cover that you don't
<aeoril> darkxst I can still learn! :)
<darkxst> I don't actually get why there would even be a difference between running /etc/init.d/gdm and ./gdm from that path (there shouldnt!)
<darkxst> though if its failing silently, then the stderr is probably redirected to some log in that case
<aeoril> darkxst I actually did some extensive probing into that and found out some of the reasons, but that was over a month ago.  Nevertheless, it is real and happens.  It should not, but does.  Parsing command line stuff badly, IIRC or something like that
<aeoril> (pulling commands out of the command line, but not doing it robustly, etc)
<darkxst> dash can be a weird beast sometimes, but this doesnt like one of them
<aeoril> "doesn't like one of them"???
<darkxst> ^look like]
<aeoril> poor parsing technique in the actual sysv scripts, I think, but I do not think I ever completely nailed down exactly what was going on
<aeoril> techniques*
<darkxst> aeoril, there a lots of corner cases, when it fails strangely on bash syntax
<aeoril> darkxst it was quite a tree of scripts when I was delving into it!
<darkxst> ("it" being dash)
<aeoril> darkxst I meant "it" being the sysv scripts
<aeoril> darkxst there was some fairly elaborate scripting going on in those scripts beneath gdm
<infinity> darkxst: 20 lines?  You ovrachiever.  Most of my SRU boilerplate looks like "[Justification] See original report [Test Case] Try to run it.  Does it work?  You friggin' win. [Regression Potential] Might set your house on fire."
<darkxst> aeoril, I don't know where that script came from, but if it has bash-isms, its likely to have problems
<darkxst> infinity, see my 3 line version about 20 lines up in the scrollback!
<infinity> darkxst: Ahh, indeed.  That's more like it. :)
<darkxst> I probably should have said 20 lines would be the max length ;)
<infinity> darkxst: Well, I've had some elaborate ones where the test case is really brutal or the regression potential is actually worth a discussion, but most SRUs are really quite simple.
<infinity> (THankfully)
<darkxst> infinity, agreed, but the point was aeoril's is about 200 lines longs ;)
<infinity> darkxst: I accepted his SRUs before he updated the bugs.  I'm now afraid to go read. ;)
<infinity> Oh wow.
<infinity> aeoril: Have you considered a career as a tech writer?
<aeoril> infinity are you being facetious?  My effort seems to have fallen flat ...
<infinity> aeoril: A little bit, perhaps. :)
<infinity> aeoril: But that level of verbosity could come in handy, say, for help with the release notes in a couple of weeks...
<infinity> *cough*
<aeoril> I have done a lot of tech writing during my career - probably hundreds of pages, if not thousands overall, as part of my duties as a software engineer during all phases of development, including requirements, test cases, bug reports - just about every part of where writing needs to be done.  Most of my time has been spent coding and debugging, but tech writing was still a big part of
<aeoril> things
<aeoril> infinity hook me up!  I think I might be a good fit for that, and like writing as well as editing other peoples writing.  I write and edit on the side, sometimes for money anyway.  That may be a very good fit for me actually at Ubuntu
<aeoril> infinity I worked in enterprise, government and military, so tech writing was an oft used skill for any developer in those environments
<darkxst> aeoril, ubuntu GNOME release notes are generally sparse
<darkxst> no one has started on the final ones yet
<infinity> darkxst: That's okay, he can help write both yours and mine, I don't mind.  We'll share him.
<darkxst> infinity, perfect!
<aeoril> lol I feel like the kid claimed by two women King Solomon said to cut in half ...
<darkxst> aeoril, don't take it so seriously then ;)
<infinity> aeoril: The sawing in half comes after the release.
<aeoril> darkxst I was joking ...
<darkxst> infinity, is half a person going to be eligible for ubuntu membership in the future though, that seems a little problematic!
<aeoril> infinity if you are serious about me doing some technical writing, where would I get started with that?
<aeoril> infinity I am actually very interested in that
<aeoril> (I really enjoy writing)
<infinity> aeoril: Well, we have a doc team that probably has all sorts of docs on how to contribute.  But none of them seem to contribute to my release notes, so those end up written by frustrated release managers 20 minutes before we ship. :P
<infinity> And, while I'm clearly no slouch with this whole English business, writing release notes is about my least favourite thing in the world.
<darkxst> infinity, we don't even have that, the doc team refuses to recognise flavours
<aeoril> infinity you are talking specifically not about Ubuntu but more gnome?
<infinity> darkxst: I feel your pain, and a beer is in the mail.
<darkxst> aeoril, infinity is Ubuntu, I am GNOME
<infinity> aeoril: I'm talking about all the Ubuntu flavours, though my bias is to the "main" release notes that cover all the core bugs and new features in Ubuntu in general.
<aeoril> infinity I might give it a shot.  Definitely a different direction than where I was going, but I might like it
<infinity> aeoril: Anyhow, I'll nudge you about it closer to release week.  I'm sure we'd all appreciate some help from someone who actually enjoys writing and editing, rather than what most of the flavour release managers do, which is copy and paste some bug reports, scream "THAT'S TOTALLY GOOD ENOUGH, LA LA LA" and run off to the pub.
<infinity> Which is a natural response after the week of pain we go through to get there.
<aeoril> infinity whould this be steering me into the arena of a "release manager" then?
<infinity> aeoril: Nah, that's an entirely different role.
<aeoril> good
<darkxst> aeoril, community members can't really do that
<infinity> darkxst: That's not true, lots of the release team is community (well, all of them, depending on your world view).
<aeoril> anything with the word "manager" in it strikes me with fear and loathing
<infinity> aeoril: Depends on the flavour, but most release management is really just technical steering.  It's a position of trust (and holds many keys to the kingdom), though, so comes well after upload permissions and earning trust from your peers, etc.
<darkxst> infinity, I meant the actual releases, not the release team
<darkxst> that requires access to secret canonical servers no ?
<infinity> darkxst: Well, yeah, the final button mashing is something we still have to do internally, because of how the infrastructure is laid out, but we've got that down to mostly a no-brainer.
<aeoril> infinity sounds like an honorable thing then
<infinity> darkxst: Really, that bit takes me only a few minutes per flavour, so I don't really think about it anymore.  It's all the other crap we (as a team) do leading up to it that's work. :)
<aeoril> infinity thanks for recognizing some value in what I did and offering me something I may be really interested in.  A great manager can match the right talent with the right job
<infinity> darkxst: Say, why are you not core-dev?
<darkxst> infinity, I probably dont have enough time for that! still be meaning to put my -desktop team application in
<infinity> darkxst: Well, core-dev doesn't imply uplading every package in main tomorrow, just the ability to do so without being sponsored. :P
<infinity> darkxst: Which, I'd guess you've got enough history for at this point.
<infinity> darkxst: (And my motivation for asking was because I was pondering if you'd make a good addition to ~ubuntu-release, but because of the permissions that team gives, I won't invite non-core-devs, since it allows you to bypass upload rights)
<darkxst> infinity, most of my work has been within ubuntu-desktop sure there would be some core-dev packages in there though
<darkxst> I don't really check which are the difference, since I don't have upload rights for either
<darkxst> but my MOTU application was knocked back with your too GNOME!
<infinity> darkxst: Hah.  Well, that's curious.  Maybe I should have stood for a DMB position this term.
<infinity> darkxst: I mean, it's fair that if all of someone's contributions can be covered by a package set, then that's the safe set of permissions to give them.  But people maintaining major DEs like xfce and gnome tend to need to mangle packages that aren't theirs quite often, IME.
<infinity> Since we all share a bunch of stuff in core.
<darkxst> infinity, none of that is in the flavour packagesets though
<darkxst> ours is dismall, http://people.canonical.com/~ubuntu-archive/packagesets/vivid/ubuntugnome
<infinity> darkxst: Exactly, nothing in core can be in flavour packagesets, so once a flavoury person finds they've had to touch those packages often enough and have proven competence in doing so, I'm all for them being a bit less flavourful in their permissions.
<darkxst> infinity, and nothing in -desktop either, though pretty sure I will get that now, if I can actually make a meeting
<darkxst> its like 5am or so here
<infinity> darkxst: Just learn to live timezone-free, like I do.
<infinity> (don't do what I do, it's apparently really bad for you)
<darkxst> infinity, I need my sleep, had chronic fatigue syndrome, days don't go so well If i don't sleep at night!
<infinity> darkxst: I'm pretty sure I need sleep too, I just rarely get any.
<aeoril> infinity what is your main role in the Ubuntu community?
<darkxst> infinity, I get all sick and stuff If I do that ;(
<infinity> aeoril: Jack of all trades, master of two or three.
<aeoril> infinity yes, I saw you are a member of a heck of a lot of things on your launchpad page ... do you work for canonical?
<infinity> aeoril: I do, yes.
<aeoril> infinity do they pay you to work there?
<infinity> They keep me fed, yes. :)
<Unit193> Ah so it was a choice between food and sleep.  Good choice, you made.
<infinity> Heh.
<aeoril> darkxst I also need my sleep now - not so much when I was younger
<darkxst> aeoril, are you saying I am young? that is unlikely
<aeoril> Unit193 remember when you tried to get me interested in vala?
<Unit193> Sounds like me to mention it at least, yep.
<aeoril> Unit193 I ran into some of it in a bug I was trying to fix (gnome stuff)
<aeoril> It reminded me of you and the ubuntu beginners team
<Unit193> Heh.
<aeoril> darkxst no, nothing meant about you - just me being older now
<darkxst> aeoril, quite a few gnome apps are
<darkxst> written in vala
<darkxst> none of the core though, thats all pretty much C
<darkxst> with a touch of JS, for the shell
<aeoril> darkxst yes, I remember you mentioning I might be a good fit for parts of Gnome because of my Javascript background ...
<aeoril> I have C and Javascript, so might be a good match (I could learn Vala)
<darkxst> its not really standard JS, somewhat customised
<darkxst> its the firefox spidermonkey engine with a bunch of custom hooks
<aeoril> darkxst I was just about to ask the question to your answer :)
<darkxst> aeoril, there you go, upstream want me to maintain gjs
<aeoril> darkxst hmmm ... I had aspirations of Kernel/Driver, then tech writer, now gjs - oh me oh my, so many choices!  What to do! :D
<darkxst> gjs is 100% C
<darkxst> but it enable the custom JS bindings, most of the code if enababling gobject-instrospection
<darkxst> s/if/is/
<darkxst> aeoril, just do what you enjoy!
<aeoril> darkxst I am very fortunate - I enjoy just about everything technical!
<darkxst> (I've been pulled from that a little, given the lack of manpower in Ubuntu GNOME ;( )
<aeoril> darkxst infinity I'm off to slumberland.  Thanks again for all you help yesterday and today.  Good night.
<aeoril> your*
<dupondje> Just installed the new Ubuntu, but something should be changed in the installer imo.
<dupondje> It asks crypt password BEFORE it asks keyboard layout
<dupondje> So you need to enter a password before your keyboard is set correctly (ok you can change it manually in the menu bar .. but not that user-friendly)
<Noskcaj> dupondje, Since not everyone is around at the moment, could you please file a bug asking for that to be changed?
<psusi> could someone please merge this fix for a critical bug before the 15.04 release?  It's been waiting for quite some time: https://code.launchpad.net/~psusi/ubuntu/vivid/grub-installer/fix-efi-multi-disk-installs/+merge/247772
<tjaalton> hm no psusi.. uploaded grub-installer with that fix
<tjaalton> psusi: i've uploaded the fix
<psusi> tjaalton, thanks
<psusi> now if someone more familliar with ubiquity could take a look at this release critical blocker of a bug, that would be great: https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1418706
<ubottu> Launchpad bug 1418706 in ubiquity (Ubuntu) "Vivid: UEFI: blank drive incorrectly detected as existing BIOS-mode install" [Critical,Triaged]
<psusi> I have a strong suspicion that the underlying breakage is more far reaching than the simple use case in which it was originally detected, which alone is very serious
#ubuntu-devel 2015-04-05
<cyphermox> infinity: ack
<ari-tczew> The page "Debian RC bug fixes missing from Ubuntu" is empty. Would be nice, but I guess it's broken. Can any admin confirm that? http://qa.ubuntuwire.com/bugs/rcbugs/
<aeoril> anybody got any good tips for bug browsing?  I am not having much luck finding good bugs to fix for myself on launchpad
<darkxst> aeoril, you could try the papercut bugs
<aeoril> darkxst yes, I have been looking at those - is that the "100 papercuts" thing?
<darkxst> yes
<aeoril> I have been looking at this as a possibility:  https://bugs.launchpad.net/hundredpapercuts/+bug/1241972
<ubottu> Launchpad bug 1241972 in Unity 7.2 "Drag and drop from Dash to Desktop doesn't work" [High,Triaged]
<aeoril> darkxst ^
<aeoril> (got that off papercuts)
<aeoril> darkxst but, from how Unity works in vivid, that seems more like a "feature change" than a bug - but that is ok
<darkxst> aeoril, no idea about unity, but sounds like nautilus is throwing an error, because of a broken uri or so
<ari-tczew> aeoril: you can try to triage CVEs. http://people.canonical.com/~ubuntu-security/cve/universe.html
<aeoril> ok, thanks guys - my son just arrived for easter, but will look at those
#ubuntu-devel 2016-04-04
<mwhudson> hm
<mwhudson> why hasn't golang-1.6 migrated from -proposed to -updates in trusty yet?
<mwhudson> i thought it would happen after a week
<mwhudson> (and the bug was verification-done)
<roaksoax> mwhudson: http://people.canonical.com/~ubuntu-archive/pending-sru.html -> seems green, but its probably because there's no golang-1.6 in trusty main
<roaksoax> mwhudson: so might need manual push
<roaksoax> w
<mwhudson> roaksoax: ah ok
<infinity> It's always manual.
<infinity> It needs a human to say "yep, let's do that".
<infinity> And we don't tend to release on weekends.
<infinity> Though, for a NEW package, it can't hurt.
<infinity> mwhudson: Released.
<mwhudson> infinity: what is this weekend you speak of
<mwhudson> infinity: thanks
<infinity> mwhudson: The weekend is the time when a large number of our developers shockingly aren't glued to their keyboards and would prefer not to deal with the flood of bug reports a bad SRU can cause.
<infinity> mwhudson: Weird, I know.  Since some of us have brain uplinks.
<mwhudson> infinity: it's already monday afternoon though!
<infinity> (Well, it's both about developer response time, and about not breaking corporate users with unattended-upgrades and a similar 5-day schedule)
<infinity> mwhudson: Not in the correct part of the world!
<lifeless> infinity: 'correct'!
<infinity> lifeless: You heard me.
<lifeless> I see stockholm has its claws into you
<infinity> I lived in the future for five years.  It didn't agree with me.
<infinity> Granted, not your little bit.
<lifeless> :)
<mwhudson> woo fun running the go runtime tests can kill the kernel on s390x
<mwhudson> i guess i should report that to someone...
<lifeless> mwhudson: !
<mwhudson> actually an ibm person mentioned this too
<mwhudson> so /hopefully/ i'm just running an out of date kernel
<cpaelzer> good morning
<pitti> Good morning
<pitti> jdstrand: thanks, I'll look into the udev crash now
<pitti> dannf, infinity: adt-run always sets LANG=C.UTF-8 by default; something changed there since the new glibc, can you reproduce this with that command?
<pitti> dannf: lxd currently seems broken on my xenial, I'll look into that now and file a bug
<dholbach> good morning
<mwhudson> yay https://launchpad.net/ubuntu/+source/docker.io/1.10.3-0ubuntu4
<mardy> Mirv: hi! ping ping :-)
<Mirv> mardy: pong pong
<mardy> Mirv: red alert :-) Do you think we can get this fixed by 16.04? bug 1564767
<ubottu> bug 1564767 in webapps-sprint "Wrong size of embedded window" [Critical,In progress] https://launchpad.net/bugs/1564767
<mardy> Mirv: I've attached a patch, generated with quilt on top of the existing debian/patches
<Mirv> mardy: thanks, sure it should be possible. can you submit it to https://launchpadlibrarian.net/251636878/xcb_fix_parent_screen_of_embedded_windows.patch ASAP? we shouldn't carry a patch if it's not approved by upstream.
<mardy> Mirv: sorry, to where?
<Mirv> mardy: hah, https://codereview.qt-project.org/ I was meaning to paste
<Mirv> mardy: maybe look through http://code.qt.io/cgit/qt/qtbase.git/log/src/plugins/platforms/xcb/qxcbwindow.cpp too if there's something to backport instead of your patch
<mardy> Mirv: but are they still interested in Qt 5.5?
<Mirv> mardy: no, they'd be interested in 5.6 though if it's affected by the same bug
<Mirv> mardy: and most likely 5.6 branch is the best place to offer a fix too in, they merge from there to 5.7 and dev.
<mardy> Mirv: I'll now test 5.6, but looking at their code, I believe they've already fixed it
<mardy> Mirv: the problem is, it's not just one patch to backport, but many
<Mirv> mardy: ok, to me it'd look like the line of code in question is still unchanged, just a variable name changed. but maybe it was fixed elsewhere?
<Mirv> mardy: we actually have a lot of XCB fixes already in, in order to try to fix multi-monitor issues that plagued 5.5 still (and maybe even 5.6 still too).
<Mirv> mardy: but at this point I'd tend to agree that if it's yet another multiple patches, it would be better to take your two-liner patch instead
<mardy> Mirv: yes, that function is still there in Qt 5.6, but handleConfigureNotifyEvent() doesn't call that method anymore :-)
<mardy> Mirv: but let's see, I'm installing 5.6 and I'll let you know
<Mirv> ok!
<GunnarHj> pitti: Hi Martin, Time to look at the FFe request at bug #1556457 (fontconfig 2.11.1 -> 2.11.94)?
<ubottu> bug 1556457 in fontconfig (Ubuntu) "[FFe] Demilight (OS/2 weight=350) confuses fontconfig" [High,New] https://launchpad.net/bugs/1556457
<mardy> Mirv: yes, 5.6 works! :-)
<mardy> Mirv: but given how deep are the chanegs in teh XCB plugin between 5.5 and 5.6, I think it's quite risky to try a backport (also because we already have quite a few debian/patches touching XCB)
<Mirv> mardy: ok! :) then you don't need to submit anything to upstream since indeed they've forgotten about 5.5 by now (because 5.6 is LTS). so it may be your patch is simply the best way.
<Mirv> mardy: I agree, unless some of the already backported patches form a baseline on top of which one more could be cherry-picked, but I somehow doubt that too
<Mirv> mardy: it just happened I got my previous qtbase xenial upload done so I'll start preparing the next one but not with what I had on my mind earlier (not so important) but your patch instead
<mardy> Mirv: excellent, thanks a lot!
<rbasak> tseliot: thank you for fixing bug 1565436 so quickly. I wasn't expecting that!
<ubottu> bug 1565436 in ubuntu-drivers-common (Ubuntu Wily) "gpu-manager hangs on boot when syslog is bloated" [High,Triaged] https://launchpad.net/bugs/1565436
<tseliot> rbasak: I think I did a while ago. I need to find some time to backport the fix
<rbasak> Ah, OK
<rbasak> infinity: opinion on https://bugs.launchpad.net/ubuntu/+source/myodbc/+bug/1564856/comments/1 please?
<ubottu> Launchpad bug 1564856 in myodbc (Ubuntu) "myodbc uses internal libmysqlclient functions no longer exported by 5.7" [Undecided,New]
<rbasak> Presumably repackaging for cmake shouldn't be insurmountable and we should just do it?
<Skuggen> rbasak: But the main issue hasn't been fixed upstream
<rbasak> Skuggen: how hard would it be to fix it and patch it in distro and then send that upstream?
<rbasak> (in that I'm asking the question - I don't mean that rhetorically)
<Skuggen> The developers are working on a fix, which we would then apply to the newest released version, but I don't know the code, so I don't really know how big a task this is
<pitti> GunnarHj: followed up; I don't think I have enough information/experience with fontconfig to answer this right away, but I asked some questions there
<tsimonq2> Greetings, regarding bug 1530323, I don't know what to do next, and it's affecting Lubuntu, could somebody please take a look at this bug report and my comments and judge whether it's fixed yet or not? I can't really tell...
<ubottu> bug 1530323 in network-manager-applet (Ubuntu) "The input box for editing a Wired connection static IP address doesn't appear correctly" [High,Confirmed] https://launchpad.net/bugs/1530323
<GunnarHj> pitti: Added an answer to bug #1556457. If you don't have enough fontconfig experience, who has ;)
<ubottu> bug 1556457 in fontconfig (Ubuntu) "[FFe] Demilight (OS/2 weight=350) confuses fontconfig" [High,New] https://launchpad.net/bugs/1556457
<GunnarHj> Hi Laney, any chance you have some good advice re. the bug #1556457 FFe?
<ubottu> bug 1556457 in fontconfig (Ubuntu) "[FFe] Demilight (OS/2 weight=350) confuses fontconfig" [High,New] https://launchpad.net/bugs/1556457
<Bluefoxicy> bluez-gstreamer wine1.6 gnome-media need recompile against gstreamer 1.0; they depend on gstreamer 0.10 in Xenial o.o
<Bluefoxicy> not sure if that's fixable at this stage though
<Bluefoxicy> (also bah the Wine team, they didn't get Wine 1.8 in Xenial even though it's been out since before Wily)
<_hc> we (Android Tools Debian team) finally got all of our current packages into Debian/testing.  xenial is mostly in sync, but there are two packages with packaging fixes that have not been fixed: android-platfrom-system-core and android-platform-tools-base
<_hc> oops, have not been synced
<_hc> should I do requestsync?
<ginggs> _hc: yes please
<_hc> ok will do
<_hc> seamlik: do you want to try the requestsync, or shall I?
<seamlik> I'm not familiar with that ...
<_hc> ok, I can do it, its basically a webform in launchpad
<teward> _hc: i'd be happy to run 'requestsync' for you if you need
<teward> then give you the bug # to make your comments ;)
<teward> this close to final freeze, though, how critical are the package updates :P
<seamlik> Hmm I would wait for some time
<teward> s/final freeze/final release/
<_hc> I think they are essential, and these are new packages that nothing else depends on, so they are low risk changes
<_hc> the new packages do depend on each other
<_hc> for example, one change is a typoed package name in depends
<seamlik> Do we have any deadlines?
<_hc> yeah, final release is very soon
<teward> final freeze is next week I think
 * teward pulls the Xenial schedule up
<seamlik> April 14?
<teward> https://wiki.ubuntu.com/XenialXerus/ReleaseSchedule
<teward> Final Freeze on April 14
<teward> and we're way past FeatureFreeze
<_hc> these are all bug fixes in the packaging
<teward> so you'll need to follow https://wiki.ubuntu.com/FreezeExceptionProcess to get it reviewable for FFe
<seamlik> OK, fire at will ;)
<teward> seamlik: android-platfrom-system-core and android-platform-tools-base ?
<teward> seamlik: and from Debian Testing?
<_hc> teward: the first package is https://packages.debian.org/source/sid/android-platform-system-core
<teward> and from Testing or Unstable?
<_hc> hold off on -tools-base
<teward> (where do you want the sync req. to come from)
<_hc> unstable and testing should be the same, it just happened, but unstable to be safe
<teward> hmm
<teward> !info android-platform-system-core xenial
<ubottu> Package android-platform-system-core does not exist in xenial
<teward> hate the bot
<seamlik> Oh, android-platform-build
<teward> source packages are better ;)
<teward> okay, so...
<ginggs> teward, _hc: android-platform-system-core package already sync'd
<teward> yep
<teward> i was going to say that
<teward> E:Versions match
<teward> :P
<_hc> ah, ok, I guess I should look at the ubuntu tools rather than the debian tools here :)
<teward> ginggs: though, rmadison shows a delta between sid and xenial/universe
<teward> are we absolutely certain they're in sync?
<ginggs> sync'd 5 minutes ago
<seamlik> Thank you!
<teward> ah, nice, so rmadison isn't updated :)
 * teward goes back to figuring out why his boxes are deady
<teward> dead*
<ginggs> sponsored by LocutusOfBorg for Mapreri
<teward> even better :)
<seamlik> Mapreri helped a lot during the migration
<ginggs> _hc: what was the other one?
<_hc> android-platform-build
<teward> i get the same notice about version match for that too
<teward> ginggs: ^
<_hc> the android-platform-tools-base update requires a new package to xenial, so that's probably not feasible
<_hc> liblombok-ast-java
<teward> my squid proxy on my net is dead, so... I can't check easily
<teward> as of a couple minutes ago 'cause i broke it :/
<ginggs> android-platform-build was also sync'd already
<_hc> 8 minutes ago, it looks like :)
<ginggs> you can see https://launchpad.net/ubuntu/+source/android-platform-build and https://launchpad.net/ubuntu/+source/android-platform-system-core
<_hc> I think we're good then unless seamlik has something to add
<ogra_> did anyone contact the phone team about these packages (since they maintain their own patched versions of i.e. adb, adbd and fastboot)
<_hc> I think we've had some contact.  these packages don't touch the original android-tools source package, which is what Ubuntu uses for adb, adbd, and fastboot
<ogra_> ok
<_hc> Ubuntu already has its own android-tools anyway, for a while now
<ogra_> we tried to sync it at one point
<seamlik> well, that's all we need for now :)
<_hc> it would be great to move adb and fastboot out of the android-tools package.  We have more up-to-date adb and fastboot building in the Android Tools Team packages, but they only build on amd64 and i386.  So someone would need to port things to all the other archs to fully replace the android-tools source package
<ogra_> you would have to pull in the patches to the udev rules
<ogra_> (that are added to support ubuntu devices)
<ogra_> (beyond that fastboot and adb binaries shoudl be fine to use vanilla ... adbd not though  ... taklk to the guys in #ubuntu-touch)
<Mirv> mardy: bug #1564767 fix is now built at https://requests.ci-train.ubuntu.com/#/ticket/1215 - you can mark it as Lander Signoff Approved when ready, although no hurry since qtbase is and will be blocked in xenial-proposed because of mysql-5.7 transition it seems
<ubottu> bug 1564767 in qtbase-opensource-src (Ubuntu) "Wrong size of embedded window" [Critical,In progress] https://launchpad.net/bugs/1564767
<rbasak> What happened to bzr-fastimport? Looks like it disappeared since Wily.
<rbasak> "(From Debian) RoQA; orphaned, unmaintained upstream, rc-buggy; Debian bug #742416"
<ubottu> Debian bug 742416 in ftp.debian.org "RM: bzr-fastimport -- ROM; orphaned, unmaintained upstream and rc-buggy" [Normal,Open] http://bugs.debian.org/742416
<barry> doko: configglue (even upstream bzr) is still not python3.5 compatible, thus the ftbfs
<barry> doko: LP: #1504288
<ubottu> Launchpad bug 1504288 in configglue "Test suite failure with Python 3.4 & 3.5" [Undecided,In progress] https://launchpad.net/bugs/1504288
<barry> doko: i will spend a *little* time looking at an upstream
<rbasak> xnox: around? Please could you comment on https://bugs.launchpad.net/ubuntu/+source/juju-mongodb/+bug/1557830/comments/10 please?
<ubottu> Launchpad bug 1557830 in juju-mongodb (Ubuntu) "[needs-packaging] juju-mongodb2.6 in xenial, wily, and trusty" [Undecided,New]
<rbasak> xnox: I'm happy to do whatever you and the release team prefer.
<xnox> rbasak, and why do you ask me? I'm not a release team =)
<rbasak> xnox: because you have reason to care :)
<xnox> also what juju upstream supports should not matter what ubuntu archive compiles.
<rbasak> Yeah
<xnox> rbasak, e.g. it should be totally valid to have a client on 32bit controlling 64bit deployments....
<rbasak> I think I should change it to "any".
<rbasak> If it FTBFS on some archs, then the release team can decide whether to let that in or not.
<rbasak> It doesn't seem right to just turn it off on an arch, since I understand that makes life hard for porters who want a particular arch to work well across the archive.
<doko> stokachu, looking at bignum: please don't use bash as the shebang when plain sh is good enough
<stokachu> doko: bignum?
<doko> stokachu, you uploaded that to NEW. or can it be removed?
<stokachu> doko: you talking bout bigdata?
<doko> ahh
<doko> yes
<stokachu> doko: i can fix the bash string if you want
<doko> stokachu, just for your next upload
<stokachu> doko: thanks, fixed here https://github.com/Ubuntu-Solutions-Engineering/bigdata-deb/commit/fce9d383a8011e9b31cca01022128dc412afca87 so it'll make it into next upload
<doko> stokachu, debian/copyright is missing 2016, in conjure as well
<doko> stokachu, conjure: why all the pre-built egg files in conjure/dist?
<stokachu> doko: hmm
<stokachu> doko: i need to remove those, not sure why they are there
<stokachu> doko: i fixed it and the copyright, anything else? otherwise i can upload a new package
<doko> stokachu, ok, I'll reject that one. also ubuntui/*.py doesn't have any copyright notices. there might be more of these
<stokachu> ok ill add those files to copyright
<doko> stokachu, the question is, if these files should contain the copyright, as the other files have it
<stokachu> doko: yea some are LGPL and AGPL
<doko> stokachu, well, then the debian/copyright is wrong. it only mentions the MIT license
<stokachu> doko: yep fixing that now
<doko> stgraber, golang-gopkg-inconshreveable-log15.v2-2.11+git20150921.0.b105bd3 debian/copyright is missing the copyright for the term subdir
<stgraber> doko: thanks, will fix
<doko> stokachu, the update conjure: is it intended that the toplevel files are still covered by the MIT license?
<stokachu> doko: yea
<stokachu> aside from those directories i defined
<doko> tjaalton, updated https://bugs.launchpad.net/ubuntu/+source/libset-scalar-perl/+bug/1558820
<ubottu> Launchpad bug 1558820 in libset-scalar-perl (Ubuntu) "[MIR] libva" [Undecided,Incomplete]
<tjaalton> doko: cool, thanks
<Pharaoh_Atem> nacc: I'm having trouble actually building php-fshl locally
<Pharaoh_Atem> it keeps throwing errors
<nacc> Pharaoh_Atem: paste?
<Pharaoh_Atem> nacc: http://fpaste.org/349497/45979560/
<elbrus> infinity: any progress with debugging fpc FTBFS on powerpc yet?
<elbrus> ginggs: ^^ I don't assume you know more already?
<ginggs> elbrus: i know nothing!
<elbrus> :)
<nacc> Pharaoh_Atem: hrm, rebuilt fine here
<nacc> Pharaoh_Atem: oh, in debian, though
<nacc> let me check that
<infinity> elbrus: I didn't have time over the weekend to dig deeper.  It's on my "free time" TODO this week.
<elbrus> ack
<stgraber> mterry: sorry for those late MIRs took forever for those 3 packages to be accepted into xenial (went unreviewed between December and a couple of hours ago...)
<doko> stgraber, lxc team == you?
<nacc> Pharaoh_Atem: hrm, built fine in a sid schroot too
<stgraber> doko: lxc team is hallyn, mmcc, tych0 and I
<stgraber> doko: jgrimm is also in the team so he can get the rest of the server team up to speed on bugs if we miss any
<doko> stgraber, was the team accepted as a bug subscriber in the past?
<stgraber> doko: and the server team is also subscribed to those packages separately (jgrimm was working on it now-ish)
<doko> ahh, ok
<stgraber> doko: yeah, we are the MIR subscribe team for a dozen packages
<jgrimm> stgraber, doko: should be done already even
<stgraber> doko: https://bugs.launchpad.net/~ubuntu-lxc/+packagebugs those are all the packages that are in main for which the ubuntu-lxc team is the main contact point
<doko> stgraber, mterry: I just did the NEW review, so I'll propose to promote these. just waiting on your feedback
<doko> mterry's feedback
<stgraber> cool. I poked mterry because he's been handling all our other go-related MIRs this cycle but I'm not picky as to what MIR team member gives the go ahead :)
<stgraber> I refreshed the go-lxc one with a new snapshot an hour ago to pick up the bugfixes needed for LXC 2.0, the other two looks to be perfectly functional so no reason to update to new upstream snapshots
<jdstrand> superm1: hey, fyi bug #1565963
<ubottu> bug 1565963 in seahorse (Ubuntu) "seahorse does not see gpg keys after upgrade to gnupg 2.1" [Undecided,New] https://launchpad.net/bugs/1565963
<jdstrand> seb128: fyi, ^
<superm1> thanks, i'll take a look
<nacc> slangasek: does LP: #1565097 need to be re-uploaded?
<ubottu> Launchpad bug 1565097 in refdb (Ubuntu) "Update to PHP7.0 dependencies" [Undecided,Fix committed] https://launchpad.net/bugs/1565097
<nacc> slangasek: i don't see it changed yet
<slangasek> nacc: quite possibly! let's see
<nacc> slangasek: jgrimm: i believe i'm down to the last 9 packages that need updating, fyi; a few will be in a broken state (e.g., drupal7 pending drupal8 or drupal7 updates) and i'm still contacting upstreams for a few to see if they have php7 versions we can pull down
<nacc> slangasek: but i think we'll be in a position to remove src:php5 soon, if you want, with minimal breakage to the archive, afaict
<jgrimm> nacc, great!
<slangasek> nacc: my count of remaining affected packages Friday was higher than yours; was your count including or excluding things that were still awaiting sponsorship at the time?
<TJ-> nacc: are any of the php5/php7 changes you've been shepherding in any way capable of removing a user from the sudo group? specifically anything related to libapache2-mod-php5 and/or a2enmod ?
<TJ-> nacc: I'm thinking .postinst mostly
<nacc> slangasek: including those things still awaiting sponsorship. My count was more of what is left to touch list; the official reverse-depends count is 30 right now, but i submitted a bunch today and some are false-positives due to php5 | php
<nacc> TJ-: hrm, in general, i've not changed any fucntionality in the postints, beyond calling the right command (for php5enmod -> phpenmod) or right parameter (a2endmod php5 -> a2endmod php)
<nacc> TJ-: so I'd be surprised if that happened, but I'm not going to make any guaranteed; do you have a specific package in mind?
<nacc> or a bug, i guess? :)
<slangasek> nacc: ok.  my count as of Friday was 56, and a couple of those are already on the removals list (php-imap, php-mcrypt) but we should reconcile these counts soonish :)
<TJ-> nacc: maybe you could run your eyes over the following pastebin? A user in #ubuntu+1 reported it and I did some 'live' debugging and we couldn't figure it out, so not even sure it is a bug, and the user re-added themselves so the issue is now dead. http://pastebin.ubuntu.com/15585996/
<nacc> slangasek: yep, let's plan on syncing this afternoon?
<slangasek> nacc: +1
<nacc> TJ-: looking; but fwiw, i've not actually touched the src:php5 itself, which is a bit out of sync with debian probably
<nacc> TJ-: it's goign to be removed
<nacc> TJ-: so i'd just suggest to that user they need to migrate asap :)
<nacc> TJ-: and/or reproduce it with php7
<TJ-> nacc: right... I just wanted to do a heads up since we're so close to release... the trigger might have been a2enmod rather than the package install; hard to know but would be awful for that to escape into the wild
<nacc> TJ-: yep, i'll try and reproduce it here in a bit?
<tkamppeter> infinity, hi
<TJ-> nacc: well no great pressure, as I said, the user re-added themselves from a recovery boot and I couldn't find any other mentions of similar stuff. It was a fresh clean install of 16.04 about 45 minutes before it happened, though.
<nacc> TJ-: ok, np; but first, lunch! :)
<TJ-> nacc: supper :)
<infinity> tkamppeter: Hi.
<tkamppeter> infinity, because of cups-filters. I do not know whether you know that I have made use of the fact that one could run LSB-compliant packages on Ubuntu.
<tkamppeter> infinity, for this there was an "lsb" package. Debian pulled this feature out, very shortly before our FF, not letting me a chance to introduce a new package.
<tkamppeter> infinity, so as LSB compatibility was actually only used by us to allow manufacturers to supply printer drivers, I have simply re-introduced the LSB compatibility by taking the stuff which was taken out of the lsb package into cups-filters.
<tkamppeter> infinity, only that I forgot the postinst  in the first place and got a bug report because of this and added it today to complete my work.
<infinity> tkamppeter: Yes, I followed your bug report to see what you were doing.  cups should not, in any way, be responsible for providing ld.so links, however.
<tkamppeter> infinity, so does this mean that I should say LSB driver support is skipped on the LTS or forever?
<infinity> tkamppeter: No, it means you should probably talk to Foundations people before deciding to hack around something like this in a printer driver package. :P
<slangasek> nacc: zend-framework> the prior-version argument to dpkg-maintscript-helper mv_conffile is strongly recommended
<infinity> If we decide LSB ld.so links belong anywhere, it should be something reasonably low-level, either a re-introduction of some lsb thing, or in glibc itself.
<slangasek> nacc: (not blocking this upload on it, but you really want that there so that things eventually clean up)
<infinity> tkamppeter: Surely, you see how your method would immediately go sideways if someone else also decides they need that functionality.
<tkamppeter> infinity, so what I could perhaps do then is to recover the lsb-source package to its old state, of before Debian took everything out and sync cups-filters with Debian to remove all LSB stuff from it. OK?
<infinity> tkamppeter: I don't think reverting lsb is sane either.  But leave it to slangasek and I to sort out the best way to solve this one.  cups-filters definitely shouldn't have an lsb package, though.
<jdstrand> superm1: I added some more info to the description of the bugs. the secret keys didn't get migrated
<tkamppeter> infinity, slangasek, so please check and tell me what is the best solution for that.
<tkamppeter> infinity, slangasek, the solution can be a short-term solution for 16.04 only. On the OpenPrinting Summit I will tell manufacturers that the LSB is dead for printing as one of the two principal distro families left the LSB.
<slangasek> tkamppeter: an LTS in not "short term"; anything deployed here has to be supported on upgrade for 2 years, so needs to be designed carefully. I'm fairly certain the right answer is to put the symlinks in glibc, but I'll leave that to infinity to confirm
<tkamppeter> infinity, slangasek, the package in which the symlinks where before was lsb-core, coming from the lsb source package.
<slangasek> we're aware
<Pharaoh_Atem> nacc: I'm not quite sure, but I think all of these debian package build tools hate me :/
<slangasek> nacc: why does yubikey-ksm call phpenmod in its postinst for a module it does not ship?
<slangasek> nacc: (not a regression, not blocking the upload, but ugh)
<slangasek> nacc: mv_conffile, same thing for wikidiff2
<nacc> slangasek: oh sorry, i rusehd that!
<nacc> slangasek: will post updated shortly
<tjaalton> should unattended updates show install progress on shutdown?
<nacc> slangasek: updated in both
<slangasek> nacc: 'tcpdf' - that's the Transmission Control Protocolortable Document Format, right?
<rbasak> slangasek: I'm not sure what you mean by "Robie (the uploader of the version (re?)introducing the recommends" in bug 801244 but I think that's moot now?
<ubottu> bug 801244 in vblade-persist (Ubuntu) "[MIR] vblade-persist" [Undecided,Won't fix] https://launchpad.net/bugs/801244
<rbasak> AFAICT, I've never uploaded a vblade-persist.
<mwhudson> anyone know what "main::scan_file() called too early to check prototype at /usr/bin/aclocal-1.11 line 644." means?
<mwhudson> https://launchpadlibrarian.net/251176532/buildlog_ubuntu-xenial-amd64.google-perftools_2.4-0ubuntu4_BUILDING.txt.gz
<slangasek> rbasak: you sponsored the upload that reintroduced the recommends: on vblade-persist from vblade
<rbasak> Ah
<mwhudson> is it code for running autoreconf or something?
<rbasak> slangasek: ah yes, I remember now. Sorry! Yeah cpaelzer is right. That was to bring vblade closer to sync with Debian so we can stop caring for it in universe next cycle. So no MIR any more so no further action I think.
<rbasak> (the conffile move needs a delta but that can go > Xenial)
<slangasek> rbasak: did vblade get uploaded to drop the MIR?  (I haven't looked at any of this, was just poking the bug via component-mismatches)
<rbasak> slangasek: I wasn't aware of the MIR at the time. It was in MoM as needing a merge. We looked, decided we didn't want to maintain a delta, so merged it dropping most of the delta for a graceful removal next cycle.
<slangasek> rbasak: ok, you can't just drop the delta.  It's a component-mismatch; packages in main need to not recommend packages in universe
<slangasek> it was confusing to have an MIR bug still around from before vblade was promoted, but this still needs to be dealt with
<rbasak> slangasek: sorry, I missed that.
<slangasek> rbasak: my recommendation, given the goal of minimizing delta, is to change that Recommends back to a Suggests in vblade; the alternative is to try to make vblade-persist work without ruinit
<slangasek> sorry, "runit" ;P
<rbasak> slangasek: I think we might be able to drop vblade from server-ship and get it into universe.
<slangasek> rbasak: also wfm :)
<slangasek> but that's a server product decision I guess, --> SEP
<nacc> slangasek: heh, i who knows why they named it that way; it appears to be a fork of fpdf, also their website claims "Started in 2002, TCPDF is now one of the world's most active Open Source projects"
<slangasek> radioactive? bioactive?
<nacc> Pharaoh_Atem: can you help me check something; if you install php-pecl-http and neable it, do you see a complaint if you just run `php`?
<Pharaoh_Atem> nacc: how do I enable it?
<rbasak> slangasek: SEP?
<nacc> Pharaoh_Atem: actually, i think it will be enabled on install
<slangasek> rbasak: "somebody else's problem" ;)
<nacc> Pharaoh_Atem: alternatively, phpenmod http?
<rbasak> slangasek: ah :)
<rbasak> slangasek: I'll take care of it
<Pharaoh_Atem> nacc: is this what you want to see? PHP Warning:  PHP Startup: Unable to load dynamic library '/usr/lib/php/20151012/http.so' - /usr/lib/php/20151012/http.so: undefined symbol: php_resource_factory_init in Unknown on line 0
<nacc> yeah
<nacc> it seems like something is not putting in the lib dependency
<nacc> that symbol is from raphf
<nacc> but `ldd` indicates http.so doesn't load raphf.so, which seems like a mistake
<nacc> trying to figure out what's mssing
<sarnold> see also dlopen()
<slangasek> raphf.so, implies it's not a library but a plugin of its own; so linking to it is likely wrong
<Pharaoh_Atem> yeah
<nacc> sarnold: true; but not called in this library, and not linked against libdl
<Pharaoh_Atem> which means it's a runtime dependency
<slangasek> http.so probably assumes this symbol is resolvable through the parent
<slangasek> by raphf.so being loaded first
<nacc> slangasek: so maybe it's an ordering thing
<slangasek> could be
<nacc> istr something about the order of names does matter
<nacc> let me see if i can find it
<Pharaoh_Atem> is it being linked with -Wl,--no-undefined?
<slangasek> could also be a scoping issue with the options php itself passes to dlopen()
<slangasek> Pharaoh_Atem: that would fail at build time if it were
<Pharaoh_Atem> right
<rbasak> slangasek: I've passed to kirkland/jgrimm for an ack. If they say yes, I'll unseed it.
<Pharaoh_Atem> so.... this just happened? http://fpaste.org/349595/59805700/
<Pharaoh_Atem> anyone know why usb-modeswitch 2.3.0 isn't available?
<slangasek> Pharaoh_Atem: because don't try to dist-upgrade to -proposed
<Pharaoh_Atem> slangasek: I've been living on -proposed for over two months because php things :/
<slangasek> Pharaoh_Atem: xenial-proposed is not for human consumption
<Pharaoh_Atem> I guess I'm not human :)
<slangasek> you should be doing that in a chroot, not on a desktop root
<jgrimm> rbasak, ack from me (and kirkland gave an email ack to that on Feb 4, as well as, for munin)
<Pharaoh_Atem> slangasek: eh, it's a VM
<kirkland> rbasak: vblade?
<kirkland> rbasak: ack, +1 please drop from main.  vblade (aoe) was needed for eucalyptus, many moons ago
<jgrimm> virtual AoE blade emulator
<jgrimm> yep
<rbasak> jgrimm, kirkland: thanks. Seed changed.
<jgrimm> rbasak, munin too?
<slangasek> nacc: wikidiff2, zend-framework, please provide incremental debdiffs since the previous are already uploaded
<rbasak> jgrimm: no but done now, thanks.
<jgrimm> rbasak, thanks!
<slangasek> nacc: are packages with build-deps but no runtime deps on php5 on your list?  (e.g. jscribble)
<nacc> slangasek: hrm, I thought I did ?
<nacc> slangasek: and no, not build-deps yet, that is next on my list
<nacc> slangasek: i just checked both bugs and the last attachment in each is an incremental debdiff?
<slangasek> nacc: hurrr ok apparently I didn't read it right :)
<slangasek> nacc: core-dev endorsement: "he writes correct code that I subsequently don't read; give him upload rights"
<nacc> slangasek: heh
<rbasak> pitti: is there an easy way without cgmanager to get myself a shell that is running in its own cgroup?
<rbasak> I asked hallyn, he suggested I ask you :)
<slangasek> nacc: wrt php-mongo,php-horde-mongo - there are an awful lot of packages depending on php-horde-mongo, all of which will be broken by this; are we ok with that?
<hallyn> rbasak: which controllers are you intersted in?
<slangasek> nacc: oh - nope, these are all recommends, ignore me
<nacc> slangasek: right, it should all be recommends
<nacc> i should have noted that, but did see that before suggesting its removal
<rbasak> hallyn: I want to limit CPU and memory. I'm told that limiting memory will stop my entire cache from being dropped if I do something big in there.
<rbasak> Ideally I want "run-in-cgroup --memory=X --cpu=X /bin/bash"
<rbasak> (unprivileged)
<hallyn> you want cpu not cpuset right?
<rbasak> I'm not sure.
<hallyn> anyway memory you can do with no privilege with or without cgm;  cpu you'd need to edit /etc/pam.d/common-session to add ",cpu" to the libpam-cgfs line
<hallyn> so in the meantime i'd recommend yeah use cgm.  I think we should come up wiht a good systemd based answer and put that into the server guide
<rbasak> hallyn: OK, thanks
 * rbasak reads up
<nacc> Pharaoh_Atem: slangasek: may have found the pecl-http issue, typo -- checking to see if it fixes it
<infinity> rbasak: Who's taking ownership of evaluating the removal of the block-proposed tag from https://bugs.launchpad.net/ubuntu/+source/squid3/+bug/1473691 ?
<ubottu> Launchpad bug 1473691 in squid3 (Ubuntu) "[FFe] squid: Update to latest upstream release (3.5)" [Critical,Fix committed]
<rbasak> jgrimm: ^^
<rbasak> Or rharper maybe?
<infinity> rbasak: We're probably approaching a point where we're not going to find any more bugs without inflicting it on users.
<rbasak> I've seen activity, but I'm not sure who's holding the baton right now.
<rharper> last I saw was a 1ubuntu4 upload with some fixes from slangasek on the maint scripts;
<infinity> And another from me, yes.
<rharper> I can give the proposed package a test; but since it was maint stuff, I don't it to modify the functionality w.r.t universe packages we were testing
<rharper> rbasak: I didn't get any time to test additional rdepends on squid3 from universe yet;
<rharper> we did want to maybe see about maas and squid3
<infinity> Well, we're running out of time to "see about" anything.
<rharper> I don't see any reason to hold back
<rharper> better to get the hurt ASAP
<rbasak> rharper: any known issues with what is in -proposed currently?
<infinity> That was sort of my thinking.
<rbasak> Sorry, I haven't really been following along.
<rharper> rbasak: none that I'm aware of
<infinity> I'm sure we missed some bugs, but I've fixed the ones *I* run into.
<infinity> So, I need other people to find more. :P
<rbasak> OK, let's drop the tag as I don't hear any objections.
 * rharper nods 
<slangasek> unless we want to risk keeping squid3 out-of-date for another LTS, we should let 'er rip
<rharper> heh
<rharper> not after all of this trouble
<infinity> And someone might want to merge the new upstream after we let this one through.
<infinity> Because more bugs.
<rharper> 3.5.15 (new stable IIRC)
<slangasek> yes there may be some knock-on effects, but we need to find them before we can sort them out, and at this point we need it in xenial before we're likely to find them
<rharper> yep
<rbasak> I saw activity on bug 1448149. I think that probably doesn't affect Xenial?
<ubottu> bug 1448149 in squidguard (Ubuntu) "Squid 3.3.8 incompatible with squidGuard 1.5-4" [High,Triaged] https://launchpad.net/bugs/1448149
 * infinity removes the tag.
<rbasak> (in fact it would be fixed by Xenial?)
<rharper> rbasak: yes
<rharper> fixed
<rbasak> Lovely. Thanks!
<rharper> at least with the trivial test case kick1nz setup
<Pharaoh_Atem> nacc: cool
<nacc> Pharaoh_Atem: nm, didnt' fix it (but is a real bugfix :)
<slangasek> nacc: netmrg is dep-wait on all archs
<slangasek> looks like an outdated build-dep on libmysqlclient15-dev?
<rbasak> slangasek: I have that on my list to fix.
<nacc> slangasek: i believe it's due to the pending migration
<rbasak> Right
<slangasek> what's pending that's causing it to dep-wait?
<rbasak> Is https://launchpad.net/~mysql-ubuntu/+archive/ubuntu/mysql-5.7/+sourcepub/6249018/+listing-archive-extra helpful?
<rbasak> That's our test build.
<jgrimm> rharper, do you know if maas got any testing done on squid3 proposed?  they said they'd have to make changes in maas.
<slangasek> $ apt-cache showpkg libmysqlclient15-dev
<slangasek> N: Unable to locate package libmysqlclient15-dev
<slangasek> $
<nacc> slangasek: sorry, i mean the deps need to be updated, but that the sql migration is going to fix it (or needs to)
<rbasak> slangasek: s/libmysqlclient15-dev/libmysqlclient-dev/. They're equivalent. We dropped the virtual package from MySQL 5.7 that's in proposed.
<slangasek> nacc, rbasak: right, so netmgr should get reuploaded with the fixed build-dep and afaics that doesn't need to wait for anything else
<slangasek> (then once built, will block in -proposed as part of the mysql-5.7 transition - but should get done sooner than late so as to not itself block mysql-5.7?)
<nacc> slangasek: good point; rbasak want me to submit the debdiff?
<jgrimm> roaksoax,  squid3 block-proposed just removed, so it'll migrate assuming no failures.
<rbasak> No need, I have it local.
<rbasak> (already done, just not uploaded)
<nacc> rbasak: ok, thanks
<slangasek> nacc: and is lasso on your todo list?
<infinity> jgrimm: Already has migrated, in fact.
<rbasak> slangasek: it's in my queue of uploads for the transition.
<jgrimm> infinity, ah..
<rbasak> (netmrg that is)
<rbasak> slangasek: I was holding back in case we decided to not do the transition.
<infinity> rbasak: I think we're past the point of turning back.
<rbasak> I was going to talk to infinity about it.
<infinity> rbasak: Worst case scenario, we drop mysql-proxy and myodbc, and the rest of the world looked okay, right?
<rbasak> infinity: OK. I'll begin tomorrow morning :)
<rbasak> infinity: AFAICT, yes.
<infinity> rbasak: Yeah.  Let's do it, then.
<slangasek> rbasak: ah, k
<nacc> slangasek: urgh, that doesn't show up in `reverse-depends` ... how strange
<nacc> slangasek: oh wait, it will
<rbasak> infinity: ack
<infinity> rbasak: I can demote those to -proposed when the rest is looking alright, and we can outright remove them from the archive when we're sure that's the right thing to do.
<slangasek> rbasak, infinity: oh, er, myodbc is already broken in the archive, if you didn't know
<nacc> slangasek: yes, on my list
<infinity> slangasek: It is?
<slangasek> infinity: yes, it built and then had undefined symbols and I decided I had better things to do with my life
<infinity> slangasek: Awesome.
<slangasek> https://bugs.launchpad.net/ubuntu/+source/myodbc/+bug/1010044
<ubottu> Launchpad bug 1010044 in myodbc (Ubuntu) "program crashes saying "undefined symbol: strfill"" [Undecided,Confirmed]
<rbasak> slangasek: upstream are working on fixing up myodbc for us. We can land that late I guess, since there's no risk of regression then.
<infinity> slangasek: File a removal in Debian and yank it from Ubuntu and wash your hands of it? :P
<rbasak> Skuggen: ^^ FYI.
<slangasek> infinity: that says it's been broken for 4 years, hth
<rbasak> slangasek: well that certainly makes life easier. Thanks :)
<infinity> slangasek: I feel a little less bad about some of my underloved Debian packages now.  At least mine run.
<slangasek> infinity: trade you upstreams
<infinity> slangasek: Though, I suppose yours is quite secure.
<slangasek> nacc: ok.  How about libkolab? Its runtime dep is on phpapi-20131226, not on php5-*
<slangasek> infinity: unbreakably secure
<nacc> slangasek: yes, it shows up due the build-dep
<slangasek> nacc: ok
<nacc> slangasek: i haven't fixed any build-deps on src:php5
<nacc> or very few
<slangasek> nacc: fwiw here's my current watchlist: (grep-dctrl -n -sSource:Package -FDepends php5 -o -FDepends phpapi-20131226 /var/lib/apt/lists/archive.ubuntu.com_ubuntu_dists_xenial_*binary-amd64_Packages; grep-dctrl -n -sPackage -FBuild-Depends,Build-Depends-Indep php5 /var/lib/apt/lists/archive.ubuntu.com_ubuntu_dists_xenial_*Sources)   | sort -u
<infinity> Huh.  How is it 16:21 already?  I guess I should go find breakfast or lunch or whatever.
<nacc> slangasek: ok, thanks ... that's handy to have
<Pharaoh_Atem> the day just flies by, doesn't it?
<slangasek> nacc: NB that only looks at release pocket, not -proposed, so season to taste
<nacc> slangasek: right
<slangasek> pitti: wow, watershed demoted!
#ubuntu-devel 2016-04-05
<smckee> Hi everyone, I'm doing a study at Oregon State University trying to determine what is difficult about merge conflicts and how developers solve their conflicts. We're looking for professional developers with 3+ years of experience. Would anybody here be interested in participating in a ~20 minute interview? We will, of course, compensate you for your time :)
<teward> !offtopic | smckee
<ubottu> smckee: #ubuntu is the Ubuntu support channel, for all Ubuntu-related support questions. Please register with NickServ (see /msg ubottu !register) and use #ubuntu-offtopic for other topics (though our !guidelines apply there too). Thanks!
<teward> close enough
<sarnold> I've gotta say, twenty minutes feels like an absolute eternity, especially this close to release date..
<smckee> teward and ubottu, My apologies, I wasn't sure which channel to use as there are so many to choose from.
<nacc> Pharaoh_Atem: slangasek: i can confirm http.so is loading before raphf.so per strace, even though the http.so build specifies: PHP_ADD_EXTENSION_DEP([http], [raphf], true)
<Pharaoh_Atem> nacc: so is there a way to fix that?
<nacc> Pharaoh_Atem: not sure, need to figure out where the bug is first
<nacc> slangasek: fyi, using your output, we have about 46 pacakges left to fix up, i'm starting on build-deps now
<nacc> some might be swig/drops, too
<slangasek> nacc: yep, that number sounds about what I saw at last check
<nacc> slangasek: ok, will try to get to 0 tomorrow :)
<slangasek> nacc: I actually count 37 now, with some manual filtering of the false-positives
<slangasek> and some are pending either in -proposed or in the sponsor queue
<nacc> slangasek: cool, yeah, that number above was raw, not processed for the ones i know about
<stgraber> pitti: do you think it would be possible to publish the VM images for adt somewhere on autopkgtest.ubuntu.com? just spent half an hour trying to understand why my testsuite failed on adt but not locally, just to find that it had to do with the package list differing as I'm using the cloud images locally that contain a bunch more things
<stgraber> (in this case, I was missing lxc-templates)
<Skuggen> rbasak: ack
<Skuggen> infinity, rbasak: So does that leave us with the suggestion in https://bugs.launchpad.net/ubuntu/+source/myodbc/+bug/1564856/comments/1? Focus on getting everything else working, and then see if we can get myodbc working and updated?
<ubottu> Launchpad bug 1564856 in myodbc (Ubuntu) "myodbc uses internal libmysqlclient functions no longer exported by 5.7" [Undecided,New]
<infinity> Skuggen: Yep.
<sarnold> which installer is used on the server disk? is that debian-installer or ubiquity? I see them both in the pool/
<Unit193> infinity: BTW, do you think it'd be sane to have ddebs commented out in the default sources.list, just like proposed?
<cpaelzer> good morning
<pitti> Good morning
<Foxtrot> Morning
<pitti> stgraber: I don't think that there's anywhere I could publish them, but they are using "--setup-commands setup-testbed" on lcy01, and the equivalent of adt-buildvm-ubuntu-cloud on the two other clouds
<pitti> stgraber: I'd like to use the latter on all three, but lcy01 doesn't allow new image builds, so it behaves differently :/
<pitti> rbasak: sure, you can sudo mkdir the cgroup you want, and then echo $$ > /sys/fs/cgroup/<controller>/<cgroup>/tasks
<pitti> rbasak: ah, reading more scrollback -- you can use something like "sudo systemd-run -t -p MemoryLimit=5M bash" too
<pitti> rbasak: see man systemd.resource-control for the various settings wrt. cgroup limits
<infinity> sarnold: d-i is used to install the server ISO.  ubiquity is there for people to use oem-config post-install.
<sarnold> infinity: thanks :D
<pitti> stgraber: I just noticed that adt-buildvm-ubuntu-cloud hangs eternally now, on/after "Started LXD - network bridge" (this is after *removing* lxd..)
<GunnarHj> pitti: Good morning, Martin. As an alternative to the fontconfig upgrade we talked about yesterday, we successfully patched a few upstream commits:
<GunnarHj> https://launchpad.net/~gunnarhj/+archive/ubuntu/fontconfig-test/+packages
<GunnarHj> Would you consider that to be a safer/better alternative, considering that we are late in the cycle? (The patch is not small.)
<pitti> GunnarHj: yes, quite obviously safer; do we actually want/need any of the other fixes from the new version?
<pitti> GunnarHj: shall I sponsor this for now?
<GunnarHj> pitti: Not as far as we know. This ought to be sufficient.
<GunnarHj> pitti: Yes, it would be great if you could sponsor it. (Can you please correct a typo in the changelog if you do - the patch name is not correct.)
<pitti> GunnarHj: uploaded with fixed changelog, thanks!
<GunnarHj> pitti: Thank you!
<pitti> meh, github.com feels like a pit of tar today
<pitti> and now I'm getting unicorns
 * Unit193 tests pitti's BAC.
<smb> pitti, that rather sounds like an improvement... ;)
<pitti> smb: but *pink* unicorns?? *shudder*
<pitti> Unit193: "BAC"?
<smb> Sure its not *pink* but some other colour we cannot describe
<pitti> ah, https://status.github.com/ mentions this too
<Unit193> pitti: Blood Alcohol Content. ;)
<pitti> this was *not* a pull request for "moar beer!" :)
<pitti> it's a little early in the morning for that
<smb> pitti, not in Bavaruia
<infinity> pitti: That must have just happened, I was getting ~100 Mbit/s from them an hour ago.
<elmo> infinity, pitti: they're currently being routed via a DDoS scrubber FWIW
<pitti> and https://status.github.com/ now changed from "connectivity problems" to "major service outage"
 * pitti will just wait then, not only me obviously
<pitti> Laney: whoa, "No nova image available that matches ubuntu/ubuntu-vivid-.*-i386-server" â seems our clouds lost the vivid images :/
<pitti> lgw at least
<flexiondotorg> Morning Pilots xnox, tjaalton, smoser
<flexiondotorg> If you are able please can you take a look at my sponsor requests?
<flexiondotorg> https://bugs.launchpad.net/ubuntu/+source/mate-tweak/+bug/1565356
<ubottu> Launchpad bug 1565356 in mate-tweak (Ubuntu) "Sync mate-tweak 3.5.9-1 (universe) from Debian unstable (main)" [Undecided,New]
<flexiondotorg> https://bugs.launchpad.net/ubuntu/+source/ubuntu-mate-artwork/+bug/1563971
<ubottu> Launchpad bug 1563971 in ubuntu-mate-artwork (Ubuntu) "ubuntu-mate-artwork 16.04.6 bug fix release [debdiff attached]" [Undecided,New]
<Laney> pitti: !!!
 * pitti sends an RT
<seb128> bdmurray, hey, do you have any idea why https://errors.ubuntu.com/problem/9add44104f20d47646d1c9f9f952bc5fee42bbc3 fails to give a backtrace?
<doko> mvo_, please could you fix your goget-ubuntu-touch b-d's? see  http://people.canonical.com/~ubuntu-archive/nbs.html
<doko> jamespage, python-pathspec accepted, however the python3 package doesn't use python3:Depends
<jamespage> doko, ack will get that fixed up...
<ginggs> pitti: could we ignore the i386 autopkgtest for julia please?
<pitti> ginggs: the llvm error is back? ok
<doko> jamespage, why are python-stuf and python-otherstuf not packaged for Python3?
<pitti> ginggs: hint committed
<ginggs> pitti: danke
<doko> jamespage, theblues: Comment: License information is not present in the 0.1.1 release; see
<doko>  XXX for actual licensing information.
<doko> is this still valid?
<rbasak> pitti: neat. Thanks!
<doko> jamespage, 	python-libcharmstore doesn't have a copyright file
<jamespage> doko, actually that might not be - let me check (re the blues)
<jamespage> doko, stuf and otherstuf depend on python-parse which is not yet py3 enabled...
<jamespage> doko, let me check in libcharmstore - I swear I fixed that
<doko> well, then enable it ;)  apparently it won't be enabled in Debian
<jamespage> doko, I'll ask marcoceppi to take a look at the py3 enablement for parse and *stuf
<jamespage> python-libcharmstore in the NEW queue does have a copyright...
<doko> jamespage, it's the comment in debian/copyright which I cited
<jamespage> doko, you are correct about theblues - my comment in the copyright file was on the first version I reviewed which lackes any upstream licensing information
<jamespage> I can correct that and re-upload if you like, or I can fix it post acceptance...
<doko> jamespage, ok, but please before the release ...
<jamespage> doko, I have it ready to go for theblues...
<jamespage> doko, http://paste.ubuntu.com/15627833/
<jamespage> doko, re 'python-libcharmstore doesn't have a copyright file'
<doko> jamespage, the upstream copyright file is missing
<jamespage> doko, lemme take anther look
<jamespage> doko, ah sorry I missed that
<jamespage> LGPL is identitified in the setup.py but its not versioned...
<jamespage> marcoceppi, hey - can you update libcharmstore for licensing information please; its to light atm
<pkern> We don't install git by default on laptop. Heresy.
<highvoltage> 1/win 10
<mvo_> doko: sure, will do
<mvo_> doko: how often is the nbs.html updated? this should be fixed with the latest upload
<doko> mvo_, once the package is migrated
<doko> xnox, is this temporary? https://launchpadlibrarian.net/251822278/buildlog_ubuntu-xenial-s390x.openexr_2.2.0-9ubuntu1_BUILDING.txt.gz
<xnox> looks weird
<doko> bdmurray, please could you have a look at https://launchpadlibrarian.net/251821539/buildlog_ubuntu-xenial-amd64.update-manager_1%3A15.10.3_BUILDING.txt.gz missing b-d?
<hallyn> pitti: hey - lxc and lxcfs use Delegate= in their systemd jobs.  In jessie that's not supported.  What is the recommended way to deal with that?  sed it out in debian/rules until systemd is updated, or is there a better way?
<pitti> hallyn: systemd normally ignores directives it does not know about (at most it might warn about them); does that actually cause problems?
<hallyn> yeah apparently theywon't start
<TJ-> interesting openjdk-7 question from a user: required by the android build tools, but no longer in 16.04 (although I have a March 5th 16.04 chroot that still contains openjdk-7) - is this intended (to break android builds) ?
<hallyn> fiding url
<hallyn> pitti: https://lists.linuxcontainers.org/pipermail/lxc-devel/2016-April/013964.html
<pitti> hallyn: ah, seems I'm wrong then, sorry
<doko> tjaalton, is ubuntu-x-swat used as bug subscriber for other packages as well?
<tjaalton> doko: all of X
<doko> mvo_, goget-ubuntu-touch (0.33-0ubuntu2 to 0.34-0ubuntu1)
<doko> won't migrate: ubuntu-emulator/i386 unsatisfiable Depends: ubuntu-emulator-runtime
<TJ-> Urgent: we seem to have a widespread signing-key mismatch for the trusty-updates lists, on the main archive server and mirrors
<cjwatson> TJ-: sample output please
<cjwatson> I'm not seeing it here
<TJ-> cjwatson: 2 users in the last hour reported hash sum mismatch for it, one on the main archive, one on the US archive. I've just pulled the files manually and http://paste.ubuntu.com/15629885/
<cjwatson> (note that archive.ubuntu.com is a mirror too)
<TJ-> cjwatson: right :)
<cjwatson> the master site is fine
 * cjwatson analyses
<TJ-> I've just grep-ed my irc log, for the 2 users reporting. The 1st user cleared their /var/lib/apt/lists/ out and redid apt-get update and still hit it. http://paste.ubuntu.com/15629926/
<TJ-> hah, 3 users isn't there. missed that :)
<cjwatson> all archive.ubuntu.com hosts are fine
<cjwatson> which is a superset of all us.archive.ubuntu.com hosts
<cjwatson> TJ-: so I can't reproduce this as a live issue on our primary mirrors.  please ask users to pastebin the output of "apt-get -o Debug::Acquire::http=true -o Debug::Hashes=true update"
<TJ-> cjwatson: will do
<cjwatson> my (crude) methodology was:
<cjwatson> for x in 91.189.88.152 91.189.92.200 91.189.91.15 91.189.92.201 91.189.91.14 91.189.88.149 91.189.88.153 91.189.91.13 2001:67c:1560:8001::11 2001:67c:1562::15 2001:67c:1562::14 2001:67c:1360:8001::17 2001:67c:1360:8c01::19 2001:67c:1360:8c01::18; do mkdir -p $x; curl --resolve archive.ubuntu.com:80:$x -o $x/Release http://archive.ubuntu.com/ubuntu/dists/trusty-updates/Release; curl --resolve archive
<cjwatson> .ubuntu.com:80:$x -o $x/Release.gpg ...
<cjwatson> for x in *; do gpg --verify $x/Release.gpg $x/Release; done
<cjwatson> ... http://archive.ubuntu.com/ubuntu/dists/trusty-updates/Release.gpg; done
<cjwatson> TJ-: this sort of thing is usually a mirror update race which goes away though
<TJ-> cjwatson: OK, I thought that for the first 1 although the user had tried 30 minutes apart, but with 2 more reporting it seemed ... strange
<cjwatson> TJ-: well, if the race happens to hit a mirror rather than just a single user, it can persist for a while
<cjwatson> oh hell my methodology is bust isn't it
<cjwatson> I was checking Release vs. Release.gpg not Packages files
<cjwatson> still, that debug output would be useful
<TJ-> :p
<TJ-> I've asked for it, I'll give you pastebin links once they're available
<TJ-> and:   scwizard | TJ-: http://paste.ubuntu.com/15630027/
<cjwatson> this issue will go away for xenial soon
<cjwatson> TJ-: that's not the output of the command I gave
<TJ-> hmm!
<cjwatson> come back when it actually has debugging information in it :)
<TJ-> oh, does debugging go to stderr by any chance? if so, it's because of the redirection I gave them :p
<cjwatson> probably
<cjwatson> 2>&1 |
<cjwatson> or >foo 2>&1
<TJ-> cjwatson:  scwizard | TJ-: http://paste.ubuntu.com/15630108/
<smoser> hey, for flexiondotorg it seems acceptable to sync that to me. i tried copy-package with target of xenial-proposed but i think that just got swallowed . should i just copy by hand (pull-source and then dput)?
<cjwatson> smoser: before you do that, what exactly did you do with copy-package?
<smoser> bah. i just noticed its in unapproved.
<cjwatson> ah well there you go
<smoser>  yeah. copy-package --from=debian --to=ubuntu --suite=sid --to-suite=xenial mate-tweak
<cjwatson> TJ-: still investigating, it's just being slow
<smoser> so yeah, thanks cjwatson . sorry for noise.
<TJ-> cjwatson: yes, I'm trying to reprodce on other mirrors
<cjwatson> TJ-: I think that's probably unnecessary at this point
<mvo_> sergiusens: hm, what ubuntu-device-flash is unhappy about ubuntu-emulator-runtime:won't migrate: ubuntu-emulator/i386 unsatisfiable Depends: ubuntu-emulator-runtime - any hints? should this get demoted to recommends?
<sergiusens> mvo_, I will invoke sil2100 for that, I have no idea about the android emulator anymore
<sergiusens> if it is demoted to recommends we might need some code changes in the ubuntu-emulator command to fail gracefully
<doko> jamespage, your commons-vfs merge is dep-wait for a month
<jamespage> nacc, hey - can you take a looks at why common-vfs is dep-wait as doko points out please
<jamespage> as that was pretty much your merge...
<cjwatson> smoser: I'm a little surprised that worked; I would expect to need --to-suite=xenial-proposed instead.
<cjwatson> But there is a mate-tweak in unapproved for proposed.
<cjwatson> smoser: Just "syncpackage mate-tweak" would have worked though, which is a bit friendlier when you don't need low-level control.
<smoser> oh. i did use xenial-proposed
<smoser> with just 'xenial' it failed with a nice message like "use xenial-proposed, smoser"
<cjwatson> Ah good.
<cjwatson> Having the raw copyPackage API understand the redirection directly would be much riskier, because basically the same interface is used to promote stuff from xenial-proposed to xenial, so we don't try to be magical there.
<TJ-> cjwatson: all seems fine now; race condition across those 3 mirrors must have been coincidence 3 users fetched at that point
<cjwatson> TJ-: mirror.jmu.edu still has a Release file from four hours before archive.ubuntu.com but a more current Translation-en.bz2
<TJ-> cjwatson: yes, that user started in us.archive and switched to try to avoid the issue ... they've switched back now
<cjwatson> TJ-: but it looks like an entirely straightforward race, nothing sinister; should clear up at its next sync
<TJ-> cjwatson: glad to hear it... was making me concerned with several reports in a short space of time :)
<cjwatson> Oh, we usually get them in bulk when a mirror races.
<TJ-> not seen one in ages, my good fortune ... thanks for your swift help :)
<cjwatson> by-hash is hopefully rolling out todayish for xenial.  Not for earlier releases, so we'll have to put up with it for the lifetime of trusty, but with any luck this should be on the decline.
<rharper> nice!
<bdmurray> seb128: I'll have a look but that crash looks similar to bug 1538438.
<ubottu> bug 1538438 in apt (Ubuntu) "apt-helper crashed with SIGABRT in __gnu_cxx::__verbose_terminate_handler()" [High,Triaged] https://launchpad.net/bugs/1538438
<seb128> bdmurray, thanks
<hallyn> pitti: hm, finally gave in and set up a new jessie desktop.  yeah systemd *warns* about unknown Delegate but it runs fine
<hallyn> now i'm annoyed
<bdmurray> seb128: looks like there was no crash signature after retracing
<seb128> bdmurray, would that be because gdb doesn't give a valid stacktrace?
<bdmurray> seb128: https://pastebin.ubuntu.com/15631038/
<seb128> hum, k
<seb128> I wonder why :-/
<bdmurray> seb128: If I find time I'll dig some more, the test case seems pretty straightforward though.
<stgraber> pitti: hmm, that's odd
<nacc> slangasek: ugh, libkolab is going to be ugly; they did their own .ini management, i guess
<nacc> slangasek: meaning they don't install to the typical locations :/
<nacc> slangasek: will need to figure out if there is a good parallel for php7
<nacc> Pharaoh_Atem: any update on libvirt-php?
<slangasek> nacc: php-kolab doesn't appear to be central to the functionality of libkolab (no revdeps on that binary package); could be dropped from the packaging for 16.04, or left uninstallable
<nacc> slangasek: yeah, i think that will be the far saner route for me, it's pretty gross and I don't know it will
<nacc> *well
<slangasek> nacc: right, just let me know if you want to change the packaging to drop the binary (preferred unless you expect this to be fixed in SRU), or if you want it left uninstallable in the archive
<nacc> slangasek: yeah, i'll provide debdiffs for that; it's similar to the swig case imo, not maintained
<nacc> and i'm not sure why kolab needs php bindings :)
<Pharaoh_Atem> nacc: well, it builds and seems to run
<Pharaoh_Atem> but we don't have enough basic unit test coverage
<Pharaoh_Atem> so that's something that we're working on
<nacc> Pharaoh_Atem: ok, PR sent yet?
<Pharaoh_Atem> they don't do PRs, but not yet
<Pharaoh_Atem> I'm hoping to get everything in shape this week for that
<Pharaoh_Atem> the code *is* available in https://gitlab.com/Conan_Kudo/libvirt-php7 in the php7 branch
<nacc> Pharaoh_Atem: we're probably at the point where we're just going to have to drop it
<nacc> not sure
<nacc> i'll confer with slangasek
<nacc> there are no rdeps in the repo, afaict
<Pharaoh_Atem> well, since it's in universe and not part of a seed, I'm hoping I have enough time to get it submitted
<nacc> Pharaoh_Atem: final freeze is next week
<Pharaoh_Atem> yeah, it's the 14th, right?
<nacc> slangasek: heh, do you own php-imlib in debian?
<slangasek> nacc: "own"
<nacc> slangasek: :)
<slangasek> nacc: it's bindings for a language I no longer use, for a library that I no longer care about
<nacc> slangasek: fair enough, i'm guessing it won't compile, will schedule for removal too
<nacc> slangasek: so blocking php-mcrypt's removal right now is roundcube :/
<Pharaoh_Atem> nacc: didn't roundcube say they weren't going to support php7 anytime soon?
<nacc> Pharaoh_Atem: 1.2 supports it, in beta right now, release any day now
<nacc> hopefully
<Pharaoh_Atem> awesome
<dobey> bdmurray: is there any way to get errors.u.c to retrace crashes that failed to retrace due to "the following packages are missing debug symbols" error?
<bdmurray> dobey: I could poke the database so that we try retracing the crash again.
<jamespage> doko, nacc: quick peek at libcommons-net-java - its looks really odd - the binary "libcommons-net-java" is in main, its source is in universe...
<nacc> jamespage: yeah, i think it's still showing up in component mismatches too, right?
<nacc> jamespage: because of libcommons-net-java-doc ?
<jamespage> nacc, yah - but I think its confusion due to a rename - libcommons-net2-java -> libcommons-net-java
<jamespage> doko, I think this is a switch and binary promotion only
<jamespage> libcommons-net2-java got renamed libcommons-net-java
<jamespage> the binary -java is already in main
<nacc> jamespage: ah i see
<jamespage> nacc, doko: confirmed - libcommons-net2-java needs dropping and replacing with libcommons-net-java
<jamespage> commons-vfs is the only main component in the release pocket keeping net2 in main
<jamespage> the version in proposed drops the version
<nacc> jamespage: thanks for digging into that
<slangasek> nacc: roundcube, on my todo for today for precisely that reason
<nacc> slangasek: thanks; i can poke upstream again if you want, but it does sound like they are going to release soon, with something very similar to what's in beta (and their src hasn't changed much since then)
<nacc> their release manager is busy :)
<slangasek> nacc: my only concern on roundcube was, just because you're willing to put in free time to do the SRU does not necessarily mean it's the best use of the SRU's time to process that SRU.  But the odds seem good that we'll get this in before release, so let's go ahead
<nacc> slangasek: yeah, i understand
<nacc> slangasek: http://pad.ubuntu.com/8eABivrkBv
<nacc> Pharaoh_Atem: http://pad.ubuntu.com/8eABivrkBv
<nacc> slangasek: going to lunch for a bit, will sync with you when i'm back
<Pharaoh_Atem> nacc: does swig have support for php7 or is the done status referring to disabling php support in swig?
<slangasek> nacc: you have libdigidocpp marked as 'done' but it doesn't look that way to me?  still build-depends: php5-dev in xenial
<rharper> hi, I'm trying to get a copy of ifupdown source repo on launchpad, bzr branch lp:ubuntu/trusty/ifupdown doesn't work for me (http://paste.ubuntu.com/15637779/)
<rharper> I'm looking into this bug https://bugs.launchpad.net/ifupdown/+bug/1565711 and wanted to see about picking out the just the changes that allow ifup to succeed for manual interfaces; i think that will resolve the issue in the bug; but it's hard to understand where that is in the debdiff between trusty and vivid
<ubottu> Launchpad bug 1565711 in MAAS "vlan configuration/unconfigured interfaces creates slow boot time" [High,New]
<mhall119> hi guys, who can look into an FFE for me?
<teward> mhall119: you might have better luck in #ubuntu-release and poking the release team, though you might be waiting to tomorrow
<mhall119> thanks teward
<nacc> slangasek: done is relative to me :)
<nacc> Pharaoh_Atem: disabling
<rbasak> rharper: I don't trust UDD to ever not be broken.
<rbasak> rharper: but you can "pull-lp-source ifupdown <version>"
<rharper> rbasak: yeah, I can get the source
<rharper> but I wanted the repo
<nacc> slangasek: i can change done to 'waiting on sponsorship'
<rharper> hoping to find smaller commits
<rbasak> Use https://launchpad.net/ubuntu/+source/ifupdown/+publishinghistory for all previous versions.
<rharper> the debian hg repo doesn't seem to have single function commits either
<rbasak> I would git-dsc-commit all of them. That'll at least break down by upload
<rharper> heh
<rharper> I might have to do that
<tjaalton> mdeslaur: hi, have you planned to still merge apache2 (2.4.18-2)? if yes, i've actually done it locally
<mdeslaur> tjaalton: I hadn't planned on it, please go ahead
<tjaalton> ok cool
<nacc> slangasek: Pharaoh_Atem: found one way to force the dependency between the php modules; looking into how that's properly meant to be done
<nacc> slangasek: Pharaoh_Atem to fix pecl-http
<doko> jamespage, nacc: promoted
<nacc> doko: thanks!
<mwhudson> why does golang-1.6 appear to be in trusty updates *and* proposed on https://launchpad.net/ubuntu/+source/golang-1.6 ?
<nacc> Pharaoh_Atem: would you be able to see if remi/fc have the same level of php-pecl-http and/or the same issue?
<nacc> slangasek: you're probably right, and seems like maybe you did the same for lasso? except that php-dev pulls in implicit build-deps :/
<nacc> i'm realizing that now
<nacc> slangasek: i think both lasso and libpuzzle need autoconf
<nacc> slangasek: do you want updated debdiffs or will you fix locally?
<slangasek> nacc: hmm I've already uploaded and moved on so please shoot me a fresh debdiff
<nacc> slangasek: will do
<nacc> slangasek: and nm, libpuzzle already explicitly pulled in dh-autoreconf, so only lasso needs a fix
<slangasek> nacc: yep, I see the lasso FTBFS mails streaming in
<nacc> slangasek: yeah :)
<nacc> slangasek: incr. debdiff posted to LP: #1566404
<ubottu> Launchpad bug 1566404 in lasso (Ubuntu) "PHP bindings only support PHP5" [Undecided,New] https://launchpad.net/bugs/1566404
<Pharaoh_Atem> nacc: certainly
<nacc> Pharaoh_Atem: thanks! i'm really stumped but mostly because i don't know very well how to debug these modules; i'm still digging in the builds/sources, though
<Pharaoh_Atem> okay
<nacc> Pharaoh_Atem: slangasek: so i see that some extensions have a priorit= value in their configuration .ini. That helps with sorting them, I beleive (so, e.g., pdo.so is a priority=10, while pdo_*.so is a priority=20)
<nacc> Pharaoh_Atem: slangasek: for now, would you be ok with me doing the same with raphf/propro/pecl-http until i hear back from ondrej if there is a better solution/
<Pharaoh_Atem> nacc: that sounds reasonable
<slangasek> nacc: no objection here
<nacc> slangasek: Pharaoh_Atem: ok, thanks testing that now
<nacc> slangasek: so afaict, zeroc-ice will only support php7 with 3.7.x, which is yet to be released (and no release date provided that i can find), are you ok with me just removing the php-zeroc-ice package?
<nacc> slangasek: both we and debian are on 3.5.x fyi
<slangasek> nacc: I am perfectly ok with removing any of these packages, binary or source as appropriate, so long as their reverse-dependencies are handled in the process
<nacc> slangasek: ok, thanks, that will probably be easiest here
<nacc> slangasek: i think we'll need to drop spotweb, but not sure yet, but no revdeps
<nacc> squirrelmail is all in php, but i don't know if there is a php7 version
<nacc> Pharaoh_Atem: any idea?
<nacc> i've been searching w/o much luck
<nacc> woo that worked
<Pharaoh_Atem> nacc: I don't see anything of the sort, but I'm looking a bit more
<Pharaoh_Atem> nacc: it looks like there's no real drive to move to php7
<nacc> Pharaoh_Atem: for that pkg at elast, upstream was more focused ohn supporting the oldest phps
#ubuntu-devel 2016-04-06
<smoser> pitti, i tried 'adt-buildvm-ubuntu-cloud -vv' and ended in a hang/timeout with a prompt about keyboard configuration.  i'm trying http://paste.ubuntu.com/15639799/ as a fix.
<nacc> Pharaoh_Atem: well, it works, so there's that
<nacc> slangasek: so, i think, at this point, all packages that are on your list either have pending sponsorships, FFe upgrades, or are going to be left broken
<nacc> slangasek: pad is updated with my current notes
<nacc> jgrimm: --^ FYI
<nacc> jgrimm: pad is at http://pad.ubuntu.com/8eABivrkBv
<smoser> pitti, the paste there fixed the issue for me.  the fix is really in the DEBIAN_FRONTEND=non-interactive.  theres a large performance increase in only running a single 'apt-get purge' command rather than many of them.
<nacc> slangasek: Pharaoh_Atem: debian's fix turns out to be identical to what i am suggesting, as ondrej is just picking up my chagnes :)
<slangasek> well there you go
<Unit193> BenC: Congrats.
<BenC> Thanks
<slangasek> nacc: btw php-radius is stuck in -proposed because php-common needed its versioned breaks: adjusted; I did that and reuploaded php-defaults, it has a bunch of autopkgtest regressions that are almost certainly false-positives, but can you help me sort through those and confirm which ones I should retry?
<nacc> slangasek: i think all of the php-defaults ones were due to the php-pecl-http breakage
<nacc> slangasek: let me go through and verify right now
<nacc> slangasek: so only 3 are "real" -- php-monolog, php-email-validator and php-horde-icalendar; the last is an internal timeout in autopkgtest
<nacc> looking at the first two
<slangasek> nacc: thanks, throwing the others back
<nacc> slangasek: hrm, i cna reproduce those two failures here, will need to investigate first thing in the AM
<BenC> * Laney to start an onboarding page for new dmb members (15:11)
<BenC>   ACTION: laney stop slacking and write onboarding page
<BenC> Answers one of my questions :)
<xnox> BenC, you should join #ubuntu-dmb and chat there about dmb private stuff ;-)
<xnox> BenC, congrats btw
<BenC> That was not on the wikiâ¦I hope someone gets that onboarding doenâ¦thanks
<aatish910> How are the official ISO images generated? Both me and tsimonq2 want to know
<tsimonq2> specifically Desktop
<slangasek> nacc: ok, I believe I have everything uploaded now, and the only things left are autopkgtests, mysql-5.7 blockage, and package removals
<slangasek> aatish910, tsimonq2: lp:ubuntu-cdimage, which dispatches to launchpad to run the build scripts from the livecd-rootfs package
<tsimonq2> slangasek: thank you :)
<aatish910> Uncompressed "Packages" is not available in http://archive.ubuntu.com/ubuntu/dists/trusty/universe/binary-amd64/ but it is listed in http://archive.ubuntu.com/ubuntu/dists/trusty/Release
<infinity> aatish910: That's a feature, not a bug.
<infinity> (And has been like that for, well, ever)
<aatish910> I was getting Hash sum mismatch on clean Xubuntu 14.04 install, and found that bzip2 version of "Packages" caused that problem. I then switched to "gz" with Acquire::CompressionTypes::Order::=gz and the problem is gone.
<infinity> The compression method doesn't relate to your mismatches, timing does.
<aatish910> Timing?
<infinity> Unless you have a transparent proxy between you and the archive that had an old version of Packages.bz2, but no copy of Packages.gz
<infinity> Timing.  You can download the old Release and then the new Packages, and they mismatch.  Or if your mirror isn't a two-stage mirror, there can be a loooong period where Release and Packages don't match.
<aatish910> I was using the main mirror.
<infinity> This is all being fixed with fancy new by-hash indexing, which is almost landed.
<sarnold> infinity: oh please oh please tell me it'll land before xenial.
<infinity> Anyhow, just saying that "switching to gz fixed it" was bad science.
<sarnold> infinity: .. and will the by-hash indexing also fix the translations?
<infinity> sarnold: There's a prototype on dogfood, Colin's plan is certainly to land it for xenial.  That said, even if he doesn't, we can retrofit xenial with it and the client will DTRT.
<sarnold> infinity: yay :D
<infinity> (Well, and it's not actually important for the release pocket post-release anyway, since it doesn't change, so landing it post-xenial for just updates/security/proposed/backports would also be fine)
<aatish910> I downloaded the bz2 version using wget - got md5sum af89c33be26ac1e6a58158a3a2c00a64, but md5 listed in Release is 39929667be5295b337096d56a22ff00d
<infinity> aatish910: Which file?
<aatish910> infinity, http://archive.ubuntu.com/ubuntu/dists/trusty/universe/binary-amd64/Packages.bz2
<infinity> $ md5sum Packages.bz2
<infinity> 39929667be5295b337096d56a22ff00d  Packages.bz2
<infinity> aatish910: I'd suggest you have a transparent proxy between you and the archive.
<infinity> And it's busted.
<aatish910> infinity, Thanks, I am going to call my ISP.
<sarnold> try the two tests here too http://www.lagado.com/proxy-test
<aatish910> sarnold, Yup, the second test revealed the proxy
<sarnold> neat, nice to know it works :)
<infinity> Oh, if that test worked, it's not even a transparent proxy.
<sarnold> this one aims for the more-transparent of the proxies http://www.lagado.com/tools/cache-test
<infinity> Oh, I missed that little link.
<infinity> Who else misses the world before CSS when every href was blue?
 * infinity raises hand.
 * sarnold raises hand
<infinity> Oh.  The best part there is that there's ARE blue, but black for :visited.
<infinity> And I'd apparently been there before. :P
<sarnold> I also miss the grey background
<infinity> s/there's/theirs/
<sarnold> hah
<aatish910> How do you raise the hand? :)
<sarnold> aatish910: /me raises hand
 * aatish910 raises hand
<aatish910> Is "Acquire::BrokenProxy=True" right for my scenario?
<sarnold> I don't see any mention of "brokenproxy" in my apt.conf
<mwhudson> heh i just hit that but the proxy was my own
<mwhudson> which stick do i hit squid-deb-proxy with to get it out of that situation?
<cpaelzer> good morning
<pitti> Good morning
<pitti> smoser: confirming the hang, I fixed the a-b-u-c yesterday; just syncing it into xenial
<seb128> hey pitti!
<pitti> smoser: I more or less have the same fix (DEBIAN_FRONTEND=noninteractive) and also dropped the purging of xkb-data
<pitti> hey seb128, wie gehts?
<seb128> pitti, gut, danke! und dir?
<pitti> seb128: good as well, just slept too long
<seb128> there is no such thing
<pitti> doko: sorry for some libhunspell collisions last night
<pitti> doko: so I suppose we can sync hunspell now, this should fix the FTBFS; aside from our transitional -v5 package the other ubuntu changes are in Debian
<pitti> doko: ah, you merged already; note that Debian already has M-A: same, you just moved it two lines down :)
<pitti> doko: is it possible to retry something on http://people.ubuntuwire.org/~wgrant/rebuild-ftbfs-test/test-rebuild-20160401-xenial.html ? I tried dutch and gnupg-doc locally last night, and they build fine
<wgrant> pitti: Done.
<pitti> ah, thanks
<tjaalton> doko: mesa is now in depwait, is libva good to move?
<pitti> tjaalton: looks ok, promoting
<tjaalton> thanks!
<tjaalton> oh and it's build-dep too libset-scalar-perl
<tjaalton> this is bug 1558820 btw
<ubottu> bug 1558820 in libva (Ubuntu) "[MIR] libva" [Wishlist,Fix released] https://launchpad.net/bugs/1558820
<pitti> yes, sure, see bug 1558820
<pitti> tjaalton: I don't promote stuff without looking for an MIR :)
<tjaalton> noted :)
<tjaalton> pitti: will mesa try again on it's own, or should I kick the builds at some point?
<pitti> tjaalton: it will retry by itself; it just takes a while for the publisher to pick up the promotion
<tjaalton> right
<pitti> give it another 30 mins or so
<tjaalton> sure thing, I remember ppa's need to be manually triggered, at least in the past
<darkxst> what happened to the casper branch? where is it hiding these days
<pitti> apt-get source it is, I guess
<infinity> lp:casper is only 6 years out of date. ;)
<cjwatson> tjaalton: dep-waits have never needed to be manually triggered, but some build-dep installation failures can't be turned into dep-waits.  It's not about PPAs vs. primary archive.
<cjwatson> darkxst: lp:ubuntu/casper I believe
<infinity> cjwatson: No exist.
<cjwatson> Ah, could be
<darkxst> cjwatson, that is what I though, but no
<infinity> pull-lp-source :P
<cjwatson> We should maybe grab lp:ubuntu/wily/casper and shove it back to lp:casper
<cjwatson> Or gitify it
<darkxst> I'll just debdiff it for now ;)
<tjaalton> cjwatson: ok, bad memory then
<darkxst> cjwatson, infinity, casper one-liner http://pastebin.com/5TiiguNS
<infinity> darkxst: Hrm.  Curious.  So does that mean one can't have a passwordless user on an installed system?
<infinity> Not that I'd recommend anyone running passwordless, but that seems like a regression.
<darkxst> infinity, normal user will be User1000
<darkxst> its not possible for a user to create a uid of 999
<darkxst> and besides the casper scripts only run on the live session
<infinity> darkxst: No, that's my point.  This fixes the live session to allow passwordless login, but I assume it means after install, one can't have a passwordless user, if they're so insanely inclined?
<infinity> Well, other than setting that unintuitive key. :P
<darkxst> GNOME won't allow setting a blank password
<darkxst> so they would have to user passwd or something
<infinity> But the system sure does, so one can create the user without the help of GNOME tools.
<infinity> Anyhow, one bug at a time; happy to sponsor the casper workaround.
<darkxst> infinity, right, and gdm doesnt use the nopasswd group like lightdm
<darkxst> although I am not sure that is much of a better solution
<infinity> darkxst: Err, wait.  I would be happy to sponsor this, except are you sure it works? :P
<infinity> darkxst: Pretty sure you're missing a chroot in there.
<darkxst> infinity, I can't test it, because I can't login after I have updated casper
<infinity> darkxst: Boot with break=casper-bottom and then run your bits manually from the initramfs prompt, then exit.
<infinity> darkxst: It almost certainly needs a "chroot root/" at the very least.
<infinity> chroot /root even.
<infinity> darkxst: I'm going to go see if anyone sells coffee at 4am.  Lemme know if you've been able to manually test from the initramfs.
 * infinity wanders off.
<Saviq> pitti, hey, when you have some time to spare, I'd like to pick your brainz on something wrt. running autopkgtests over adb :)
<ginggs> Unit193: LP: #1406825 has been fixed 5.34-2 in Debian, do you want to update your merge?
<ubottu> Launchpad bug 1406825 in xscreensaver (Ubuntu) "xscreensaver complains "This version of xscreensaver is VERY OLD!"" [Medium,Confirmed] https://launchpad.net/bugs/1406825
<darkxst> infinity, oh there is no dbus apparently
<infinity> darkxst: Well, that also makes some sense, being that you're in the initrd still.
<infinity> darkxst: Perhaps scripts/casper-bottom/32disable_hibernation might give some hints?
<infinity> The only occurrence of the string "freedesktop", was a grep in the dark. :P
<infinity> darkxst: Alternately, if it must be done with dbus instead of a config snippet, there's prior art at the end of scripts/casper-bottom/19keyboard
<darkxst> I tried that, dbus-launch gdbus call ... and it also failed
<darkxst> will try config snippet
<infinity> config snippet is at least more comfortably testable once booted.
<infinity> Since you can login on a tty and mangle it, and then restart gdm.
<infinity> If you can come up with a config bit to drop in place, that's probably the simplest.
<darkxst> not to mention I somehow lost my ability to type in the init shell ;(
<darkxst> well short of mashing each key 10 times
<darkxst> infinity, I don't quite see how polkit actions correlate to dbus properties
<darkxst> its seem to be more about access to dbus etc?
<infinity> darkxst: Well, fair.  Was just figuring there might be some generit config snippet way to abuse other bits on boot.
<infinity> dbus is very not my area of expertise.
<darkxst> like that snippit from before just says, no you can;t call that method
 * infinity experiments.
<doko> seb128, please could you have a look at the libspectre ftbfs? http://people.ubuntuwire.org/~wgrant/rebuild-ftbfs-test/test-rebuild-20160401-xenial.html
<seb128> doko, k
<seb128> doko, likely need https://cgit.freedesktop.org/libspectre/commit/?id=34a52f30400aab1c21c69c31122d496751d7d99e
<infinity> darkxst: So, I'm thinking you might want to stuff a systemd service in that launches with gdm and pokes dbus then, or something gross like that.
<darkxst> infinity, I was just thinking exactly the same thing
<infinity> darkxst: Not only is dbus intentionally unconfigured on the squashfs (which one can hack around early, and I did), then it still fails to love me for other reasons.
<infinity> darkxst: Pretty sure that call in 19keyboard, if ever reached, doesn't work. :P
<darkxst> accountsservice has code to set the PasswordMode flags, but not sure if they are trigger by the low level tools at all, and certainly not before the daemon is running!
<doko> jamespage, python-oslo.service is dep-wait
<infinity> darkxst: Right, so you probably want to inject a service that starts After=gdm.service (or gdm3 or whatever it is), and just does the poking then, and Bob's your ungle.
<infinity> Or uncle.
<infinity> darkxst: A oneshot service, obviously.
<darkxst> infinity, actually Bob is my uncle :P
<darkxst> yes of course
<infinity> Hah.
<infinity> Growing up in a part of the world without that idiom, it confused me to no end when I first heard it.
<infinity> And now I seem to be infected.
<darkxst> its pretty common around here, but always seemed strange when its just a real fact
<pitti> Saviq: what's up?
<jamespage> coreycb,^^ re oslo.policy
<darkxst> infinity, anywill I will play with a systemd service, but in the meantime would be good to get bug 1565177 landed
<ubottu> bug 1565177 in ubuntu-release-upgrader (Ubuntu) "screensaver is not disabled during release upgrade" [High,In progress] https://launchpad.net/bugs/1565177
<darkxst> that causes some nasty side-effects if the screenlocks!
<pitti> rbasak: http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#mysql-5.7 now holds up a sizable number of packages in -proposed, as we build everything against the new library now; dbconfig-common is still failing even after the previous patch, and its own tests are now failing too
<pitti> rbasak: not sure if you are already aware, as we don't have email notifications on test regressions, so relaying on IRC :0
<pitti> and it seems ruby-mysql needs adjustment too ("Access denied for user 'root'@'localhost'
<rbasak> pitti: thanks. We're aware. Skuggen and I are working on it.
<pitti> rbasak: great, thanks
<pitti> yofel: http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#baloo-kf5 has been stuck on the 32 bit regression for a month now; should we pull this from -proposed?
<yofel> pitti: I'm not sure what to do there, maybe... when I asked upstream what they're proposal is the response was "we don't support 32bit, over"
<pitti> oh, wow
<pitti> I thought ARM was a target for KDE
<yofel> maybe they simply didn't care about the tests, but it's not like this would work in real work conditions... and I don't think we have 32bit testers in our team either
<yofel> OTOH, I'll ask around if someone can test the old baloo and see how that works. Most people run the 64bit build from our PPA
<pitti> there's the theoretical option of removing the binaries from i386 and armhf, but it has a sizable chunk of reverse dependencies
<Skuggen> pitti: The dbconfig failure now seems to be a dependency issue
<Skuggen> pitti: I've fixed ruby-mysql2, actually
<infinity> yofel: "We don't support 32-bit" is a pretty crazy stance for an upstream.  The bug is probably trivial too.
<pitti> Skuggen: oh, https://launchpad.net/ubuntu/+source/ruby-mysql2/0.4.3-2build2 ? (it fails to build)
<yofel> infinity: well yeah, but I couldn't get anyone to help me figure it out, and I don't have enough time myself to troubleshoot C++ code :(
<Skuggen> pitti: No, I only uploaded it to the test ppa we're using, so far
<pitti> Skuggen: ah, ok; great to hear that there's progress, thanks
<infinity> yofel: Is there a bug filed, perhaps with (hopefully) a gdb backtrace?
<Skuggen> pitti: It needs an --insecure to the mysql_db_install command
<infinity> yofel: It'll probably jump out as someone doing a long->int conversion somewhere and chopping off half, or something similar.  Might even jump out in compiler warnings in the build log.
<yofel> bug not sure, but I do have a gdb backtrace somewhere. I'll gather that later
<infinity> And "we don't support 32-bit" is a poor excuse for writing bad C, if it's that sort of bug. :P
<infinity> s/C/C++/ but same thing in this case.
<pitti> oh, it seems the previous version didn't even run the test suite as part of the autopkgtest
<pitti> so it might not actually be a regression, but just expose the 32 bit crash now as we actually run the tests now
<infinity> pitti: It's possible.  If that can be confirmed, I'm happy with a badtest on it for now.  But it's clearly also shoddy code and a real bug.
<infinity> I'm also wondering how badly one needs to screw up to segv while moving a file...
<infinity> That should be, like, two lines.
<yofel> IIRC the crash came from the DB initialization or something like that
<infinity> yofel: But every other test passes.  So, that's a bit fishy.  Unless it's the test itself passing shoddy data, and the backend is fine.
<yofel> I still had gdb open on my raspi: http://paste.ubuntu.com/15645578/
<yofel> I can try the old version later and see if that crashes the same
<infinity> Not guaranteed to be the issue, but...
<infinity> In file included from ../../../src/engine/transaction.cpp:38:0:
<infinity> ../../../src/engine/idutils.h: In function âquint64 Baloo::devIdAndInodeToId(quint32, quint32)â:
<infinity> ../../../src/engine/idutils.h:37:44: warning: cast from âquint32* {aka unsigned int*}â to âquint64* {aka long long unsigned int*}â increases required alignment of target type [-Wcast-align]
<infinity>      return *(reinterpret_cast<quint64*>(arr));
<infinity>                                             ^
<infinity> ../../../src/engine/idutils.h:37:45: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing]
<infinity>      return *(reinterpret_cast<quint64*>(arr));
<infinity>                                              ^
<infinity> That looks preeeeeeetty suspicious.
<yofel> pitti, infinity: baloo-kf5 5.15 fails the same, so feel free to badtest it
<infinity> pitti: Be my guest, I'm still injecting enough caffeine to understand how keyboards work.
<Skuggen> Hehe
<Skuggen> I feel like I've been banging my head on these packages for a full day already :|
<Skuggen> well, many many days, really
<zyga> jdstrand: hey, I'm adding a flag to all interfaces that indicates if it should auto-connect
<zyga> jdstrand: I'd love a review of that when you have a moment
<jdstrand> zyga: sure thing
<jdstrand> just point me at it
<zyga> jdstrand: currently nothing auto conncets
<zyga> *connects
<zyga> I was wondering if I should do a quick pass for likely candidates
<infinity> @pilot in
* udevbot_ changed the topic of #ubuntu-devel to: Wily (15.10) Released! | Archive: beta freeze | Devel of Ubuntu (not support or app devel) | build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of precise-wily | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: infinity
<jdstrand> zyga: well, that depends on the autoconnect policy and how assertions play into. prior to 16.04, we would autoconnect everything and let the store (review tools) flag on dangerous stuff
<jdstrand> I don't have the larger picture of how autoconnect is supposed to work
<jdstrand> in 16.04
<flexiondotorg> infinity, seb128 If you have the time I have a couple of small sponsoring requests I really like to get integrated.
<flexiondotorg> https://bugs.launchpad.net/ubuntu/+source/ubuntu-mate-artwork/+bug/1563971
<ubottu> Launchpad bug 1563971 in ubuntu-mate-artwork (Ubuntu) "ubuntu-mate-artwork 16.04.6 bug fix release [debdiff attached]" [Undecided,New]
<zyga> jdstrand: I'd be conservative now, we can always be more lenient later
<zyga> jdstrand: I'd do network and network-bind
<zyga> jdstrand: and perhaps nothing else for now
<flexiondotorg> IN fact, it is just that one for now.
<jdstrand> zyga: I agree
<jdstrand> the other things give privileges access
<jdstrand> privileged*
<zyga> jdstrand: cool, I'll open the pull request shortly
<jdstrand> zyga: what happens if a snap plugs say firewall-control and you install it? ie, it isn't autoconnected
<zyga> it isn't auto-connected
<jdstrand> heh
<jdstrand> I get that
<zyga> I think we'll auto connect that when assertions are in place
<zyga> (that was hard to parse)
<jdstrand> I mean, what is the UX
<zyga> ahh
<zyga> well, nothing happens
<zyga> the UX is poorish now
<jdstrand> the user just has to know to connect it? or is there some sort of feedback?
<zyga> with auto-connect nothing happens either
<zyga> there's none right now (install still hasn't landed)
<zyga> but there are ideas on how to do that
<zyga> it's just so so post 16.04
<jdstrand> I see
<infinity> flexiondotorg: On it.
<zyga> we have ways to push messages (websocket); currently (AFAIR) we poll; the bigger issue is that there's no UX design yet
<flexiondotorg> infinity, Cheers.
<flexiondotorg> infinity, Just preparing what should be that last one.
<flexiondotorg> Ubuntu MATE Welcome fixes and new translations.
 * zyga realized this is the wrong channel
<infinity> flexiondotorg: You might want to switch ubuntu-mate-artwork from native to non-native so you can stuff all those massive images in an orig.
 * infinity says, uploading a 67MB package.
<flexiondotorg> infinity, OK. Can that be a 16.10 thing?
<infinity> flexiondotorg: Sure.  Well, this also assumes you change non-image bits more often than the images.
<infinity> flexiondotorg: If both change a lot, you won't get much of a win from breaking it apart.  *shrug*
<infinity> flexiondotorg: I have 10Mb up, I'm just being whiney. :P
<flexiondotorg> infinity, I have 4Mb up ;-)
<flexiondotorg> Added to the work sheet for 16.10.
<infinity> flexiondotorg: Like I said, it only makes sense if the text/theme bits change more often than the images (or if there are translations in there you update regularly, etc)
<infinity> flexiondotorg: If you're constantly replacing images, you kinda lose, and the current format works fine.
<flexiondotorg> Generally we do all the image and theme changes together.
<flexiondotorg> Then you get a few theme only fixes toward the end of the cycle.
<infinity> flexiondotorg: Yeah, so ignore me.  The current format works, I'll just complain less.
<flexiondotorg> infinity, I do appreciate all the feedback. I want to learn best practice.
<pitti> yofel, infinity: hinted
<yofel> thanks
<infinity> pitti: Do you have context on the weird gcc-5-cross-ports madness in excuses?
<infinity> pitti: Or, rather, the lack of it in excuses.
<pitti> infinity: this one? http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#gcc-defaults-ports
<Saviq> pitti, actually I think I managed - the default pinning on touch devices made it so adt did not pick up the newer packages in the PPA - I'm checking now whether that's the case (unless you can already tell me otherwise - I didn't know pinning affects how adt selects the source package to test)
<pitti> infinity: no, doesn't tell me anything
<infinity> pitti: No, the thing it depends on.  That isn't there.
<infinity> pitti: gcc-5-cross-ports is in -proposed, and britney knows enough to know that gcc-defaults-ports depends on it, but... It's not there.
<infinity> pitti: Which is a bit 'wat'.
<pitti> infinity: I don't understand -- there simply is no binary gcc-5-cross-ports
<infinity> pitti: No.  It's a source package.
<pitti> i. e. I suppose that's a wrong dependency in the new gcc-defaults-ports or so
<infinity> pitti: Which isn't in excuses.
<infinity> pitti: Despite being in proposed.
<pitti> not according to rmadison
<doko> pitti: but which one would that be?
<pitti> $ rmadison gcc-5-cross-ports
<pitti>  gcc-5-cross-ports | 7ubuntu3 | xenial/universe | source
 * infinity blinks.
<infinity> https://launchpad.net/ubuntu/+source/gcc-5-cross-ports/7ubuntu4
<infinity> Okay, I can copy it over itself to fix that, but before I do, I think this needs an LP person to examine WTF.
<pitti> yeah, it seems it never got published
<infinity> cjwatson: Yo, LP person.
<infinity> https://launchpad.net/ubuntu/+source/gcc-5-cross-ports/7ubuntu4/+publishinghistory <-- WTF, iz not on disk.
<infinity> cjwatson: Assuming copying it over itself will "fix" it, but figured you might want the current state to persist long enough to cry a bit.
<pitti> doko: as britney says -- gcc-defaults-ports binary depends on gcc-5-cross-ports which doesn't exist
<doko> yeah, it's the unpublished package
<pitti> no, not really -- that binary isn't on https://launchpad.net/ubuntu/+source/gcc-5-cross-ports/7ubuntu4/+build/9385392 either
<pitti> i. e. that's not just a publishing problem
<doko> there is no gcc-5-cross-ports binary
<infinity> pitti: That binary dep also doesn't exist in the build.
<infinity> pitti: As in, I think britney's just super confused right now, due to the unpublished mess.
<pitti> yeah, apparently; I figure the "impossible dependency" thing is source based, as gcc-defaults-ports also does not exist as a binary
<infinity> ...
<infinity> All the binaries are published, but not the source?
<infinity> *head explodes*
 * infinity will give Colin an hour or so to respond and have a poke at it before he just fixes it.
<infinity> doko: Should clear up later today if that's the only issue (which I think it is).
<infinity> wgrant: If you're around, you might be interested.
<cjwatson> It's in pool but not dists, hmm
<cjwatson> 2016-04-06 12:10:17 INFO    a-f: E: DSC file '/srv/launchpad.net/ubuntu-archive/ubuntu/pool/universe/g/gcc-5-cross-ports/gcc-5-cross-ports_7ubuntu4.dsc' is too large!
<cjwatson> haha, go apt-ftparchive
<infinity> cjwatson: Which would imply either it's not ending up in the file list, or... Very broken a-f cache?
<infinity> Oh.
<infinity> WAT.
<infinity> Fixed buffer?
<cjwatson> too many binaries for a-f's little mind, I imagein
<cjwatson> *imagine
<infinity> At least it doesn't overflow it? :P
<doko> seb128, will you fix libspectre?
<infinity> mvo: Dude.
<cjwatson> So copying over itself is unlikely to help.
<infinity> cjwatson: Indeed.
<mvo> infinity: hm?
<infinity> cjwatson: Is that happening on every publisher run?
<seb128> doko, feel free to do it if you want, but otherwise yes, I've it on my list, just dealing with some other things I had started before
<doko> ta
<infinity> mvo: 2016-04-06 12:10:17 INFO    a-f: E: DSC file
<infinity> '/srv/launchpad.net/ubuntu-archive/ubuntu/pool/universe/g/gcc-5-cross-ports/gcc-5-cross-ports_7ubuntu4.dsc' is too large!
<cjwatson> infinity: Sure is.
<infinity> cjwatson: Kay, so a fixed apt will magically fix it.  That's something at least.
<infinity> mvo: We can haz fix for that? :P
<mvo> infinity: uh, I think so
<cjwatson> It's fixed in latest apt
<doko> cjwatson, could be, builds two more cross compilers than the same package in debian
<cjwatson> But I'm guessing not trusty's
<infinity> cjwatson: You already hunted down a fixed commit?
<pitti> wgrant, doko: hm, it seems the retry on dutch works, but gnupg-doc retry still FTBFS (without an useful error message in the log); I still can't reproduce in a local build
<cjwatson> 31be38d205406d4c756684e20b93d62c4701e091
<mvo> most (all?) fixed buffers got fixed in the recent months so happy to hear that this is not an issue in 16.04
<cjwatson> "128 KiB DSC files ought to be enough for everyone"
<infinity> Heh.
<cjwatson> Let's see if it backports easily
<mvo> the whole commit message is very nice indeed
<infinity> Right, if we can get a single-commit SRU, v-done it with a rollout to pepo, that would work for me.
<cjwatson> pepo's already running a patched backport, so I'm just going to patch it further for now
<cjwatson> (Yes, this isn't completely ideal, but until we get round to SRUing source caching ...)
<infinity> cjwatson: Oh, is it?  What are we missing in the archive?
<infinity> cjwatson: Oh, we never SRUed source caching?
<infinity> cjwatson: I guess we could just upgrade to xenial soon and never bother.
<infinity> mvo: Still probably worth SRUing that commit, I guess, for anyone running trusty's a-f against either doko's cross madness or the Debian linux package.
<infinity> mvo: But far less urgent if Colin's fixing it out of band for ftpmaster.
<cjwatson> We also have some array -> std::vector backports from 1.1~exp1
<cjwatson> But it is indeed all backports, nothing original
<infinity> cjwatson: I'm inclined to suggest that we just make pepo->xenial an upgrade priority.
<infinity> cjwatson: I mean, I'm all for real bugfixes (like this one) in trusty, but feature backports probably don't make sense this close to a new LTS.
<cjwatson> It'll be a policy argument.
<cjwatson> Because of the "newer than precise, you have to juju" rule.
<infinity> cjwatson: Surely, pepo has a free pass on the... That.
<cjwatson> Hasn't had to come up yet.
<infinity> cjwatson: Given it's basically the backbone of everything.
<cjwatson> (Also I'm not sure we've tried running LP code on xenial, and running LP spanning three LTSes is a bit exciting.)
<cjwatson> trusty with a direct backport of xenial's apt might be more feasible.
<infinity> Well, by "make a priority", I didn't mean "upgrade blindly and hope". ;)
<infinity> The last time we did that went so well.
<ogra_> if it is high-priority-hope ?
<infinity> cjwatson: Odd of landing that before EOD?  I'd like to tick this one off the WTF list.
<infinity> cjwatson: Though, I also really want the donkey model, so...
<cjwatson> infinity: EOD today is ambitious, but I'll get things moving and EOD tomorrow should be doable.
<infinity> cjwatson: Kay.  WFM.  It's been broken for ages, just want it off the list "soon".
<infinity> doko: Looks like you get fixed tomorrowish.
<cyphermox> awe: what's your fix for VPN? I wouldn't mind applying it here now ;)
<awe> did you seee the bug?
<awe> https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1552424/comments/20
<ubottu> Launchpad bug 1552424 in network-manager-vpnc (Ubuntu) "[FFE] NetworkManager 1.2-beta" [Undecided,Confirmed]
<seb128> awe, good work figuring it out!
<awe> cyphermox, I haven't been able to verify it yet
<awe> but pretty sure that's it
<seb128> cyphermox, awe, does it mean the packages would be good to go now if release was to give an ack?
<awe> no
<seb128> :-(
<awe> well... maybe
<awe> cyphermox's package is based on beta1
<awe> my package for the phone is based on beta2
<seb128> if it's not this week we can forget about it
<awe> and rc1 was released yesterday
<cyphermox> ahah oops
<awe> and...there's at least one crasher bug fixed in rc1
<seb128> how come cyphermox and you are working on different packages?
<awe> that I reported upstream
<seb128> looks like everybody should work on the xenial package atm to get that landed
<awe> because cyphermox stopped working on it, and I kept moving fwd and re-based last week on beta2
<seb128> we don't have a working touch/xenial atm so that can probably be rebased then?
<cyphermox> seb128: package version at that level is more or less irrelevant, as long as it's >=1.1.91
<awe> correct, no working touch xenial
<seb128> awe, I guess I don't understand why you two don't work on a common vcs
<seb128> rather than duplicating work
<seb128> or diverging
<cyphermox> awe: so that was my fault I thinko'd when I ported to setserversex, sorry
<awe> because (a) we forked from desktop due to lack of stability
<awe> and desktop kept moving fwd
<cyphermox> seb128: it's a branch I have where I did the work before merging to lp~network-manager/network-manager/ubuntu, which is the correct packaging branch
<awe> I started working in moving touch from 0.9.10x ( the vivid version ) to 1.2
<awe> an then cyphermox picked up on the same
<awe> but again... there are differences our 1.2 branches dues to xenial vs. vivid
<seb128> k, so basically the fork has bitten us
<awe> no, not really
<cyphermox> no, it has not
<cyphermox> what bit you is that I don't have the time to work as hard on NM
<awe> it kept touch somewhat stable... and we were really waiting for 1.2, as it re-wrote significant portions of the WiFi code
<seb128> right
<seb128> I guess I would have started by updating the xenial/desktop codebase to current beta
<seb128> before doing that for the phone as you did
<seb128> because if we don't land the desktop side now we don't do it at all
<seb128> oh well
<seb128> I guess that part is past and we all agree we should update cyphermox's vcs to rc1
<seb128> and land to xenial
<cyphermox> that's not entirely true -- we could do a xenial overlay
<awe> for what?
<awe> touch?
<seb128> for touch
<seb128> if xenial doesn't get 1.2
<awe> that's a bit premature
<cyphermox> for landing 1.2 to "xenial" and then land vivid
<cyphermox> right, if we can't upload to -release
<awe> as we don't know if the phone will be re-based on 16.04 or 16.10
<awe> ( if & when we upgrade )
<infinity> mvo: Every time I see a commit message or comment like that, I'm reminded of Will's rapid descent into madness in the comments of: https://git.collabora.com/cgit/user/sjoerd/wocky.git/commit/?id=f6f96522cc9ff0e7541f6087f254e62900454fbf
<awe> I'm still of the opinion that desktop 16.04 should get nm1.2 either prior to release, or post release as a SRU
<flexiondotorg> infinity, If you are able this would be a big help for the Ubuntu MATE team - https://bugs.launchpad.net/ubuntu/+source/ubuntu-mate-welcome/+bug/1566837
<ubottu> Launchpad bug 1566837 in ubuntu-mate-welcome (Ubuntu) "ubuntu-mate-welcome 16.04.7 bug fix and translations [dsc attached]" [Undecided,New]
<cyphermox> awe: it's not that simple
<awe> well.. then we end up with an LTS with an older version of NM
<awe> if everyone's fine with that
<awe> so be it
<awe> touch *is* moving to 1.2, as we're continually battling problems WiFi with 0.9.10, and 1.0x doesn't help us
<cyphermox> as I mentioned, just convince the release team that that upload is bug-free ;)
<infinity> cyphermox: No upload of NM is ever bug-free.
<infinity> cyphermox: So, it's more about trading bug we know for bugs we don't.
<cyphermox> ok, reasonably looking like the bugs aren't terrifying
<infinity> flexiondotorg: Are all these -welcome changes tested?  It's a pretty unreviewable diff.
<flexiondotorg> They are extremely well tested.
<cyphermox> awe: I'm testing your patch as soon as it's done building
<flexiondotorg> And we are highly motivated to ensure Welcome works properly.
<barry> uh oh.  with today's dist-ugprade, has alt-backtick broken for anybody else?
<infinity> barry: WFM, but I haven't logged out in a while.
<awe> cyphermox, k
<seb128> cyphermox, do you have any slot to update your branchs/ppa to rc1? or do we need somebody to help with that?
<seb128> cyphermox, did you mention to slangasek that this update was kind of important and that it would be nice if other could maybe help
<barry> infinity: yeah, i just dist-upgraded and rebooted.  looks like a regression.  i'll dig in a bit
<cyphermox> it's quick enough, I'll bump the version and see if things still build
<awe> seb128, as mentioned, I can problem prepare a branch after I finish with the touch update
<awe> unless cyphermox can do so
<cyphermox> seb128: I mentioned I didn't know if the desktop team felt it was critical to land in xenial
<seb128> e.g Åukasz worked on some of the updates in the cycle
<cyphermox> to me it seems like we pretty well missed the deadline.
<cyphermox> (since as infinity mentioned, no NM upload is ever bug-free)
<infinity> With two weeks until release, I'd need a pretty solid commitment from the desktop team to clean up any regressions found very, very quickly.
<cyphermox> awe: it would help me a whole lot if you could (or anyone really) take the packages currently in my PPA or buildable from the code branch and see if autopkgtest is happy with them
<infinity> And words are cheap. :P
<awe> cyphermox, I have to admit, I don't know how to do that
<awe> that said, I will volunteer to create an updated branch for rc1
<awe> and do that before I update the touch branch
<awe> cool with you?
<seb128> bah, that all sucks
<seb128> I though it was handled when cyphermox files the ffe a month earlier
<seb128> that's why we didn't look at it more
<seb128> it would be a real shame to not have the update in the LTS
<cyphermox> awe: http://packaging.ubuntu.com/html/auto-pkg-test.html
<awe> lI still fail to see why this couldn't be SRU'd with proper testing vs. trying to rush this now
<smoser> pitti, have you seen issues adt-run and adt-virt-qemu on amd (non-intel amd64)
<infinity> SRUing new versions is even more dangerous than shoving them in at the last minute.
<infinity> Because NM is notorious for changing behaviour.
<smoser> last night i ran and it complained that kvm was not available (i assume in a nested guest).
<infinity> And users like the (mis)features they know to keep working (or not) the same way.
<seb128> awe, you can't mess up SRUs, you have customers/real world business depending on things to be stable
<seb128> better to get a bug in release and fix it in a SRU
<seb128> than creating it in a SRU
<pitti> smoser: I'm not aware of any, no; what do you see?
<smoser> well, just that. i dont have the log, but i'm running again and will collect it.  from memory, it was kvm module i think. i'll get the log.
<xnox> smoser, adt-run by default doesn't cause nested kvm... and i'm not sure if nested accelerated kvm is supported on amd.
<smoser> xnox, nested accelerated kvm is supported on amd (and was years before that landed in intel)
<infinity> seb128: If you can hunt down people willing to take ownership (including their management chain signing off on them spending the time to *actually* take ownership), I'm not completely against a late update of NM.  But of all our upstreams, they're one of the worst for introducing more bugs than they fix.
<xnox> cool
<seb128> infinity, btw, n-m is maintained by foundations (cyphermox) afaik?
<smoser> hm.. adt-run doesn't by default cause nested kvm.
<pitti> xnox: ubuntu's qemu packages enable nested kvm by default
<smoser> ok, then its probably not nested that did it :)
<infinity> seb128: Not sure who actually owns it.  Maybe us.  But we're not the ones asking for the update. :P
<pitti> xnox: and recent autopkgtest also enables it for Debian's qemu
<xnox> seb128, hehehe who is no longer in ue/devices =)
<pitti> smoser: ^
<smoser> currently running: adt-run -dd --apt-upgrade --built-binaries --unbuilt-tree open-iscsi/ -o /home/ubuntu/tmp/adt-tmp/ --- adt-virt-qemu --ram-size=2048 -d adt-xenial-amd64-cloud.img
<seb128> infinity, well, cyphermox filed the ffe :p but yeah, in any case if we can update I would be happy for desktop to help tracking issues/getting them resolved as a priority
<smoser> from matsubara's open-iscsi  branch.
<pitti> smoser: btw, matsubara is working on the nested open-iscsi tests, he just asked me to re-run the test from git
<pitti> smoser: ah, you're aware of that, good
<seb128> cyphermox, are you swamped with other work or could you handle updating to rc1 and landing the update if the ffe is acked?
<pitti> smoser: http://autopkgtest.ubuntu.com/running.shtml#pkg-open-iscsi has running tests from matsubara's git
<cyphermox> seb128: it's maintained by me only because I was the last to touch it, it's not something that would normally be under foundations.
<seb128> slangasek, ^ can we cyphermox to get some slots to get the n-m update in the lts?
<cyphermox> seb128: and I care enough about it to do updates when I can
<seb128> cyphermox, why not? it's infra
<cyphermox> because it's infra only used by desktop :)
<awe> and touch, and snappy
<infinity> If nm-cli had ever become a useful thing, maybe it would be for everyone.
<seb128> well, anyway, no point to argue over ownership
<infinity> seb128: I was literally just typing that.
<smoser> ok. pitti so this is probably luser error, but what is going wrong here: http://paste.ubuntu.com/15650198/
<seb128> cyphermox, you have the most context on the package and the update at this point
<seb128> so it would be easier if you could help pushing that through
<seb128> we can help on bugfixing and look at taking over it/be more involved then
<infinity> seb128: I know cyphermox is pretty busy from now until release, but you might talk Steve into letting him take a day to clean up NM if your team trades resources to give it love post-upload.
<pitti> smoser: ah, one of my most favourite zombie bugs, bug 1384706
<ubottu> bug 1384706 in autopkgtest (Ubuntu) "tar: Unexpected EOF in archive in copyup()" [Medium,Triaged] https://launchpad.net/bugs/1384706
<seb128> we are just not going to learn the codebase over night
<awe> seb128, again... I'm willing to do the branch update today
<pitti> smoser: I can't get this on my machine, and so far I didn't get ssh to a machine where this happens
<awe> but I may need some help
<pitti> smoser: usually it helps to just retry
<seb128> awe, that would be most useful, thanks ;-)
<awe> I already have touch 1.2-beta2 prep'd and was planning on re-basing on rc1 today
<seb128> awe, right, which is why I'm trying to see if cyphermox can give an hand there
<awe> with the dnsmasq fix
<pitti> smoser: but if you can reproduce this reliably, ssh for me to investigate would be highly appreciated; supposedly some weird bug in qemu's 9p file system
<awe> ( which still needs verification; which cypher is working on )
<seb128> infinity, right , I assumed so, as said we would be happy to pay back the favor by helping with issues due to the update/SRU and other things
<smoser> pitti, sure. if it fails again i'll let you in.
<smoser> one thing possibly related was i was | tee out.log
<smoser> ie, possibly some buffer got in the way or something
<pitti> smoser: maybe; but with -l out.log it's not entirely different
<pitti> or -o
<pitti> smoser: but this is tar unpacking/packing files from a local (or testbed) tmp dir through the auxverb (9p file system in QEMU's case), so it shouldn't be related to the actual terminal
<smoser> xnox, bah. so adt *does* for this test cause nested kvm.
<smoser> duh. i should have realized that. thats how this test works. it runs kvm with iscsi root . where iscsi root is provided via tgt on host.
<xnox> =/
<pitti> right, that was the idea
<pitti> it downloads a cloud image, and boots that (in nested kvm) with open-scsi
<pitti> matsubara is currently working out some quirks to make that work in scalingstack
<pitti> as that runs trusty's qemu which works significantly worse with nested kvm than on xenial
<cyphermox> awe: your fix works, and the code was obviously correct but I spotted something else that is wrong -- it completely replaces nameservers, doesn't include the ones for other connections
<awe> cyphermox, ack; mind sending me the updated patch when you're done; I'm working on updating your branch for rc1
<smoser> pitti, can you confirm something for me?
<smoser> Restrictions: needs-root isolation-machine breaks-testbed
<smoser> is that causing each of the 'Tests:' to be run in its own clean environment ?
<pitti> smoser: the breaks-testbed is, yes
<smoser> is there a way to say that all these tets could run together (they dont break eachother) but they probably leave the system in a suspect state.
<pitti> smoser: you can only have the last test declare breaks-testbed, but not the others
<pitti> saves you the set up of new testbeds in between, indeed
<smoser> how do you do that ?
<pitti> Tests: a
<smoser> http://paste.ubuntu.com/15650640/
<pitti> Restrictions: i-m
<pitti> Tests: b
<smoser> ah. just multiple lines. that'd be much nicer.
<pitti> Restrictions: i-m, breaks-testbed
<smoser> as even as it is right now, *all* the tests are installing qemu-sytem
<smoser> but only one of them needs it
<smoser> :)
<pitti> smoser: if the tests have different test deps, arrange them in the order of "ascending" test deps
<smoser> yeah, perfect.
<smoser> thank you.
<pitti> smoser: if the current test in the list has any test dep that the next test does *not* have, then the next test will get a fresh testbed
<infinity> pitti: Is it spec that tests are always processed in control order, or just current implementation?
<pitti> whereas new test deps are just installed
<infinity> pitti: Cause if people rely on that, it should be specced.
<pitti> infinity: the intention is certainly that this is the order, and I'd consider it a bug if it's not
<infinity> (I certainly wouldn't expect order to matter)
<pitti> well, you can influence it externally of course with --testname
<smoser> pitti, so 'install' test.
<pitti> it doesn't matter from a functionality POV, but with arranging the tests in a certain order you can optimize the runtime
<infinity> Yeah.  It's lacking make-style recipe deps.
<smoser> *should* that 'breaks-testbed' ?
<smoser> as you'd really not want to re-use a system after installing some arbitrary package.
<pitti> smoser: well, from that POV all tests would be breaks-testbed
<pitti> arguably this is a fuzzy concept
<infinity> Well, no.
<pitti> it basically means "never try to run this on real iron
<infinity> Cause "test-deps" can be tracked by the implementation for removal.
<pitti> merely installing a package should not count as that
<infinity> Installing something in the test itself can't be tracked.
<infinity> So that breaks testbed.
<pitti> infinity: adt-run doesn't do removals
<smoser> infinity, yeah, and installation of packages and then removal could not possibly cause permenant issues :)
<infinity> pitti: No, but it could.  I'm talking spirit here, not implementation.
<smoser> even if you spelled permanent right.
<pitti> it just installs, and if the next test has fewer test deps, it starts over with a fresh testbed
<infinity> pitti: think old-skool sbuild, where we installed build-deps and removed at the end.  That's trackable and, in theory, assuming your packages don't suck, it reverts to a pristine state.  Nevermind that we stopped doing that precisely because packages *do* suck, the intent is still valid. :P
<smoser> for packages in archive, it might be a ideal that you could at least hope for.
<infinity> So, I'd say anything that fiddles with the root filesystem *in the test* breaks testbed.  While installing test-deps from control doesn't.
<infinity> smoser: piuparts does a pretty good job of testing this, but we don't run it against Ubuntu.  We really should.
<pitti> infinity: right, that's about the common practice
<smoser> but if you're testing paackages before they get into the archive (or me wanting to test someone elses suggestion) then thats different.
<pitti> or mucking around with grub etc.
<smoser> pitti, http://paste.ubuntu.com/15650781/
<smoser> that is how its failing for me on amd
<cyphermox> awe: scratch that, working as designed...
<infinity> I mean, Debian packages have a pretty good track record of removing cleanly.  But it's that 0.5% that ruin it for everyone. :P
<awe> cyphermox, cool
<pitti> smoser: in practice, our test infra doesn't have any permanent boxes, so this mostly just controls whether or not the testbed is reset for multiple Tests: within one pacakge
<barry> infinity: okay, it's a regression in xserver-common, xserver-xorg-core, or xvfb (probably not the latter)
<infinity> barry: All the same source package, so meh.
<cyphermox> awe: http://paste.ubuntu.com/15650846/
<barry> infinity: yep.  and oh, nice ubuntu-bug throws an AssertionError ;)
<infinity> barry: assert('I HATE YOU AND EVERYTHING YOU STAND FOR') seems to be the default mode for apport when I use it.
<barry> infinity: more like `assert i_like_you, "yeah i really don't"`
<infinity> pitti: Oh, that reminds me.  apport's "you have out of date packages, loser" check.  Is that literally just checking for *any* OOD packages?  Cause I've had it whine about things that clearly aren't deps or in any way related to the package I'm filing a bug on, which is irritating.
<awe> cyphermox, kthanks
<barry> infinity channels barry
<pitti> smoser: can you try adding "-cpu kvm64,+svm,+lahf_lm" to the qemu command line?
<pitti> oh wait, this is the outer qemu, not the inner one
<pitti> infinity: it only checks OOD packages in the transitive depends of the affected package
<smoser> well, the outer is trying to run a guest and its failing.
<pitti> right, see above
<infinity> pitti: Huh.  Maybe it's being a little too generous about what constitutes a meaningful dep, then.  I was trying to report a bug on something the other day that clearly wasn't linked to libnih and it had a sad because my libnih was OOD.
<pitti> the outer qemu already ought to have this
<pitti> Detected KVM capable AMD host CPU, enabling nested KVM
<infinity> pitti: But if it's using dpkg deps to determine that, I could see how that might happen.
<pitti> smoser: ^ this adds -cpu kvm64,+svm,+lahf_lm to the outer qemu command line, but apparently that doesn't work?
<pitti> i. e. no /dev/kvm in the outer QEMU
<smoser> right.
<barry> LP: #1566878
<ubottu> Launchpad bug 1566878 in xorg (Ubuntu) "Alt-backtick regression" [Undecided,New] https://launchpad.net/bugs/1566878
<smoser> so were you asking me to add '-cpu' ?
<smoser> because i dont know hwere. i think you were realizing that its not the test that is missing that.
<pitti> smoser: nowhere, I was confused and thought it'd need to go to the inner qemu-system that the test calls, but that's bogus
<smoser> right.
<pitti> smoser: so I guess we need to find the magic -cpu flag that makes /dev/kvm appear in qemu on your amd system
<matsubara> pitti, smoser: amd64 tests passed: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial-pitti-ppa/xenial/amd64/o/open-iscsi/20160406_135614@/log.gz but it seems i386 tests are stuck
<pitti> yeah, http://autopkgtest.ubuntu.com/running.shtml#pkg-open-iscsi
<infinity> barry: You can twiddle those package versions up and down and confirm that's the culprit?  That's a weird bug to blame on the xserver.
<smoser> pitti,  is there a reason you '-cpu <something>' at all ?
<barry> infinity: i did a bisect dist-upgrade with disk snapshots.  those are the only three left
<pitti> smoser: yeah, upstream's and Debian's qemu don't enable nested KVM by default, that's an ubuntu specific patch
<infinity> barry: And reupgrading them breaks it again?  Bizarre.
<barry> infinity: yep
<pitti> smoser: does it work if you drop this from virt-subproc/adt-virt-qemu?
<smoser> pitti, testing with '-cpu host'
<pitti> smoser: you can use --- qemu --qemu-options '-cpu host' as a local workaround, BTW (if that helps)
<pitti> an explicit -cpu option overrides the auto-detection
<smoser> ah. ok. i just hacked the file
<smoser> http://paste.ubuntu.com/15651151/
<smoser> ^-- does that make sense for the depends changs you suggested ?
<smoser> i guess you were saying we could also drop the 'breaks-testbed' for the first two Tests:
<pitti> smoser: I thought you wanted ... that, yes
<smoser> but since debian has the first two tests and it says 'breaks-testbed', i'd just leave those alone and live with it.
<pitti> smoser: no test depends at all for "install"?
<doko> barry: mako, paramiko and the py* ftbfs could need some love ...
<smoser> so we're just appending Tests
<smoser> that 'Depends' is from debian, pitti
<pitti> smoser: ah, it presumably calls apt-get install itself
<smoser> i'm guessing it only does apt-get install ?
<smoser> yeah
<barry> doko: i'll take a look
<pitti> which is a bit pointless, as the other tests test installation of "apt-get install open-isci" by way of making that a test dep
<pitti> but *shrug*
<pitti> smoser: yeah, looks ok; perhaps add some newlines before Tests: to make this a bit easier to read
<smoser> sure. ok.
<smoser> so specifically i guess the last does not depend on open-iscsi
<smoser> as it downloads it from the archive and puts in in the to-be-built guest.
<smoser> no need for it on the host.
<smoser> pitti, that did seem to work. (-cpu host)
<pitti> smoser: ok, good; so I need to get access to some amd machine to figure out how to make this work by default
<smoser> why wouldnt you just use -cpu host ?
<pitti> that makes test results harder to reproduce
<pitti> we have a fair number of tests which are rather hw specific, like mesa or llvm
<smoser> fair.
<infinity> pitti: Except that llvmpipe is broken specifically because of qemu's craptastic feature masking. :P
<pitti> and in scalingstack we also don't do that, but some -cpu SandyBridge option
<pitti> so in production CI we don't use the qemu runner, but let nova do the qemu setup
<infinity> pitti: We unbreak it by intentionally unmasking, so it's hard to say that '-cpu host' would make the situation worse.
<pitti> well, it's bad enough with intel vs. amd; using the host CPU introduces even more jitter
<infinity> (But I understand the urge for homogenous test environments)
<infinity> pitti: I'm all for masking in theory, I just hate that qemu sucks so hard at actually doing it.
<infinity> (To be fair, it's hard to do properly, since you have to trap and emulate a bunch of instructions to prevent the guest from divining features without looking at advertised flags)
<infinity> Thanks, Intel.
<matsubara> pitti, did you restart the test for i386?
<doko> barry, and gdebi needs a b-d on pyflakes3. saw that you are maintaining this in debian
<pitti> matsubara: no, I didn't; isn't that still the same hang as with the previous few attempts?
<barry> doko: pyflakes3, yes
<pitti> matsubara: oh, I figure it auto-restarted due to tmpfail
<matsubara> pitti, I thought so, but it looks like now that it went further...
<matsubara> oh, auto-restart
<pitti> wow, there's some serious mis-formatting on http://autopkgtest.ubuntu.com/running.shtml#pkg-open-iscsi ATM
<matsubara> pitti, indeed
 * pitti saves the HTML for later investigation
<matsubara> pitti, can you give me access to the testbed running the i386 test?
<smoser>  matsubara http://paste.ubuntu.com/15651617/
<smoser> that is my current diff against yours. re-works debian/tests/control for readability and hopefully to re-use a vm on testsuite
<smoser> and then also should (i hope) have the tgt-boot command log to the console so it will go right through to the adt captured log and we can see it there.
<GunnarHj> pitti: Did you see my ping at #ubuntu-deskop?
<pitti> GunnarHj: ah, missed that, will do (after my current meeting)
<GunnarHj> pitti: Ok.
<matsubara> smoser, re-running locally with your changes. Just pushed them to my branch
<smoser> http://paste.ubuntu.com/15652025/
<smoser> that is my latest. i added '--progress=dot:mega' but that is all. and it ran to completion and the guest boot console in the log, which is nice.
<matsubara> smoser, tests passed locally with your changes and I see the nested vm console output in the screen.
<infinity> gQuigs: This nsf-utils update.  The changes to systemd/nfs-client.target don't seem to make sense in the context of the other changes.
<infinity> gQuigs: I would have expected just the removal of gssproxy.service from After, not the rewrite of Wants/After.
<smoser> matsubara, awesome
<gQuigs> infinity: I think I tried that first
<gQuigs> infinity: but the rpc-svcgssd.service depends on it so that needed cleanup too
<infinity> gQuigs: Err, yes.  And clean it up you did.  But systemd/nfs-client.target still looks wrong. :P
<infinity> gQuigs: The others look fine.
<gQuigs> infinity: all I did was remove auth-rpcgss-module.service?
<infinity> +-Wants=auth-rpcgss-module.service
<infinity> +-After=rpc-gssd.service rpc-svcgssd.service gssproxy.service
<infinity> ++Wants=rpc-gssd.service
<infinity> ++After=rpc-gssd.service
<infinity> gQuigs: The Wants shouldn't have changed at all, and the After should still include rpc-svcgssd.service
<infinity> gQuigs: At least, that would seem more correct from how I'm reading this.
<seb128> slangasek, hey, saw the n-m discussion in the backlog? can we get some of cyphermox's time to help landing 1.2 for xenial?
<cyphermox> seb128: didn't awe just say he was doing the update to rc1?
<seb128> cyphermox, yes, we still need a coredev to sponsor the upload
<seb128> and you probably know the vcs setups/packages/etc the best
<seb128> would be nice if that was you doing the review/upload?
<cyphermox> oh, sure
<slangasek> seb128: hi, if you just need some of his time for review and sponsorship, that should be ok; but why are we trying to land this so late past FF?
<cyphermox> I can review, that's not typically a problem
<seb128> slangasek, because we think that 1.2 is bringing solide improvements that would benefit the LTS
<awe> cyphermox, don't know if you ever mentioned the thread from kgunn about this?
<slangasek> seb128: is that belief based on specific bug references?
<seb128> slangasek, cyphermox had a ffe filed in early march and we (desktop) though it was on track to land, then I was on holidays and now I'm picking up the discussion because apparently that didn't got pushed through
<cyphermox> awe: not sure I saw that?
<awe> pretty sure you did, as we discussed
<seb128> slangasek, see https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1552424
<awe> I can re-fwd to you if you'd like
<ubottu> Launchpad bug 1552424 in network-manager-vpnc (Ubuntu) "[FFE] NetworkManager 1.2-beta" [Undecided,Confirmed]
<cyphermox> awe: remind me?
<cyphermox> yes, please
 * awe looking for it
<seb128> slangasek, it doesn't have much specific references but stgraber / cyphermox / awe seem to agree it would be a good one to get, and the phone team wants that update to fix long standing issues (so they are going to get it in the overlay in any case)
<awe> yea, it's definitely going into the phone overlay.  We're continually getting hammered over WiFi behavior, and nm1.2 has heavily re-factored the WiFi logic, partly based on our discussions with upstream
<cpaelzer> is there a way to query dpdk/apt/? to get any package out of the archive that would install a file into a path /foo/bar?
<nacc> slangasek: can you help me understand something? rmadison and p.u.c indicate php-pecl-http are at 3.0.1-0ubuntu4; but apt-cache policy (and my local autopkgtest env) are only seeing 3.0.1-0ubuntu3. Is this just a blip in the migration?
<nacc> cpaelzer: dpgk-query ?
<nacc> cpaelzer: specifically dpkg-query -L ?
<cyphermox> awe: have you confirmed 1.2 fixes these issues or is it just hoping?
<cpaelzer> nacc: thanks nacc, will take a look
<awe> cyphermox, I'm sick of trying to continually patch 0.9.10x
<nacc> cpaelzer: ah maybe -S with a pattern
<cpaelzer> nacc: I thought that would go only on already installed packages, I'll take a look
<awe> so far testing has been very positive.  The big change was getting rid of NM's own AP list, and making wpa_supplicant the true master
<cyphermox> right
<cyphermox> ok then
<awe> and also I plan to upstream the ofono patches after we're done
<nacc> cpaelzer: for dpkg, -S does what you say, but for dpkg-query i think it looks at all
<awe> they're probably going to require some re-work for snappy, and I'd like to get assistance from upstream
<nacc> cpaelzer: based upon the manpage, that is
<awe> especially the settting plugin which reads ofono conf files directly from the filesystem
<cpaelzer> nacc: nope, at least without further options it is equivalend to dpkg -S
<cpaelzer> nacc: at least that is easy to test with containers that have other packages installed
<gQuigs> infinity: I don't believe rpc-svcgssd.service needs to run on a client
<gQuigs> it's a server daemon
<cyphermox> awe: ack. lubko is keen to see the ofono patches and land them in 1.3 or whatever
<awe> cyphermox, just fwd'd you the email; it was actually from will cooke
<nacc> cpaelzer: ah annoying; maybe grep-dctrl?
<cyphermox> that makes more sense :)
<cpaelzer> nacc: apt-file search /path/to/file
<awe> yea... sorry for mix up
<nacc> cpaelzer: yeah, grep-dctrl should be able to get you the same
<nacc> cpaelzer: just not sure on the syntax
<awe> cyphermox, so it looks two patches were upstreamed, so I've dropped them; also a bit of re-factoring of the dnsmasq code required some re-work of our dnsmasq dbus patch
<awe> but otherwise that's it
<infinity> gQuigs: And auth-rpcgss-module.service is also server-only?
<awe> I'll keep you posted if/when I have a clean build and have sanity checked
<gQuigs> infinity: nope, but our auth_rpcgss gets loaded correctly
<gQuigs> from the comment on rpcgss-module:
<gQuigs> # We want to start gss-proxy on kernels that support it and rpc.svcgssd
<gQuigs> # on those that don't.  Those services check for support by checking
<gQuigs> # for existence of the path /proc/net/rpc/use-gss-proxy.  Before they
<gQuigs> # can perform that check, they need this module loaded.  (Unless
<gQuigs> # rpcsec_gss support is built directly into the kernel, in which case this
<gQuigs> # unit will fail.  But that's OK.)
<infinity> gQuigs: Oh, I guess Before=rpc-gssd.service picks it up.  The previous units were just a bit more redundant.  Alright.
<gQuigs> yea, they were trying to do a conditional on gss-proxy that isn't relevant to us
<doko> rbasak, I noticed that apache2 can be built with lua5.2 instead of 5.1. not the only 5.1 based package in main, but that would be one less
<nacc> slangasek: did you ignore the failure for php-horde-http? i think we don't want to do that ... it's a version mismatch that's hiding a real problem (debugging it now)
<slangasek> nacc: no, pitti did
<nacc> slangasek: ah ok
<nacc> slangasek: something is off with php-horde-http & the new php-pecl-http, which is why the other horde tests are failing
<nacc> still debugging
<slangasek> ok
<nacc> and php-monolog failed because something is trying to install php5-mongo, but not sure what yet
<slangasek> nacc: this covers the php-horde-crypt, php-horde-feed, php-horde-service-gravatar failures then?
<nacc> slangasek: yep
<gQuigs> infinity: happy to give you access to my test setup if you want it
<nacc> slangasek: they are all failing to find the http\Client class
<infinity> gQuigs: I'll pass. :)
<slangasek> nacc: php-monolog has an explicit test dep on php5-mongo
<nacc> slangasek: ah it's a testdep! ok, will fix that
<slangasek> nacc: I'm halfway through it here fwiw
<slangasek> nacc: do you know if the new php-mongodb provides the 'MongoDate' class?
<nacc> slangasek: looking at the source, it does not
<slangasek> ok then it suffices to drop the test dep
<slangasek> nacc: ok, dropping the test dep lets the tests run but then there are failures; can I punt this back to you for investigation? http://paste.ubuntu.com/15654907/
<slangasek> nacc: errrrm or, it could be that these tests are e,b,w when run as root
<slangasek> turns out that when you write a test that tries to create /foo/bar and expects it to fail, this doesn't work if you actually have permissions to create /foo/bar
<ginggs> Unit193: are you around?
<infinity> slangasek: Hahaha.
<nacc> slangasek: yeah i've seen a few things like that
<infinity> One would assume you shouldn't be running those tests as root, then. :P
<nacc> slangasek: i can look into it; fwiw just s/php5-mongo/php-mongodb/ here, autopkgtest passed
<Saviq> xnox, hey, a lil' bump - bug #1552914
<ubottu> bug 1552914 in boost-defaults (Ubuntu) "Can't install libboost-dev:armhf in a cross-build environment" [Undecided,Confirmed] https://launchpad.net/bugs/1552914
<slangasek> infinity: then the test harness should declare this, and/or skip them when you are root ;)
<nacc> slangasek: and yeah, i've seen those exact issues when running as root
<infinity> slangasek: The latter, likely, but that's expecting a lot from PHP people.
<xnox> Sabah
<xnox> Saviq, bah
<rbasak> doko: that's bug 1324062. If it works against 5.2, I'm happy with it being switched.
<ubottu> bug 1324062 in nginx (Ubuntu) "No lua 5.2 support" [High,Triaged] https://launchpad.net/bugs/1324062
<slangasek> infinity: unixtojd() is all I have to say.
<slangasek> doko, rbasak: heh, yes it would be great to not have three copies of lua in main
<rbasak> kirkland: ^^ I presume you have no objection to apache2 building with lua 5.2 instead of 5.1? AIUI, it's as different as Python 2->3.
<rbasak> (but a much smaller proportion of users will actually care probably)
<infinity> slangasek: Pretty much everything in http://php.net/manual/en/ref.calendar.php is crack.
<pitti> slangasek, nacc: ah, I did because http://autopkgtest.ubuntu.com/packages/p/php-horde-http/xenial/amd64/ is mostly fail with a few sporadic passes; but happy to un-ignore if you have a proper fix
<doko> slangasek, won't yet work. nginx is 5.1 only, and dh-lua pulls in all three
<pitti> nacc: so if you upload a new version, the hint doesn't apply any more; if it passes, I'll gladly drop the hint
<nacc> pitti: ok, still debugging why it's failing, thanks!
 * pitti waves good bye, time for dinner & basketball
<slangasek> doko: dh-lua is a build-dep only and will drop out of main shortly ;)
<slangasek> doko: but I looked, and all three luae have runtime revdeps in main :P
<slangasek> infinity: do you remember the unixtojd() bug I'm talking about? Where it returned wrong values depending on which side of UTC you were on, and when someone started hitting this bug because their server's clock left BST, instead of fixing the code they added a +1h to the test case?
<infinity> doko: Given nginx is stuck anyway, I'm not sure I see the point in bumping apache2 if it might break users on upgrade.
<infinity> (If we could get 5.1 out of main, I'd say go for it, but we can't)
<infinity> slangasek: That sounds familiar.
<infinity> slangasek: The comments on the function in the docs aren't kind either. :P
<rbasak> Yeah, maybe better to break users on X+1 instead?
<nacc> slangasek: ha! i think php-pecl-http was being built w/o curl support! :)
<nacc> slangasek: the whole file that defines the failing constants is wrapped in an #ifdef :)
<slangasek> well ok then
<nacc> it should be comign from the core, though, not sure why it's not yet
<nacc> but i think that's the root-cause, at least
<cpaelzer> hi, is subscribing to a bug accounted as "activity" that avoids the expiration of incomplete bugs?
<cjwatson> cpaelzer: I don't believe so
<cjwatson> Doesn't change any fields of the bug
<nacc> slangasek: yeah, i think that fixed it, will post a debdiff in a new bug
<cpaelzer> cjwatson: thanks
<nacc> slangasek: did you still want me to look into php-monolog?
<slangasek> nacc: php-monolog uploaded, should be no need
<kirkland> rbasak: I don't think I even know that that means
<kirkland> rbasak: but, newer is better
<rbasak> OK, that's fine by me. I think we just decided not to do it though as it's quite late to be making that change and it won't help drop the dependency from main.
<nacc> slangasek: thanks!
<nacc> slangasek: lol, i think i figured out the php-email-validator failure
<nacc> between the previous run and the current, is it possible that example.co.uk became valid? :)
<nacc> slangasek: changing it to example3.co.uk, e.g., all the tests pass as expected
<slangasek> nacc: oh dear
<nacc> slangasek: yeah
<nacc> it's failing in debian too
<nacc> we can ignore the failures safely, afaict, if you want -- it's tech. a false positive
<nacc> and i'll notify upstream
<slangasek> nacc: yeah, will mark it badtest, thanks
<nacc> slangasek: i think that clears up the remaining excuses, i'll check
<slangasek> nacc: btw, how did php-pecl-http regress? was it built against libcurl previously?
<nacc> slangasek: that's a good question, it doesn't seem like it, but possible eitehr the the old php-pecl-http faked the namespace, rather than just not compiling it in
<slangasek> nacc: doesn't look like it faked the namespace, fwiw
<slangasek> so, more likely something changed to start depending on this interface
<slangasek> (anyway, uploaded)
<nacc> slangasek: yeah, i'm not seeing why in an obvious sense, tbh; i've pinged ondrej on it in case he knows
<nacc> and so debian fixes it similarly
<nacc> slangasek: fwiw, php-horde-http (which is the actual breakage here) isn't passing in wily either
<nacc> and hasn't
<slangasek> nacc: so at this point, we have 4 packages blocked by mysql (mythtv, netmrg, yate, zabbix); 3 packages that are going to be left broken for now (drupal7, libvirt-php, php-horde-mongo); 2 packages to be removed (php5, php-json); 3 false-positives due to alternate deps (cakephp, musica, pictor); php-radius, which is blocked by php-defaults which we're cleaning up; and 1 proposed-only package
<slangasek> I think that's sufficiently manageable that I'm going to pull the trigger on removing php5
<nacc> slangasek: that sounds correct to me
<nacc> slangasek: awesome!
<jgrimm> \o/
<slangasek> nacc: oh, squirrelmail-decode Recommends: php5-recode
<nacc> slangasek: i can send a debdiff in a moment
 * xnox wishes we had more autopkgtest runners
<bdmurray> darkxst: re bug 1566141 - when was org.freedesktop.PowerManagement deprecated? We'd need to inhibit sleep on Trusty systems upgrading to Xenial.
<ubottu> bug 1566141 in ubuntu-release-upgrader (Ubuntu) "sleep inhibitor uses deprecated interface" [High,New] https://launchpad.net/bugs/1566141
<gQuigs> thanks!
<stgraber> TheMuso: hey there
<stgraber> TheMuso: so that ubuntu-meta upload adds ubuntu-snappy-cli to a whole bunch of things, including a bunch of architectures which AFAIK are not supported by snappy (thought current snappy was just armhf and amd64)
<slangasek> stgraber: ubuntu-snappy-cli is built for all archs, and snappy either has been or should soon be building for 4 archs AIUI (arm and x86, 32 and 64bit)
<slangasek> and since the package exists, including it in the seeds allows for Future Expansion on the store side
<slangasek> stgraber: also, not sure TheMuso was the one who changed the seed, as opposed to the lucky winner of the next ubuntu-meta upload following the change :)
<slangasek> (Laney seeded it, mvo adjusted the seed)
<stgraber> indeed looks that way
<stgraber> ok, still seem like a giant waste of space on the architectures where this thing won't work at all, Go binaries aren't usually small :)
<stgraber> 4.4MB compressed, that's not nearly as bad as I thought
<slangasek> stgraber: let me run that question to people who might have an opinion; and yeah, I think these go binaries are actually getting stripped now
<stgraber> slangasek: I already did ask in the secret e-mail thread
<slangasek> mmk then
<stgraber> I'll accept the upload for now, it does match the seeds and if we want to fix any of that we'll just change the seeds and do another meta package update
<slangasek> yep, sounds good to me
<slangasek> nacc: php-defaults, php-radius cleared now; php-horde-http still has autopkgtest failures, even with latest php-pecl-http
<nacc> slangasek: hrm, let me look
<doko> stgraber, any idea about http://autopkgtest.ubuntu.com/packages/g/golang-gopkg-lxc-go-lxc.v2/xenial/amd64/ ?
<stgraber> doko: yeah, that thing is racy, just hit retry
<stgraber> doko: I think it sends SIGPWR to the container before the container's init has set a signal handler, so the container never shuts down
<slangasek> sounds like the definition of a force-badtest hint
<stgraber> doko: (that's a testsuite problem)
<doko> slangasek, how can I do these permanently?
<slangasek> doko: a) you can't because that's owned by the release team; b) a 'badtest' hint applies permanently to any given version of a package, and a newer version of the package will be blocked in -proposed (and thus is not supposed to interfere with other packages) until the tests are fixed or the hint is updated
<slangasek> doko: though I guess if the current practice is to retry the tests instead of fixing the race, that would cause the next version of the broken package to get into the release and make the hint out of date; the solution is for people to not do that ;P
<TheMuso> slangasek, stgraber, no, I made a desktop seed change, and uploaded the meta.
<TheMuso> Had nothign to do with me. :)
<doko> rbasak, slangasek: it's only apache2 and nginx which *use* lua5.1. All other deps are from lua modules which are built for all lua versions. But then we would need to prove that no /usr/bin/lua5.1 shebang is used in main
<Unit193> ginggs: I am now.
<ginggs> Unit193: Hi! LP: #1406825 has been fixed 5.34-2 in Debian, do you want to update your merge? I'm sure we don't want that "easter egg" in an LTS
<ubottu> Launchpad bug 1406825 in xscreensaver (Ubuntu) "xscreensaver complains "This version of xscreensaver is VERY OLD!"" [Medium,Confirmed] https://launchpad.net/bugs/1406825
<Unit193> Yeah, saw that one scroll past in Debian, wasn't going to push too hard on it because I needed some pull for other pending stuff too. :P
<slangasek> doko: why would we need to prove this?  You mean packages that use /usr/bin/lua5.1 as shebang don't have a dependency on lua5.1?
<doko> no, I was arguing that we only had two real lua5.1 use cases, not more
<rbasak> I'm a little confused. What are we discussing? I thought we couldn't pull lua 5.1 becuase of nginx anyway?
<slangasek> that was my understanding
<doko> yes, nginx is blocking, but I'm still missing the connection to apache2
<nacc> slangasek: i'm super-confused, i just ran against both proposed and release and the test passed in both, if I build the package or not
<nacc> slangasek: so 4 PASS runs :)
<slangasek> doko: you said "it's only apache2 and nginx that use it".  Changing apache2 leaves us with 1 revdep, not 0; so doesn't appear to be worth changing anything for 16.04
<doko> slangasek, anyway, filed a debian issue to change this
<slangasek> doko: great
<Unit193> Bah, those hashsum mismatches..
<Unit193> ginggs: dget https://sigma.unit193.net/source/xscreensaver_5.34-2ubuntu1.dsc  with a buildlog: https://sigma.unit193.net/source/xscreensaver_5.34-2ubuntu1_i386.build
<Unit193> And a free debdiff too.
<ginggs> Unit193: dgetting...
<ginggs> Unit193: uploaded
<GunnarHj> ScottK, yofel: Hi, pinging about https://code.launchpad.net/~gunnarhj/ubuntu-seeds/kubuntu.xenial_chinese-fonts/+merge/288192
<Unit193> ginggs: Great!  And thanks for poking.
<ginggs> no worries, thanks for the merge!
<darkxst> bdmurray, I don't know exactly, but a *long* time ago, possibly as long ago as GNOME 3.0
<darkxst> bdmurray, trusty supports logind inhibitors
<bdmurray> darkxst: okay, I just wanted to make sure we took care of trusty too
<darkxst> I tested it on trusty
<bdmurray> darkxst: cool, I'll look at merging it soon then
<darkxst> and  the PowerManagement code wouldnt even work if the interface was still there, dbus session calls fail without extra hackery as you will see in my other bug
<darkxst> bug 1565177
<ubottu> bug 1565177 in ubuntu-release-upgrader (Ubuntu) "screensaver is not disabled during release upgrade" [High,In progress] https://launchpad.net/bugs/1565177
<rbasak> Am I right in thinking that if I need a dh_autoreconf, I can replace an existing dh_autotools-dev_updateconfig. That is, that the former completely supersedes the latter if the former is necessary?
<rbasak> Except that a dh_autoreconf fails. Lovely. A patch to configure it is.
#ubuntu-devel 2016-04-07
<cpaelzer> good morning
<alkisg> Hi, once out of 10 boots, network-manager.service isn't started for me, and I have to manually start it with `service network-manager start`.
<alkisg> I'll file a bug report, but this is one of those times, so I thought I'd ask here in case someone wants to help me troubleshoot it, so that I can add more details to the bug report.
<alkisg> I'm suspecting an issue with "nbd-client.service" and ordering cycles etc:
<alkisg> ÎÏÏ 07 08:20:15 srv1-dide systemd[1]: NetworkManager.service: Job NetworkManager.service/start deleted to break ordering cycle starting with network.target/start
<alkisg> Sometimes systemd decides to delete nbd-client.service, sometimes NetworkManager.service, others dnsmasq... things like that
<alkisg> Part of journalctl: http://paste.ubuntu.com/15664149/ ==> search for "deleted" there
<sarnold> nice find
 * alkisg diverts /etc/init.d/nbd-client to see if it will work around the issue in subsequent boots...
<pitti> Good morning
<pitti> meh, so why do the cursor-up key suddenly acts as "print screen" in QEMU since yesterday (verified on sid and xenial, so presumably not specific to the guest distro)
<pitti> xev indeed says "Print"
<pitti> qemu didn't change in three weeks
<infinity> pitti: Huh.  You're the second person in a day to complain about keyboard layout weirdness.
<pitti> it's fine on my normal desktop, this is just in qemu
<infinity> https://bugs.launchpad.net/ubuntu/+source/xorg/+bug/1566878
<ubottu> Launchpad bug 1566878 in xorg-server (Ubuntu) "Alt-backtick regression" [High,Triaged]
<infinity> pitti: Still odd coincidence.
<pitti> booting trusty CLI and running evtest also says "KEY_RIGHTALT" if I press cursor left
<pitti> cursor right is KEY_PAUSE
<pitti> perhaps somehow this gets wedged up on the host side already
<infinity> pitti: Wait, booting trusty?  So, it's not userspace in the guest that broke.
<pitti> infinity: right
<pitti> infinity: as I said, it also simultaneiously affected debian sid with LXDE and xenial with unity
<pitti> (as guests)
<pitti> so this was a change on the host side, and not qemu
<infinity> pitti: But all from the same xenial host?
<pitti> I just wonder if that's just me
<pitti> infinity: yeah, my work laptop
<pitti> (well, my only laptop/computer really..)
 * pitti tries to train his fingers to use Ctrl+P instead
<infinity> pitti: Installing a quick VM.  Though, I haven't rebooted in a while, and now I'm afraid to. :P
<pitti> I didn't reboot after this morning's dist-upgrades
<pitti> so maybe after I do it'll be broken on the host too
<pitti> but I'd have assumed that QEMU gets is key events from X
<pitti> or from evdev (and that's fine on the host too, checked with evtest)
<infinity> pitti: Can't reproduce from just a dist-upgrade.  I might reboot in a bit and see if my world explodes.
<infinity> Or even now.  I'll reboot now.  New kernel to test anyway.
<infinity> WTF.
<pitti> at least four of your keys still work then :)
<infinity> pitti: Yep.  Can reproduce after reboot.  Left is leftalt, up is sysrq.  But only in my qemu guest, not the host.
<pitti> and if it's *only* these, then conversations with you will become interesting
<infinity> That's so messed up.
<pitti> ok, so I'm not mad yet
<pitti> well, at least not in *this* regard
<infinity> pitti: Anyhow, you can safely reboot.  Confirmed it only hoses the guest, for whatever bizarre reason.
<pitti> tjaalton: ^ would you have any idea what could have messed up QEMU *guest*'s key events since yesterday?
<infinity> Ahh, and after reboot, I can also confirm barry's bug.
<pitti> tjaalton: NB that neither QEMU nor the guest OS changed at all, this must be something on the host since yesterday
<infinity> Alt-` doesn't Alt-` anymore.
<pitti> hm, I never used that, what is that supposed to do?
<infinity> pitti: It cycles between windows of the same type, rather than all windows (Alt-Tab).
<tjaalton> the key above alt
<infinity> Oh, right, it's not ` on your keyboard, probably.
<pitti> ah that, I faintly remember
<infinity> tjaalton: So, yeah.  I can confirm barry's weird bug.  And also pitti's.  And I wouldn't be surprised if they're related.
<pitti> infinity: it is, just that `/~ is below Z on my Kinesis keyboard
<tjaalton> infinity: yeah I'll bisect this
<pitti> (also, no cycling with that key in i3)
<pitti> tjaalton: the bit that I don't understand is that both evtest (evdev) and xev (X translations) are just fine on the host
<pitti> so I wonder what could possibly have changed on qemu's host input side
<pitti> KeyPress event, serial 32, synthetic NO, window 0x2c00001,
<pitti>     root 0xda, subw 0x0, time 8521331, (652,142), root:(656,633),
<pitti>     state 0x0, keycode 64 (keysym 0xffe9, Alt_L), same_screen YES,
<pitti> KeyPress event, serial 32, synthetic NO, window 0x2c00001,
<pitti>     root 0xda, subw 0x0, time 8523315, (652,142), root:(656,633),
<pitti>     state 0x8, keycode 49 (keysym 0x60, grave), same_screen YES,
<pitti>     XLookupString gives 1 bytes: (60) "`"
<pitti> this is Alt+` for me, which looks reasonable at first sight
<tjaalton> pitti: new xserver, does your host have it?
<pitti> 2016-04-06 08:55:06 status installed xserver-xorg-core:amd64 2:1.18.3-1ubuntu1
<tjaalton> I see "error compiling keymap" on xorg log
<pitti> tjaalton: ah, I didn't reboot since this morning
<pitti> just dist-upgraded
<tjaalton> could be related
<infinity> Error compiling keymap could indeed relate.
<pitti> but infinity just did reboot, and he still gets those errors (alt+` on host and screwed up keyboard in qemu)
<infinity> pitti: And yes, running evtest in host and guest at the same time is just weird.
<tjaalton> we still carry the big patch to cache xkbcomp
<tjaalton> maybe that broke
<tjaalton> pitti: after reboot you'd probably see them too :)
<infinity> pitti: FWIW, Alt-` registers correctly to evtest, it's unity that's not picking it up, but barry bisected to xorg being the thing that broke it.
<pitti> [  6842.947] (EE) XKB: Couldn't compile keymap
<infinity> But that makes sense.
<pitti> I have that in my xorg.0.log already
<infinity> evtest is getting raw events.
<tjaalton> I'll disable the patch and see what happens
<pitti> so it's not this morning's xorg that broke it, but presumably yesterday's dist-upgrade
<infinity> Then the kbdmap is responsible for feeding applications.
<pitti> ah, so even xev is still below the layer of what apps see
<infinity> Yeah.
<pitti> but for some reason it doesn't affect gnome-terminal
<infinity> Which is why you can run it on a server CLI. :P
<pitti> at least there the cursor keys are fine
<pitti> anyway, seems tjaalton is on top of it, thanks
 * infinity stops his VM before he goes a bit insane from watching the mismatched evtest results.
<tjaalton> infinity, pitti: yup, disabling the patch fixed things
<pitti> tjaalton: yay; but supposedly it re-opens some other bug?
<tjaalton> it was added to make bootup quicker.. but I don't know how much that matters these days
<infinity> I assume that's a performance patch?
<tjaalton> we've had it for over six years
<infinity> tjaalton: Does it just change when the keymaps are compiled (but still only once), or do we compile repeatedly without it?
<tjaalton> never went upstream..
<tjaalton> i haven't looked in detail, yet
<infinity> tjaalton: If it's only once (or even only once per xserver), it's likely not all that useful.
<tjaalton> "This will make the 2nd and later boots slightly faster."
<infinity> Oh.  It precompiles to a cache on disk?  I see.
<tjaalton> yes
<infinity> I can see the value in that, if it works.
<infinity> The not working part sucks a bit. ;)
<infinity> tjaalton: I'd comment out the patch for a quick upload now, if I were you, to fix all our buggy keyboards, then investigate if it's worth fixing.
<tjaalton> yeah
<pitti> ah, so this isn't a new patch at all, it just happened to become incompatible with a more recent xorg?
<tjaalton> seems so
<alkisg> pitti, would it be possible for you to have a quick look at https://bugs.launchpad.net/ubuntu/+source/nbd/+bug/1487679 when you have some time? It's making systemd delete network-manager.service one out of 10 boots, and we have to manually start it to get network access...
<ubottu> Launchpad bug 1487679 in nbd (Ubuntu) "Breaking ordering cycle by deleting job nbd-client.service/start" [Undecided,Confirmed]
<pitti> alkisg: I'll queue it; do you have some idea already how to break this?
<alkisg> pitti: no, I've looked at /etc/init.d/nbd-client's headers but I didn't find anything so far
<pitti> ah, this is nbd-client, not server
<pitti> # Required-Start: $network $local_fs
<pitti> # Required-Stop: $network
<pitti> # Default-Start: S
<pitti> ah, same old -- wanting to run in very early boot, but wants the network up
<pitti> this is an impossible requirement with dynamic stuff like NM
<pitti> so I take it nbd needs to make up its mind if it wants to run early, or wants to run after being online
 * alkisg was sure that pitti would nail it within 1 minute :)
<alkisg> I would vote for "after being online", as for early it ships an initramfs script
<alkisg> Thanks!!
<pitti> I did an initial bug followup
 * alkisg will try to ping Wouter about it
<pitti> alkisg: I'm sure someone tries to put /var on an NBD device and uses NetworkManager to bring up the net :)
<pitti> alkisg: structurally this should be fairly similar to what NFS uses, so stealing some bits from there might be useful
<infinity> pitti: Yeah, but in those cases, it should be started in initrd.
<pitti> but nfs has native systemd units now (I don't think we managed to resolve this with sysv)
<infinity> pitti: What it might want in a sysv world is three jobs: initrd script for root, rcS script for pre-hotplug, and rc2 script for post-hotplug cleanup.
<infinity> pitti: But probably best to involve wouter in that than reinvent his wheels.
<infinity> tjaalton: Thanks for the quick fix.
<tjaalton> np, sorry about the bug :)
<seb128> slangasek, xnox, bug #1566502 ... did anyone tried to get unity to build on s390x?
<ubottu> bug 1566502 in indicator-applet (Ubuntu) "[MIR] indicator-applet" [Low,Incomplete] https://launchpad.net/bugs/1566502
<xnox> seb128, ubuntu-desktop is disabled on s390x.
<xnox> seb128, we have parts of things built e.g. some indicators, but e.g. not nux nor unity7
<seb128> xnox, nux seems to hit an illegal instruction is one of the tests, would it build if we ignored the error on s390x? does unity build then or does it has issues?
<infinity> All that's missing is nux, really.
<infinity> seb128: That bug you referenced has nothing to do with s390x, though.
<seb128> infinity, it does, see comments
<infinity> seb128: It doesn't, see next comment. :P
<xnox> and no plans to enable that. s390x is Ubuntu Server only
<seb128> infinity, right, I'm fine with that to
<infinity> xnox: No it's not.  Our *contract* is server-only.
<seb128> but seems like slangasek wanted the thing out of component-mismatch
<infinity> xnox: We've made no effort to restrict the packages built.
<infinity> If someone wanted to fix nux, I'd be fine with that.
<infinity> seb128: My point is that fixing the s390x thing won't fix that part of c-m.  It's been like that for several releases.
<seb128> infinity, ok, so my take is that it's fine to ignore that bug
<seb128> right?
 * infinity nods.
<infinity> Ignore away.
<seb128> thanks
<infinity> Odd_Bloke: Did you ever get around to spinning up another powerpc test cloud image after I told you we had a fixed kernel?
<infinity> Odd_Bloke: I'm thinking that if that test works (and it should), we should be a few small twiddles away from publishing dailies?
<Odd_Bloke> infinity: I didn't, I'm afraid.
<infinity> Odd_Bloke: Could you? :)
<infinity> Odd_Bloke: Would be nice to get that work item off your plate.
<Odd_Bloke> infinity: I've kicked off https://launchpad.net/~cloud-images-release-managers/+livefs/ubuntu/xenial/cpc/+build/57310, and I'm checking in the meantime if I should expect that to work.
<Odd_Bloke> (Because I can't find my branch with powerpc changes, which either means I deleted it accidentally or the changes got merged and I deleted it :p)
<cjwatson> infinity: Fancy some archive fun?
<cjwatson> I need an adult.
<Odd_Bloke> infinity: Well, that build's already failed, so that answers my question.
<cjwatson> Maybe it's the wrong time over there.
<cjwatson> pitti: Can you be a techboarder for me?
<pitti> cjwatson: for you, always :)
<cjwatson> pitti: :-) I'd like https://paste.ubuntu.com/15666533/ run in "lp-shell production devel".  This will cause the publisher to emit by-hash index files, but won't yet turn on the Release flag to cause apt to use them by default
<Odd_Bloke> infinity: (I found my branch \o/)
<TJ-> Odd_Bloke: as you mention cloud-images, would you happen to know why the partner-images ubuntu-xenial-core-cloudimg...  are missing key packages such as iproute2, net-tools yet the 14.04 equivalents have those packages? I ask because someone installed the docker image via that archive and complained there's no network config ability
<cjwatson> pitti: (if it says that attribute doesn't exist, rm ~/.launchpadlib/api.launchpad.net/cache/*wadl* and try again)
<Odd_Bloke> TJ-: I don't off-hand, no; could you file a bug at https://bugs.launchpad.net/cloud-images/+filebug with more details? :)
<TJ-> Odd_Bloke: I was struggling to find out the responsible team/package for them, since there is cloud-images.ubuntu.com and partner-images.canonical.com
<TJ-> Odd_Bloke: the cloud-images.ubuntu.com look correct according to the manifests
<Odd_Bloke> TJ-: So we don't support using the images at partner-images.c.c directly; tianon takes those and creates the Docker base images from them.
<pitti> cjwatson: ah, I better do that right away; the rm -r has run for about a minute already :)
<LocutusOfBorg> can anybody please retry mercurial autolkgtest against the new hg-git and hg-subversion?
<pitti> apparently I had a gazillion GBs there
<cjwatson> yeah, BTDT
<TJ-> Odd_Bloke: right, do you know where  bugs for that should be reported?
<pitti> cjwatson: done; yay for moving to by-hash
<cjwatson> pitti: great, thanks, I'll watch the publisher for a while
<cjwatson> fingers crossed
<Odd_Bloke> TJ-: I don't know off-hand how Docker handles image bugs; if you file something at that link, then we'll at least have something that we can point tianon at when he wakes up. :)
<cjwatson> There's a separate advertise flag that we'll turn on once everything looks good.
<TJ-> Odd_Bloke: yeah, I followed the Docker links back until I found the images on partner-images, so thought it was a Canonical/Ubuntu specific process
<pitti> LocutusOfBorg: done
<Odd_Bloke> TJ-: Yeah, if it's a problem with the contents of the image, then it's probably something that we'll end up fixing.
<LocutusOfBorg> thanks pitti
<infinity> cjwatson: Oh, it's the right time for me, but I was AFK.  I guess pitti's got you covered?
<cjwatson> Yep, thanks
<Odd_Bloke> slangasek: I'm not sure I ever thanked you for doing clean-up on our dodgy livecd-rootfs code; thanks! :)
<TJ-> Odd_Bloke: seems this has been the case starting with 15.04 bug 1567349
<ubottu> bug 1567349 in cloud-images "partner-images (for Docker, etc) seem to be missing key network packages" [Undecided,New] https://launchpad.net/bugs/1567349
<cjwatson> doko: Would it be OK to drop the Provides from libgmpv4-dev?  I think everything that should be using that package does so explicitly (seems to be just ppl-gcc4), and the Provides field causes ambiguity when resolving build-deps from main against universe.
<doko> cjwatson, sure. this package is only there to build older gcc's, required by the phone
<cjwatson> doko: all right, I'll do that now, thanks
<cjwatson> static analysis for the win
<cjwatson> Anyone know of a reason why foo2zjs shouldn't say cups-filters | foomatic-filters rather than just foomatic-filters?  cups-filters is the one in main, and Till isn't here
<infinity> cjwatson: Sounds reasonable to me.
<infinity> cjwatson: Would change the dep resolution for universe flavours, but I'd consider that a feature, not a bug.
<cjwatson> Yeah
<LocutusOfBorg> pitti, please run the testsuite for mercurial against hgsubversion 1.8.5-1ubuntu1 if possible (just uploaded)
<pitti> that'll still take a bit, it first needs to be reviewed/accepted, built, and published
<LocutusOfBorg> ok, pitti question: I can click and retry them, can't I just do that by myself?
<pitti> LocutusOfBorg: you can retry the test in the normal mode (i. e. run against released package versions except if dependencies force the -proposed version)
<LocutusOfBorg> ok, the question was: can't I retry against proposed?
<pitti> LocutusOfBorg: normally we only use the package trigger (i. e. mercurial) from -proposed, but take the tested reverse dependencies from -release
<pitti> LocutusOfBorg: right now you can't
<LocutusOfBorg> well, hgsubversion will migrate anyway, so I can wait for migration and then retry :)
<pitti> we could add that to the REST API relatively easily, but we won't add another button for it
<LocutusOfBorg> ok thanks
<LocutusOfBorg> seems legit
<pitti> LocutusOfBorg: yes, that will work of course
<pitti> (and is also a cleaner way, as it's much simpler to pinpoint the origin of regressions)
 * LocutusOfBorg is going to look at the debci source code
<LocutusOfBorg> I can't find the source code for request.cgi
<pitti> LocutusOfBorg: https://git.launchpad.net/~ubuntu-release/+git/autopkgtest-cloud/tree/webcontrol
<LocutusOfBorg> seems that the link on the autopkgtest points to debci source code
<pitti> retry.cgi lives on the same server/domain, but it's unrelated to debci indeed
<pitti> err, request.cgi
<LocutusOfBorg> ta
 * cjwatson shoves [by-hash=force] in a bunch of places for testing
<cjwatson> seems to be behaving itself thus far
<Odd_Bloke> infinity: https://launchpad.net/~cloud-images-release-managers/+livefs/ubuntu/xenial/cpc/+build/57317 should have images shortly.
<infinity> Odd_Bloke: Ta.
<pitti> stgraber: uh, dpkg-reconfigure lxd is very ... challenging
<pitti> stgraber: is there some shortcut to "JFDI" it, like it did before?
<pitti> manually entering a gazillion IP addresses seems both error prone and also most folks won't have any idea what to use there
<pitti> it also seems to default to "lxcbr0" which already is configured by lxc, so it shouldn't ask me all those IP questions again?
<pitti> ... and now I am supposed to come up with some valid IPv6 address -- I don't know how to do that easily :/
<Odd_Bloke> infinity: I'm OOO tomorrow and sprinting next week, so if you want anything to happen with powerpc images, this afternoon is your last chance for a while. :)
<pitti> stgraber: filed as a bug 1567440 now, this might be too complex for an async IRC conversation
<ubottu> bug 1567440 in lxd (Ubuntu) "debconf for bridge configuration is confusing and too complicated" [Undecided,New] https://launchpad.net/bugs/1567440
<infinity> Odd_Bloke: Define "afternoon".
<infinity> Odd_Bloke: I'm about to spin it up in a VM right now.  Do you need anything more from me than "it works"?
<infinity> Odd_Bloke: Like, sponsoring a merge of changes to livecd-rootfs, I guess?
<stgraber> pitti: replied in the bug, the fact that you had lxcbr0 set in there is a bug, you should have had lxdbr0, that's likely caused by a bug we had in our old migration code, unfortunately detecting this is impossible (can't distinguish that from folks having actually changed their lxd config to use lxcbr0...)
<stgraber> pitti: The rest is working as intended. We do recommend -p medium nowadays (that's what lxd init calls and what the upgrade warning tells you to run)
<Odd_Bloke> infinity: The next ~3 hours; yeah, if I hear from you that it works then I'll submit a MP for livecd-rootfs.
<stgraber> pitti: and yes, the user experience is worse than the pre-configured lxcbr0 in most cases but for the 1% or so where lxcbr0 broke all networking, lxdbr0 is massively better and our requirement here was "never break someone's connectivity"
<Odd_Bloke> infinity: I don't know if I'll have dailies working before EOD (because I have about three image build-lengths until my EOD :p), but I can push that forward in spare minutes next week.
<pitti> stgraber: I just followed up again, I re-tried this in a clean VM
<pitti> stgraber: no, this can't possibly be "intended" -- quite frankly, this is a horrible UX
<infinity> Odd_Bloke: It's doing datasource things.  (I thought utlemming had planned to make cloud-init inert by default?  Didn't get to that yet?)
<infinity> Odd_Bloke: But I think that's a good sign, yes?  It broke well before this last time.
<pitti> stgraber: I have a suggestion for restructuring the questions
<pitti> (on the bug)
<Odd_Bloke> infinity: Yep, I think that's definitely a good sign.
<infinity> Odd_Bloke: Will it eventually give up on datasourceifying and give me a getty?
<Odd_Bloke> infinity: I think so, yeah; it'll eventually realise that the EC2 metadata source isn't just being slow to respond.
<infinity> Odd_Bloke: Kay.  I'll wait longer.  But based on the scrollback up to this point, I think we can call this "good" and push forward.  If it needs tweaking later, we can do that after it's building dailies in production.
<infinity> Odd_Bloke: So, I see a 1-liner to live-build, I can push that ASAP.  Lemme look at livecd-rootfs.
<infinity> Odd_Bloke: Or just toss an MP my way, since it seems you did this on top of trunk.
<Odd_Bloke> Yeah, I'll push it up now.
<infinity> cjwatson: Looks like we're dangerously close to lobbing the powerpc scalingstack ball into your court.
<infinity> cjwatson: Finally.
<cjwatson> infinity: Cool.  We need bos02 first, but from scrollback it sounds like that's getting there.
<infinity> cjwatson: cameroff?
<cjwatson> That's the one.
<infinity> That's one of my new favourite bugs.
<infinity> Odd_Bloke: Oh, looks like Colin already landed your live-build 1-liner.
<infinity> Odd_Bloke: So just need livecd-rootfs.
<Odd_Bloke> infinity: https://code.launchpad.net/~daniel-thewatkins/livecd-rootfs/powerpc/+merge/291250
<infinity> cjwatson: Based on build times I've been comparing between bos01 and my POWER7 machines, I think one POWER8 compute node should replace my whole farm.
<infinity> cjwatson: So, that's comforting.
<infinity> (But we should still ask IBM for a few more. :P)
<ansgar> Is filing a sync request still enough to get packages synced from Debian? Or do I need to do more than filing #1567322?
<infinity> Odd_Bloke: That last hunk looks curious.  But I'll go look at it in context..
<cjwatson> infinity: I don't recall how densely we're packed at the moment, but that's plausible.  I'm hoping that instances on bos02 will be a bit more reliable than on bos01.
<infinity> ansgar: That's enough if it's something that we don't care enough about to ask for more.  Lemme look.
<Odd_Bloke> infinity: It's basically "everything else".
<infinity> ansgar: Ahh, yeah, I think we can do that without any extra paperwork.
<ansgar> infinity: Yay :) It's in universe and should have no reverse dependencies outside.
<infinity> Odd_Bloke: Yeah, after looking at the diff, that hunk is wrong.
<infinity> Odd_Bloke: Well, "wrong", given that you 'add_serial_console hvc0' on ppc64el, and powerpc should match.  In reality, you shouldn't need to do console magic on systemd anymore at all.  But I'll make them match for now and you can revisit the whole concept later.
<infinity> Odd_Bloke: I'll fix that and merge, the rest looks sane.
<Odd_Bloke> infinity: Ack, thanks.
<infinity> Odd_Bloke: Tagged and uploaded.
<Odd_Bloke> infinity: \o/
<infinity> Odd_Bloke: If you can twiddle some bits on your end, this should be ready to be abused in ~30-60m.
<infinity> Odd_Bloke: (I'm just assuming here that you just need to add some vars here and there, if it's more complex, well, I'll settle for "soonish")
<Odd_Bloke> infinity: Yeah, the trick will be finding all the heres and theres.
<Odd_Bloke> infinity: (Enabling s390x has at least refreshed our memory on most of those parts.)
<infinity> Odd_Bloke: rgrep my_stuff/ ppc64el
<infinity> Odd_Bloke: Given the images are pretty much identical, I'd assume just adding powerpc wherever ppc64el lives would win.
<Odd_Bloke> Yeah, that should get us most of the way.
<cjwatson> mvo: Where are your scripts for managing ddtp-translations?
<cjwatson> Oh, apt-ddtp-tools I bet
<infinity> ansgar: Is there an order+wait-time required on those to get build-deps in an order you need, or can I just sync the lot and it'll DTRT?
<ansgar> infinity: They have strict dependencies; just dune-grid-glue needs to be rebuild after the rest (or after dune-grid at least).
<infinity> ansgar: Alrighty.  Doing.
<ansgar> infinity: Thanks :)
<infinity> Odd_Bloke: Oh hey, it finally timed out and gave me a getty.  \o/
<infinity> Odd_Bloke: Which I can't log into, but I assume that's because no datasource set up a user.
<Odd_Bloke> infinity: \o\ \o/ /o/
<Odd_Bloke> I would say SHIP IT but we already did. :p
<infinity> Odd_Bloke: ;)
<cjwatson> mvo: do you think you could merge https://code.launchpad.net/~cjwatson/apt-ddtp-tools/xz/+merge/291260 and do a new ddtp-translations?
<cjwatson> Laney: ^-
<Laney> merci
<seb128> cjwatson, wgrant, thanks ;-)
<barry> mvo: hi!  did you see my email about gdebi?
<mvo> barry: yes, was quite busy so far but I hope to get to it later today, thanks in any case for your fixes (I think I saw some in the mail :)
<barry> mvo: cool.  i'm happy to take the responsibility for uploading if you want (and if i have the perms)
<barry> mvo: otherwise, thanks!
<mvo> barry: just upload to debian if you want and sync, thats totally fine
<barry> mvo: +1
<smoser> infinity, https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1566468 wonder if you have thoughts on that. you had helped me with a similar issue long ago in bug 1115710
<ubottu> Launchpad bug 1566468 in open-iscsi (Ubuntu) "systemd-modules-load.service: Failing due to missing module 'ib_iser'" [Medium,Confirmed]
<ubottu> bug 1115710 in module-init-tools (Ubuntu Precise) "Mellanox mlx4_en network driver is not automatically loaded" [Medium,Triaged] https://launchpad.net/bugs/1115710
<infinity> smoser: Friggin' mellanox again?
<smoser> well, no. it did make me think that though. the 'ib_' was what brought it down that path.
<smoser> it is infiniband though
<infinity> smoser: There is a way to make the module load conditional, if you'd prefer that.
<infinity> smoser: But there's likely not much harm in moving it to the base linux image as well.
<infinity> smoser: I suppose the question is if ib_ser would ever be useful on a non-metal machine.
<infinity> ib_iser, even.
<smoser> right. i think probaly not. but open-iscsi is.
<smoser> so...
<smoser> so in my head its +80k into linux-image (and the cloud images) versus additional delta on open-iscsi package (which we've almost removed at this point)
<infinity> ib_iser also pulls in ib_core, so you basically end up with a full IB system at that point.
<smoser> but we already have that
<smoser> yeah... i didn't say that in the bug. meant to.
<smoser> i checked. all its deps are already there.
<infinity> Oh, ib_core and ib_addr are in linux-image already?
<infinity> In that case, just yank it in, IMO.
<infinity> We have iscsi, we have ib, we may as well have the glue.
<smoser> infinity, http://paste.ubuntu.com/15670921/
<smoser> yeah, i think i agree.
<infinity> smoser: Yeah, I definitely agree if it's just that module.  We already have all the scaffoling for both bits it bridges.
<sil2100> Laney: hey! So a quick newbie DMB question ;) Now that we have the right amount of people, how usually did the first agenda get created? Since normally it's being worked on by the chair, right?
<Laney> sil2100: nah there's only a chair during the meeting
<Laney> all of you should work together to sort it out
<infinity> sil2100: The rest of the time, we're coffee tables.
<Laney> sorry we left such a backlog of applicants :(
<sil2100> infinity: oh my, furniture all over the place
<barry> tjaalton: yay!  thanks for fixing alt-`
<slangasek> Odd_Bloke: heh, glad it all worked out :)
<teward> nacc: rbasak: should we have in ubuntu-server release notes something regarding php5 being dropped entirely, with php7.0 replacing it?
<teward> already seeing such things in #u+1 channel
<nacc> teward: yeah, it's on my todo for this week, hopefully
<teward> cool :)
<nacc> teward: i need to rewrite serverguide altogether :)
<teward> heheh
<teward> nacc: probably should expand server guide to have nginx in it at some point - too bad I'm overworked the next few weeks
<nacc> teward: yeah :/
<nacc> teward: luckily, server guide (aiui) is sort of living, so we can do updates post-release
<teward> mhm
<ansgar> infinity: Hmm, dune-grid FTBFS on powerpc. I guess this might be https://bugs.debian.org/786500? It looks like alberta wasn't rebuilt on Ubuntu.
<ubottu> Debian bug 786500 in release.debian.org "nmu: alberta_3.0.1-1" [Normal,Open]
<infinity> ansgar: Fun.
<teward> nacc: just wanted to make sure the php5->php7.0 transition was noted in the release notes, given this morning's enlightenment i imparted to #ubuntu+1 about php5 going away :P
<teward> thanks
<nacc> teward: thanks, i'll join there too, to help out
<infinity> ansgar: Oh, fun.
<infinity> ansgar: Do you know what toolchain version was needed to fix that?
<ansgar> infinity: No, I just noticed that it was fixed in Debian when I looked at dune-grid failing to build there.
<infinity> Whee.  Well, lemme give it a whirl in a PPA before assuming a rebuild in the archive will magically help.
<teward> nacc: sounds good
<seb128> nhandler, hey
<nhandler> Hi seb128
<seb128> nhandler, about the wallpapers update, are those images CC-BY-SA 2 or 3 or a mix?
<seb128> nhandler, I'm a bit confused by the debian/copyright thing
<nhandler> seb128: wallpapers update?
<seb128> nhandler, https://code.launchpad.net/~nhaines/ubuntu-wallpapers/xenial-fcs/+merge/291209
<seb128> doh
<seb128> nhandler, sorry wrong Nathan
<nhandler> seb128: No problem :)
<seb128> :p
<xnox> caribou, hey
<xnox> caribou, so i'm here with kernel people in bluefin
<xnox> caribou, got a minute to chat about zfcpdump?
<infinity> ansgar: A rebuild of alberta indeed made the world a better place in my PPA.  Replicating in the archive now.  Thanks for the pointer.
<infinity> ansgar: Or, rather, thanks for caring enough about your syncs to follow up, rather than leaving me scratching my head. ;)
<ansgar> infinity: It's just to get the newer dune packages in 16.04 ;)
<jderose> tjaalton: xorg-xserver 1.18.3-1ubuntu1 fixes this -  https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/1561685
<ubottu> Launchpad bug 1561685 in xorg-server (Ubuntu) "x-staging: 1.18.2-2ubuntu0.1 host breaks arrow keys on qemu guest" [Undecided,New]
<jderose> tjaalton: is it more proper to mark that bug as invalid, or as fix released?
<tjaalton> jderose: you probably mean -1u2
<tjaalton> mark as dupe of the other
<bdmurray> coreycb: Both keystone and nova were tested in bug 155935?
<ubottu> bug 155935 in gnome-terminal (Ubuntu) "do not print by transparent printer esc[5i and [4i" [Low,Invalid] https://launchpad.net/bugs/155935
<tjaalton> and boo that i didn't see this earlier..
<bdmurray> coreycb: er bug 1559935
<ubottu> bug 1559935 in keystone (Ubuntu Wily) "[SRU] nova 12.0.2, keystone 8.1.0" [Medium,Fix committed] https://launchpad.net/bugs/1559935
<jderose> tjaalton: ah yeah, you're right... 1.18.3-1ubuntu2. i misread my apt/history :)
<tjaalton> jderose: maybe you pinged me about that earlier and i just forgot about it...
<tjaalton> anyway, fixed now
<jderose> tjaalton: much thanks!
<coreycb> bdmurray, yes, keystone and nova were tested for that bug
<coreycb> bdmurray, I think arges already promoted that to updates
<bdmurray> coreycb: I only see the nova task as Fix Released
<coreycb> bdmurray, ah yeah I don't see keystone 8.1.0 in updates
<bdmurray> coreycb: so I'll do that bit then
<coreycb> bdmurray, thanks, appreciate it
<hallyn> hi - how do we get a package un-blacklisted?  (https://bugs.launchpad.net/ubuntu/+source/edbrowse/+bug/1565548)
<ubottu> Launchpad bug 1565548 in edbrowse (Ubuntu) "edbrowse should not be blacklisted" [Undecided,New]
<slangasek> hallyn: the archive team edits the list
<hallyn> ok i did subscribe them to the bug...
<slangasek> hallyn: yes; in practice pinging an AA probably gets you better QoS
<hallyn> arges: ^ is that something you could look at?
<hallyn> slangasek: ok :)
<hallyn> thanks
<slangasek> I am looking now fwiw
<hallyn> it sort of exemplified the worst of what ppl complained about a few years ago...
<slangasek> hallyn: I've updated the blacklist, it's cached somewhere and I don't know actually where in order to kick it; try syncing it in a bit and poke me for NEWing after?
<hallyn> slangasek: great, thanks
<cjwatson> It's a */5 cron job, I don't expect you'll have to wait long
<cjwatson> update-sync-blacklist run by ubuntu-archive@snakefruit
<cjwatson> Probably done already
<hallyn> yup, sync succeeded - thx
<hallyn> slangasek: syncpackage worked
<kwah> Greetings...
<kwah> Got bitten by something: unity session does not really start
<kwah> no dash/no panel
<kwah> Any ideas how to find out what is wrong are welcome
<kwah> happened on xenial after yesterdays update + upgrade
<kwah> just filed bug 1567591
<ubottu> bug 1567591 in unity (Ubuntu) "[xenial] unity session does not start" [Undecided,New] https://launchpad.net/bugs/1567591
<kwah> + and no window decorators as well.
<hallyn> kwah: sorry, i also cannot run unity7.  unit8 works better for me (but is not usable unless yo'ur ehappy in the terminal)
<kwah> hallyn, for me everything worked perfectly till yesterday. until upgrade. not anymore :(
<kwah> By "unity" package date looks like april fools: Installed: 7.4.0+16.04.20160401.1-0ubuntu1
<kwah> But today is already 7th :D
<hallyn> kwah: all i know about it is that kirkland excitedly found he could put the panel on the bottom :)  (which i personally wouldn't want, but more power to him)
<kirkland> indeed, I do like it down under :-)
<hallyn> is that bc you have an actual real monitor?
<hallyn> speaking of which, did lenovo make any more announcements aobut the 'legacy' thinkpad they were gonna put out, with a reasonably sized monitor?
<kwah> At the moment, I would not mind having it "down under". But it is nowhere.
<sarnold> maybe he took those 16:9 monitors and spun them around to 9:16 so he's got all kinds of vertical space to play with
<hallyn> heh i've read pdfs that way
<hallyn> i'd rather read them on the new sony ereader
<sarnold> hallyn: dude 4:3 is never coming back :( they made that clear..
<hallyn> sarnold: no no!  lenovo said they would
<hallyn> it would have the little light on top of the monitor to shine on the kbd and everything
<sarnold> hallyn: in one of the questionaires they had a handful of screen dimensions and they had a note near the bottom "no one makes 4:3 panels any more we can't offer that as an option. sorry."
<hallyn> don't take this away from me!
<hallyn> biab, gotta go kick a puppy
<infinity> sarnold: Cop out.  They could buy 16:9 panels and slice off the end with an Xacto knife.
<hallyn> like i do
<infinity> sarnold: A great activity for the kids at the Lenovo daycare.
<sarnold> infinity: you know if that works that might be better than my "cover it with some dark duct tape" idea
<nacc> Pharaoh_Atem: ping
<sladen> hallyn: no.  There is one video interview with David the design discussing basically "the anniversary in 2017 would be a good year"
<hallyn> sarnold: wouldn't stacking two one over the other work better?  you could glue the one kbd to the back of the other monitor...
<hallyn> sladen: are you the kind of guy who enjoys telling kids there's no easter bunny?
<hallyn> :)
<infinity> hallyn: That's exactly the kind of guy sladen is.
<hallyn> in the end i really just want it for pdfs, so the sony ereader is the way fwd for me
<jrwren> there is no easter bunny?
 * jrwren runs and cries in teh corner
<sarnold> which ereader by the way? :) my prs505 or whatever it is is sluggish enough and bringing it along on trips seemed to be the magical "please subject me to extra time-consuming scrutiny" at airports
<sladen> hallyn: infinity:  https://youtu.be/8lqAa_eD84A?t=13m34s "David Hill Q&A with Lenovo Insiders "
<infinity> sladen: I actually prefer the new Thinkpads, I don't get this fetishism for the past.
<infinity> Literally the only thing wrong with my T450s is the pry/clip versus screws thing.  And yeah, I'd give up a few mm and a few grams to get screws.
<infinity> But I don't want anything remotely like an old Thinkpad just to get easier opening. :P
<nacc> slangasek: Pharaoh_Atem: i just got a weird testcase failure with cgi/fpm/mod-php7.0, wget wasn't present in the image? is that a recent change?
<sladen> infinity: grooy.  I quite like the same keyboard I've used for 15 years, vertical space, hardware nipple buttons, status LEDs that show when the machine is about to die, HDDs/RAM/etc thta can be exchanged
<infinity> sladen: Hardware buttons are there in the current line.  They backpedalled on that one quickly.
<infinity> sladen: Guts can be exchanged on this fine (except for the screw issue).
<infinity> sladen: Keyboard, I grant you, is a matter of taste, but I type faster on their new keyboards than the old (though I like both).
<nacc> slangasek: Pharaoh_Atem: ah i wonder if it's an autopkgtest quirk
<hallyn> sarnold: the dpts1 'digital paper'
<hallyn> infinity: yeah the only thing i hate about my t440s is the *&$%(*$&%)( clickpad, i think i'll love the t450 when i upgrade
<sarnold> 1200x1600! hey!
<infinity> hallyn: You can buy a 450 pad and install it in a 440.  wgrant did that.
<hallyn> yeah, i saw his...
<hallyn> i was going to hold out, but my laptop isn't breaking yet so maybe i'll give in
<infinity> hallyn: Assuming it's not exploding, the 440 is pretty nice hardware.  Would make a decent hand-me-down.
<infinity> hallyn: Heck, my T420s is still great, and I can't figure out what to do with it.
<hallyn> exploding?
<infinity> (It's doing glibc CI builds right now)
<hallyn> it did smoke once when i didn't plu gin in the righ torder...
<hallyn> but that was a year ago
<slangasek> nacc: if your autopkgtest requires wget it should declare a test dependency; that's not guaranteed to be part of the test environment
<nacc> slangasek: that's what i though, i'll update my debdiff then
<nacc> slangasek: i don't know why we didn't see it before
<nacc> sarnold: so i was looking at some older PHP5 CVE fixes, and noticed one of the ubuntu patches has some stray changes (very small, shouldn't have any impact, but ...). Is that expected? I would think not
<sarnold> nacc: no, it isn't, but despite appearances we are human :)
<nacc> sarnold: heh -- wasn't sure if it's worth fixing, i don't think it's causing this other bug or anything, just was curious
<nacc> sarnold: it *might* actually be a performance improvement, even if marginal :)
<sarnold> nacc: it's also possible that e.g. a first-draft change was proposed and we'd build packages with that, test, etc., and then the 'final patch' is released with other changes -- we don't always rebuild with those, especially if the changes look useless / pointless
<nacc> sarnold: ah that could be, you're right
<nacc> sarnold: ok, np -- just learnin'
<sarnold> nacc: if you do spot something that looks like a regression, please do file bugs.
<sarnold> thanks :)
<nacc> sarnold: yep, of course
<Pharaoh_Atem> nacc: that's strange, as it definitely worked, and nothing changed in the tests
<nacc> Pharaoh_Atem: just confirmed that i needed to add the dep
<nacc> Pharaoh_Atem: maybe it just happened to work before
<nacc> Pharaoh_Atem: i'll let ondrej know
<Pharaoh_Atem> okay
<slangasek> nacc: fyi php-universe-source7.0 should go away as part of this merge
<slangasek> nacc: dunno if you're prepared to do that right now :)
<mvo_> Laney: if you still need it we should talk tomorrow, crazy day
<nacc> slangasek: oh because our infra can do the universe builds now?
<nacc> slangasek: i can do that today, for sure; do you have a pointer to what i need to do?
<slangasek> nacc: basically just dropping the delta
<slangasek> nacc: I just flipped the switch on enabling universe build-deps for main in xenial ~20 minutes ago
<slangasek> 10? maybe it was only 10
<nacc> slangasek: ok, cool; so i'll fix that up and udpate those debdiffs
<nacc> slangasek: yeah, that'll be nice to have done now, will make our delta very small
<tjaalton> huh, enigmail broke
<tjaalton> can't find the secret key
<tjaalton> bug 1485863
<ubottu> bug 1485863 in enigmail (Ubuntu) "gpg: decryption failed: secret key not available" [Undecided,New] https://launchpad.net/bugs/1485863
<tjaalton> same symptoms on two xenial machines
<tjaalton> ah it's bug 1565963
<ubottu> bug 1565963 in gnupg2 (Ubuntu) "gpg secret keys not migrated after upgrade to gnupg 2.1" [Undecided,New] https://launchpad.net/bugs/1565963
<superm1> tjaalton: could you make sure you add some comments about what version you came from and upgrade path?  you're the second person, but we don't have a reproducer for this yet
<superm1> I tried in a VM including an upgrade over from gnupg2.0 to 2.1, and maintainer in Debian tried as well without any luck so far
<tjaalton> both xenial->xenial, but the .gnupg directory is much older
<nacc> slangasek: just to be clear, i think we'll still need to have the netcat-traditional change?
<slangasek> nacc: as a delta in build-depends?
<tjaalton> superm1: I'll update the bug
<superm1> thanks
<nacc> slangasek: yeah, just trying to understand fully what is now allowed/enabled
<tjaalton> superm1: what files should be updated by the migration? only files touched this year are random_seed and the agent socket
<slangasek> nacc: there's no need to carry a delta for build-deps so long as those build-deps are only used as runtime.  If the build dep will be translated into a runtime dep (i.e. a library -dev package), we need to make sure we use the right one for main; but netcat, it should also be fine to drop the delta for
<superm1> tjaalton: that's a better question for the debian maintainer who is subscribed to the bug too (i'm worried i wouldn't give a complete answer)
<superm1> tjaalton: i know that it touches a .gpg-v21-migrated
<superm1> if you haven't already ran the import to fix it can you back up .gnupg to something else before doing so in case there are some forensics to be done?
<tjaalton> sure
<tjaalton> gpg: error building skey array: Permission denied
<tjaalton> after import
<nacc> slangasek: to clarify, the first "runtime" above (first sentence) is referring to compile-time? And then the second part is if any binary packages need the same dep at runtime?
<tjaalton> superm1: I guess the socket thing doesn't work if $HOME is on nfs or such and simultaneously logged in on two machines..
<superm1> tjaalton: eek
<superm1> if it's on NFS do you have proper permissions as your user?
<slangasek> nacc: haha yes, sorry
<superm1> or possibly permissions are wrong and never noticed because you haven't written to .gnupg for a long time?
<nacc> slangasek: :) was a little worried I had no idea what runtime was anymore
<tjaalton> superm1: this is not on nfs, was speaking hypothetically :)
<nacc> slangasek: ok, doing a build-test now; is there a good way for me to verify locally it will build properly and packages will "live" in the right component?
<tjaalton> but yeah import gives that error
<slangasek> nacc: I'm sure Alice in Wonderland would clarify this for us
<slangasek> nacc: verify locally> ummm at this point just having main+universe in your sources.list is a valid test
<nacc> slangasek: ok, will post an updated debdiff shortly, hopefully
<superm1> tjaalton: okay well that's probably more useful then, add whatever you determine to the bug then
<stgraber> roaksoax: around?
<stgraber> roaksoax: that latest maas upload introduces two new udebs as arch:any but they don't contain binaries (or in fact anything), any reason they can't be arch:all?
<slangasek> nacc: php7.0, your merge drops debian/patches/0049-backport-89a43425.patch which seems to still be needed
<nacc> slangasek: grr, you're right, let me fix -- i mistook the sha1
<slangasek> nacc: shall I re-add locally?
<nacc> slangasek: about to post a new debdiff
<slangasek> nacc: ok
<nacc> slangasek: updated debdiff posted just now
<slangasek> nacc: great, uploading
<nacc> slangasek: thanks!
<nacc> slangasek: debian has moved on to 7.0.5, which has that bugfix, but i'll send them the wget dep change, so we should be able to sync at some point, if we get a dotrelease exception
<roaksoax> stgraber: no no reason at all. I'll change the arch for next upload if that's ok, or would you prefer I do one now ?
<stgraber> roaksoax: next upload is fine
<roaksoax> stgraber: k cool, thanks!
#ubuntu-devel 2016-04-08
<nacc> slangasek: quick general question for you, SRU related; there's an open bug for php5-apcu (LP: #1374892), and even the upstream maintainer says we shouldn't be shipping 4.0.2 (provided a +1 to update in the bug, c13). Debian ships 4.0.7-1 in stable for similar issues, afaict.
<ubottu> Launchpad bug 1374892 in php-apcu (Ubuntu) "Please backport php5-apcu version 4.0.6 to Ubuntu 14.04 LTS" [Undecided,Confirmed] https://launchpad.net/bugs/1374892
<nacc> slangasek: we have 4.0.7-ish in backports, but this bug is specifically about updating the official one
<sarnold> (upstream maintainers always say that :)
<nacc> sarnold: at least in this case, i think the extension crashes/hangs pretty easily
<nacc> sarnold: but that is a fair point
<sarnold> sometimes they're right :) but still
<nacc> sarnold: right, so i'd like to understand what i can do to figure it out
<slangasek> nacc: general process is https://wiki.ubuntu.com/StableReleaseUpdates; if you're asking about upgrading wholesale to 4.0.7, "current version is completely broken" is a good argument, but the update would still need to be regression tested for an SRU
<nacc> slangasek: yep, i was reviewing that; I will see what kind of testing I can do / ask the community to do
<infinity> nacc: I'm not at all against accepting an SRU on the "it's broken" grounds.
<infinity> If the one in backports has no dependencies in backports, we could just copy it over.
<nacc> infinity: yeah, i'm trying to get some clarity on if it fixes all the issues or not; there is one reporter who says some things are still broken
<nacc> infinity: most say it's better, at least (meaning it's usable)
<nacc> infinity: afaict, it has no deps in backports, but i'm trusting `reverse-depends -r trusty -c backports src:php-apcu` to tell me that, is that correct?
<infinity> nacc: Err, no, I meant the binary itself shouldn't have backports deps.
<infinity> nacc: As in, backports build-deps on backports, and can thus pull in deps that wouldn't be satisfiable in -updates (which would then mean we need a fresh build in -updates)
<infinity> Which is fine, but if we can use the backports binary, people have already tested that one and claimed it's not crap.
<nacc> infinity: oh i see
<nacc> infinity: i don't believe that's the case here; I will dig into it a bit tmrw
<pitti> Good morning
<alkisg> Good morning
<alkisg> It appears that Ubuntu's network-manager patches have something to do with the nbd-client's cyclic dependencies... (LP: #1487679)
<ubottu> Launchpad bug 1487679 in nbd (Ubuntu) "Breaking ordering cycle by deleting job nbd-client.service/start" [Undecided,Triaged] https://launchpad.net/bugs/1487679
<alkisg> I.e. that any sysvinit service that has "Required-Start: $network" is causing loops in Ubuntu, but not in Debian
<slangasek> nacc: php-horde-db tests regress with mysql-5.7
<seb128> cyphermox, did we get anywhere with the n-m 1.2 update?
<slangasek> nacc: php-sabredav also fails with an incompatibility between php-sabredav and some dependency
<pitti> alkisg: not "any" sysvinit service, but rcS ones; we've seen that happen in Debian too
<pitti> alkisg: most prominently with nfs-utils, as Debian's package still uses the single sysv script instead of the units
<pitti> this comes up on (Debian) IRC every so often
<pitti> slangasek: ^ speaking of which, do you plan to merge Ubuntu's nfs-utils changes to Debian? Or is that fodder for an NMU?
<slangasek> pitti: have the patches been sent to the BTS?  I haven't looked at nfs-utils at all recently
<alkisg> pitti: I don't think I can help there; it's way over my head! We'll just dpkg-divert nbd-client service until some fix is made available... :)
<pitti> slangasek: no, I don't think so; it's essentially the changes from 1:1.2.8-9ubuntu2 to ubuntu12, but as this keeps changing, patches are bitrotting quite fast
<slangasek> pitti:
<pitti> slangasek: i. e. if you plan to update Debian at all, I'm fine with massaging those for Debian (changelog cleanup, etc.)
<pitti> slangasek: and send them to some appropriate debian bug
<slangasek> pitti: I don't have any near-term plans, but a patch to the BTS would be helpful; there are comaintainers
<pitti> we don't want the upstart changes in Debian supposedly, as upstart is gone there
<slangasek> they don't hurt anything, and if it reduces the delta then I'd be for them
<pitti> ok; might use debian bug 765731, but I guess it's better to file a new one and refer to that and some others
<ubottu> Debian bug 765731 in nfs-kernel-server "nfs-kernel-server: Service ordering cycle under systemd" [Normal,Open] http://bugs.debian.org/765731
<pitti> slangasek: well, I suppose we won't keep them much longer either, do we? ubuntu touch won't need NFS
<pitti> maybe there's a new upstream version by now which incorporates these patches
<pitti> ah, 1.3.3
<pitti> so, updating to that would get rid of 90% of the patches already
<pitti> doko: new vim seems to break vim-addon-manager (http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#vim)
<pitti> currently checking if that's a real regression, or fallout from some ruby change
<pitti> E: Failed to fetch http://archive.ubuntu.com/ubuntu/dists/xenial/universe/source/Sources  Writing more data than expected (9699328 > 9651713)
<pitti> le what?
<ansgar> pitti: I think that error happens when apt gets a new InRelease, but old Packages/Sources (or the other way around).
<pitti> I consistently get it in my containers now, might be some fallout wrt. the recent "by-hash" enablement and apt-cacher-ng
<pitti> hm, still the same thing after cleaning /var/cache/apt-cacher-ng/uburep
<pitti> meh, this happens with a *completely clean* /var/lib/apt/lists and /var/cache/apt-cacher-ng/
<pitti> it's like something in the metadata contradicts with each other
<cjwatson> pitti: by-hash isn't advertised yet.  I suspect the contrary: your problem will go away once we advertise it :)
<cjwatson> pitti: Try with 'deb [by-hash=force] http://...' for the relevant sources.list line; I bet that fixes it
<cjwatson> pitti: Also, if you're running pre-xenial or non-Ubuntu apt-cacher-ng, see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=819852 for a config workaround you'll need to support by-hash
<ubottu> Debian bug 819852 in apt-cacher-ng "apt-cacher-ng: support by-hash index files" [Normal,Open]
<pitti> cjwatson: no, I have current xenial version with your patch
<cjwatson> pitti: OK, good, just try [by-hash=force] then
<cjwatson> apt-cacher-ng might have just decided to cache a stale Sources, or perhaps some other proxy in the way
<pitti> yay, works wonders
<pitti> cjwatson: well, I suspected that too, but if I stop acng, completely empty /var/cache/apt-cacher-ng/ and restart it, that shouldn't be the case any more
<cjwatson> pitti: could be something else on the network path between you and a.u.c
<pitti> cjwatson: thanks for the hint with [by-hash=force]!
<cjwatson> pitti: planning to turn it on by default today; I just want to check that deletion is working
<pitti> cjwatson: ah, I'm on the VPN, maybe there's some transparent proxy in between indeed
<pitti> doko: so, vim-addon-manager tests still succeed on current xenial and fail in that way in xenial-proposed, so this looks real
<alkisg> (10:20:01 ÏÎ¼) pitti: alkisg: not "any" sysvinit service, but rcS ones; we've seen that happen in Debian too ==> I tried *without* the S stage and got the issue... I.e. with a single "Required-Start: $network" and without a Default-Start (or with 2 3 4 5)
<alkisg> I had only the required-start: $network part with no other headers at all...
<doko> pitti, yes, see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=820313
<ubottu> Debian bug 820313 in vim-common "vim-addon-manager ftbfs (tests are failing)" [Serious,Fixed]
<zyga> re
<zyga> jdstrand: IT WORKS :-)
<rbasak> xnox: are you working on the rsyslog s390x FTBFS?
<xnox> rbasak, did not see that.
<xnox> rbasak, is there a bug number?
<doko> xnox, see the test rebuild
<rbasak> xnox: no, it's just in http://people.ubuntuwire.org/~wgrant/rebuild-ftbfs-test/test-rebuild-20160401-xenial.html
<xnox> doko, rbasak - did not go through s390x only ftbfs yet
<pitti> doko: ah, so that was fixed in vim itself
<doko> pitti, package in unapproved
<pitti> doko: no, it's not :-)
<pitti> doko: (i. e. accepted, thank you!)
<pitti> xnox: is it actually part of the specification that just about every tool and acronym on s390x is utterly unpronouncible? :-)
<xnox> pitti, yes Ram is Storage and etc.
<pitti> dasdfmt, fdasd, lpar, chzdev, this all sounds much more like "cat jumped on the keyboard" :-)
<xnox> pitti, do we need a guidelines of acronyms?
<xnox> pitti, dasdfmt -> DASD drive low level formatting for linux; fdasd - format dasd partition table on a dasd drive; LPAR - logical parition, e.g. a portion of a mainframe viewed as a single baremetal machine
<pitti> xnox: I figure zSeries' guidelines are "must contain at least 80% consonants and have a non-memorizable name"
<pitti> xnox: (no worries, j/k -- it's Friday afternoon)
<pitti> just spotted some more of this during unapproved review
<xnox> chzdev - CHange z device -> bring CCW (their unique bus, all devices are on CCW bus) devices online/offline (e.g. on/off switch for network cards, drives of all types)
<cjwatson> pitti: all right, can we do this by-hash thing?
<cjwatson> pitti: lp-shell production devel, then xenial = lp.load('/ubuntu/xenial'); xenial.advertise_by_hash = True; xenial.lp_save()
<pitti> cjwatson: I haven't heard of any problems
<pitti> cjwatson: Fri afternoon is the perfect time :)
<xnox> pitti, [ls|ch]*foo is quite common within s390-tools... and that's the thing to fiddle with stuff in /sys/ without going brain dead =)
<xnox> on all linuxes.
<cjwatson> totally :)  we have an easy circuit breaker to turn it off if it causes problems (i.e. just revert the above flag)
 * pitti pushes the button and sticks fingers in ears
<cjwatson> yay
<pitti> cjwatson: thanks and congrats, this is an amazingly nice feature
<pitti> "hash sum mismatch"-b-gone!
<cjwatson> fingers crossed.  there will be an assortment of problems with mirror scripts, but they should be no worse than previous behaviour
<jdstrand> zyga: woohoo! :)
 * jdstrand hugs zyga :)
<zyga> jdstrand: I'll ping you with two or three branches shortly
 * zyga just wasted 30 minutes debugging telepathy to see why irc is broken
<zyga> it seems that irc password is saved as a dbus type signature instead, some missing function call somewhere :P
<zyga> anyway...
<zyga> jdstrand: one critical thing is to get the template in line
<zyga> jdstrand: we have two options
<zyga> jdstrand: but I think for 16.04 we should just get rid of all unused variables
<zyga> jdstrand: and use "modern" names everyhwere
<zyga> jdstrand: I'll explain details in a sec, I have to go to a meeting
<jdstrand> zyga: (see my response in #snappy-- I'm not going to be available for several hours (many meetings, need prep, etc)
<jdstrand> )
<doko> xnox, should we kick out the separate boost-mpi source?
<xnox> doko, if universe got enabled, yes.
<xnox> doko, e.g. no-follow-build-depends
<xnox> but i'm not sure what the status there is.
<doko> hmm, true. currently only seen in component-mismatches
<cjwatson> xnox: it's done
<xnox> Set no-follow-build-depends feature, so packages in universe aren't pulled into main just because they are build-depends.
<xnox> yeay
<xnox> wow
<xnox> just wow
<xnox> i can't even believe we managed to do this =)
<xnox> i mean when i first used linux, archive reorg was an "acient thing that never got implemented"
<xnox> doko, so new boost needs to be uploaded that builds both main & universe packages, and then it should still correctly ship "mpi" bits into universe, and then we can purge boost-mpi package.
<pitti> mvo, juliank: I can't make much sense of bug 1560797 -- it seems after unpacking libgcrypt20, apt decides to try and configure systemd instead of configuring libgcrypt20 first
<ubottu> bug 1560797 in systemd (Ubuntu) "package systemd-sysv 225-1ubuntu9.1 failed to install/upgrade: libgcrypt20 was unconfigured" [Undecided,Confirmed] https://launchpad.net/bugs/1560797
<pitti> but all of libgcrypt20's deps are already configured, so there should be nothign that prevents libgcrypt20 configuration
<pitti> do you have any idea how to debug this further?
<pitti> (I wasn't able to reproduce this)
<pitti> oh, this uses libgcrypt20:amd64 *and* libgcrypt20:i386, maybe that will help to reproduce it
<pitti> slangasek, cyphermox, jibel: *phew*, we nailed bug 1554266; thanks to nuclearbob for being remote hands
<ubottu> bug 1554266 in UTAH "sshd does not start on newly installed desktop system" [Undecided,Triaged] https://launchpad.net/bugs/1554266
<cyphermox> what was it?
<pitti> see the last two bug comments
<pitti> TL;DR: installing a package while the boot was still going on
<cyphermox> oh, interesting
<pitti> which is highly timing dependent on how fast your network/disks are, i. e. whether booting finishes  first, or download/unpack
<pitti> i. e. time bomb :)
<cyphermox> well, not just boot..
<pitti> and allegedy the CI lab was moved to a faster network recently
<cyphermox> this would be running after boot, towards the end (or at least the middle) of installation
<cyphermox> so if systemd thinks it's still in a boot phase, we have something wrong in the ubiquity-dm service
<pitti> cyphermox: Max will put it back into the OS install, in late_command
<cyphermox> ok
<pitti> cyphermox: but right now rc.local calls apt-get install
<pitti> which is *during* boot
<cyphermox> mmkay
<cyphermox> well, that's not fixing the bug
<pitti> (I suggested an alternative approach with waiting until the boot is finished, but Max knows this stuff better)
<pitti> so installing openssh-server as part  of installing the OS instead of during first boot sounds fine
<pitti> and apparently it used to be that way, but it was changed some time ago
<cyphermox> pitti: installing openssh was already being part of the install, and that was not working
<pitti> anyway, we have an explanation and two proposals now
<cyphermox> well, we'll see, I'm not holding my breath
<cjwatson> Laney: is there some way to get appstream to say what it actually means when it says "AppStream cache update completed, but some metadata was ignored due to errors" ?
<Laney> cjwatson: Ummmmmmmmmmmmm
<Laney> I think there's an appstreamcli subcommand for that
<gQuigs> cjwatson: interesting - http://pastebin.ubuntu.com/15688945/
<cjwatson> OK, so it actually means errors inside the metadata tarball?
<Laney> I don't see it here
<cjwatson> Yeah, seems so here
<cjwatson> In that case I don't care - I just wanted to make sure it wasn't a problem prompted by by-hash
<Laney> but it sounds like it comes from appstreamcli refresh-index
<Laney> ah I probably don't have the new appstream from yesterday
<cjwatson> https://paste.ubuntu.com/15688991/ here
<cjwatson> also worth noting there that it's downloading both from my local mirror and from the archive
<cjwatson> so perhaps that's the cause of colliding ids?
<Laney> Yeah, don't think that particularly matters
<Laney> I would guess it's the warning
<Laney> I'll look into it, thanks for the report
<gQuigs> cjwatson: so apt-get update hangs for me.. new problem as of today...
<gQuigs> http://pastebin.ubuntu.com/15689150/
<gQuigs> but I can browse to the archive website fine...
<gQuigs> cjwatson: and it's my fault, nevermind
<nacc> slangasek: ok, will investigate those
<morphis_> does anybody know if I can tell launchpad to not truncate diffs on a merge proposal?
<teward> morphis_: #launchpad may be able to answer that better
<dobey> morphis_: you cannot
<teward> or that
<morphis_> dobey, teward: thanks .. that somehow makes reviews superflous with MPs if people can't really comment on the whole thing in line
<nacc> rbasak: might need your help on these php regressions, too; default mysql permissions seem to be denying root@localhost
<dobey> morphis_: e-mail works fine. the e-mail has the whole diff
<rbasak> nacc: there are two possibilities for that.
<morphis_> dobey: sure
<dobey> but yeah, not nice for in-line replies on the web site
<rbasak> nacc: first is that you're setting an empty root password, possibly by installing non-interactively. In this case login as MySQL root by a non-root Unix user is no longer permitted. I can understand this might impact testing.
<nacc> rbasak: ok, i can update the tests; that's almost certainly what this module does (presumably the default?)
<rbasak> nacc: second is that there's currently a bug that prevents dpkg-reconfigure from setting a root password later if it is originally unset. We'll have a fix for that early next week.
<nacc> rbasak: ok, i'll reproduce locally and let you know
<nacc> rbasak: thanks for the quick response!
<rbasak> nacc: one final thing. Another bug: if ~/.my.cnf or ~root/.my.cnf exists at the time the mysql postinst is run, it interferes with the initial configuration of the database. We should have a fix for that early next week too.
<nacc> rbasak: yeah i saw that yesterday; for the first case is there a config option i can tweak or is that permanently disabled?
<rbasak> nacc: no config option currently. Perhaps there should be one You could work around by tweaking the config as root before going non-root, but I'm not sure if that'll stay when the postinst runs again.
<nacc> rbasak: right, will just verify if that's the issue, at least
<nacc> rbasak: this is in an autopkgtest, fwiw
<rbasak> nacc: does it run as root or non-root? Ie. does it have a Restrictions: needs-root?
<nacc> rbasak: it has needs-root
<rbasak> nacc: then you might be able to work around in the autopkgtest by switching the auth type back to password for the root user
<rbasak> It's OK for a test to have an empty password I guess.
<Skuggen> If it's run as root it'll log in successfully even if you specify a password that's not valid (if the auth_socket is set)
<nacc> it could easily be some bug in the php-mysql implementation relative to mysql 5.7, so want to eliminate one thing at a time :)
<nacc> rbasak: quick reference on how to do that?
<Skuggen> nacc: Switching auth back to password?
<nacc> Skuggen: yep
<Skuggen> Can you log in as root at the start of the test?
<Skuggen> To switch it back, right now you have to log in and run "ALTER USER 'root'@'localhost' IDENTIFIED WITH 'mysql_native_password' IDENTIFIED BY 'somepassword'";
<nacc> Skuggen: let me see
<Skuggen> If you've installed in noninteractive so password was blank, any attempt to log in as mysql-root as unix-root should succeed
<nacc> rbasak: ah i see, the test runs as root to set up the db, then drops to www-data :/
<nacc> Skuggen: yes, logging in as root w/o password does work by default
<nacc> so i think it's something elese
<Skuggen> For ruby-mysql we used that setup to create a separate user to use for the rest of the tests
<Skuggen> Could you just put up the test setup on pastebin or something (I'm not at a worky-computer)
<nacc> Skuggen: http://paste.ubuntu.com/15690307/
<nacc> Skuggen: i think that it's the exported CONFIGs
<nacc> that specify to use root w/o password
<nacc> for the www-data user (given --preserve-environment)
<Skuggen> "mysql -e 'create database IF NOT EXISTS test;' -uroot" If you just add the query I pasted above after ;, I think it should work
<Skuggen> Though erase somepassword
<nacc> Skuggen: ok, let me try
<nacc> Skuggen: putting IDENTIFIED BY '' threw an error: "You have an error in your SQL syntax"
<Skuggen> Are you using the same quotes you put around the entire query?
<nacc> Skuggen: http://paste.ubuntu.com/15690484/ ?
<Skuggen> Hm, maybe it needs the ; at the end
<Skuggen> i.e. after identified by ''
<nacc> nope
<nacc> :)
<Skuggen> Does it give a syntax error if you have an actual password?
<nacc> yeah, the same one, i think
<nacc> Skuggen: no second IDENTIIFIED
<nacc> Skuggen: IDENTIFIED WITH ... BY ...
<Skuggen> Aah
<nacc> Skuggen: great, tests pass now, thanks!
<Skuggen> \o/
 * mvo hugs cjwatson for landing by-hash in LP
<cjwatson> mvo: thanks for the apt side!  that reminds me, meant to credit you in my blog post
<cjwatson> mvo: oh, thanks for merging my apt-ddtp-tools branch.  did you see my request for a ddtp-translations upload with that?
<mvo> cjwatson: I was just importing the latest debian translations and will upload in  a bit
<mvo> cjwatson: its a bit slow (the generation of the files)
<cjwatson> ah, ok, cool
<mvo> cjwatson: thank you for the branch :) i18n back in xenial.
<nacc> slangasek: i think i figured out the sabredav failure as well; it might have been relying on a buggy php behavior with the default include path, testing now
<cyphermox> pitti: is there a way to tell systemd to not  try to automatically activate swap for a period of time?
<nacc> Pharaoh_Atem: is it possible to build a pear extension with debug symbols as part of `pear/pecl install` ?
<nacc> ha! faked it with export CFLAGS= :)
<pitti> cyphermox: several, but the simplest one is certainly to comment it out from /etc/fstab or add "noauto" to iit
<pitti> cyphermox: or systemctl mask your-swap-unit.swap (check systemctl --all -t swap)
<cyphermox> it wouldn't be in /etc/fstab
<cyphermox> it's detected swap in the live session
<pitti> cyphermox: oh, GPT?
<cyphermox> err, maybe, I don't know?
<pitti> systemd-gpt-auto-generator(8) runs at boot and autodetects swap partitions
<pitti> there's no auto-detection that I know of for MBR
<pitti> cyphermox: can you describe this in some more details in a bug report or mail or so, and I'll look at it next week? sorry, gotta run now
<cyphermox> pitti: there's a bug already, I'll send you the link by email
<Pharaoh_Atem> nacc: I've not been able to myself
<Pharaoh_Atem> afaik, pear stuff explicitly is pure-php, so there's no debug stuff to get
<nacc> Pharaoh_Atem: ok, it did work for me, trying to debug a php5 sigill with redis
<Pharaoh_Atem> hmm
<nacc> Pharaoh_Atem: ok, this was pecl
<Pharaoh_Atem> ah
<pitti> cyphermox: ah, just subscribe me, I get that bug mail into the right folder
<nacc> Pharaoh_Atem: which `pear` wraps if you do an 'upgrade-all'
 * pitti runs, good weekend everyone!
<Pharaoh_Atem> ohh
<Pharaoh_Atem> I've had trouble getting the debug stuff to register when trying to do it myself with libvirt-php stuff
<nacc> Pharaoh_Atem: export CFLAGS seems to work for php-redis, at least
<nacc> Pharaoh_Atem: what's the status on libvirt-php, btw?
<Pharaoh_Atem> I got a colleague to write up a good number of unit tests, eclipsing the current set from before
<Pharaoh_Atem> and I'm preparing to push that work to my GitLab and send a patch series to the libvirt mailing list
<nacc> Pharaoh_Atem: great!
<Pharaoh_Atem> from what I can tell, it works fine in php5 and php7
<Pharaoh_Atem> so at least nothing is *more* broken than before
<nacc> Pharaoh_Atem: which is something :)
<slangasek> nacc: https://launchpad.net/ubuntu/+source/php-horde-db/2.3.1-1ubuntu2/+build/9552276
<nacc> slangasek: "chroot problem"?
<slangasek> nacc: oops that's a chroot problem, nevermind
<nacc> slangasek: also, i got a couple of emails with hash sum mismatches for php-sabredav
<slangasek> oh?
<nacc> https://launchpad.net/ubuntu/+source/php-horde-db/2.3.1-1ubuntu2/+build/9552276/+files/buildlog_ubuntu-xenial-amd64.php-horde-db_2.3.1-1ubuntu2_BUILDING.txt.gz
<slangasek> maybe somebody else tried to sponsor you in parallel
<slangasek> for the chroot problem, that's obviously the chroot's problem, not yours :-)
<nacc> slangasek: sorry, in the repo itself, looks to be the translations
 * Pharaoh_Atem double checks to make sure libvirt is new enough
<Pharaoh_Atem> yep, we're good on xenial libvirt
<Pharaoh_Atem> I found out the hard way that trusty's libvirt is too old
<cjwatson> nacc,slangasek: oh, heh, I see why this is still happening even after deploying by-hash
<cjwatson> the xenial chroots are still copies of the wily ones, and wily's apt is too old to support by-hash
<cjwatson> so until the initial upgrade runs, the buildd's apt doesn't support by-hash yet
<slangasek> hah
<cjwatson> infinity: please could you update the xenial chroots sometime *before* we release? :)
<juliank> pitti: This APT ordering thing looks awful, but I don't know what to do about it. Maybe there's a complicated pre-depends or conflicts/breaks cycle somewhere?
<cjwatson> (the above is with the exception of s390x, which has been updated rather more recently and of course didn't exist in wily)
<juliank> And yes, the ordering code is somewhat suboptimal
<slangasek> juliank: systemd-sysv Pre-Depends: systemd which probably has to do with it, but I don't see any cycles that would force apt to configure this before libgcrypt20
<juliank> There probably is no sane-ish reason to do that, ordering is just somewhat broken in some places.
<slangasek> heh
<slangasek> APT, Approximate Package Tool? ;)
<nacc> cjwatson: oh i see
 * elbrus wonders if Debian bug 820475 applies to Ubuntu's php7.0 as well (which would mean a regression)
<ubottu> Debian bug 820475 in php7.0 "php7.0: php5 to php7.0 regression: undefined function xml_parser_create()" [Normal,Open] http://bugs.debian.org/820475
<elbrus> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=820475
 * elbrus has no Ubuntu system to check...
<slangasek> elbrus: it is a "regression" in the sense that the packaging of php7.0 deliberately moves the xml module into a separate binary package instead of carrying it as a builtin.  It looks like cacti needs to add a dep on php-xml now, which I don't see was done yet in Ubuntu - nacc can probably help make that happen
<elbrus> slangasek: good to know...
<elbrus> and thanks for looking into it.
 * elbrus will close the Debian bug than as well
<slangasek> no problem, sadly I have a visual trigger on php at the moment ;)
<elbrus> sadly for you, great for me in this case
<elbrus> (and for cacti in Ubuntu)
 * elbrus confirms that installing php-xml does the trick in Debian/unstable
 * elbrus is adding an autopkgtest to cacti, that is how I found out
<slangasek> wahoo, +1 for autopkgtest
<elbrus> slangasek: do you recognize "Call to undefined function mb_strlen"? is that also in an other package now, or is that just deprecated?
<slangasek> elbrus: yes, also split out - php-mbstring if I remember the name
<elbrus> slangasek: great thanks... nacc: will you pick up these dependencies for cacti in Ubuntu?
<elbrus> hmm, installing php-mbstring didn't seem to solve it, but than again, installing the php package doesn't trigger apache to reload/restart... is that a bug or a feature?
<sarnold> imho seems like a feature; there's dozens of ways php can be used and not all of thm even require a web server
<elbrus> sarnold: I feared that...
<Unit193> I have php but not apache.
<elbrus> aha, I guess as a dependency, it is resolved of course in postinst.
<elbrus> when doing stuff for apache...
<elbrus> yeah... php7.0 and cacti now work (on Debian)
<elbrus> at least according to my wget call...
<nacc> elbrus: what's up? cacti depends on mbstring and xml?
<nacc> elbrus: slangasek: debdiff attached to LP: #1568136
<ubottu> Launchpad bug 1568136 in cacti (Ubuntu) "cacti depends on xml and mbstring extensions at runtime" [Undecided,New] https://launchpad.net/bugs/1568136
<nacc> elbrus: thanks for the report, i had tested the basic functionality you had mentioned in the other bug but nothing else (I rarely know how to test php applications unless they have autopkgtests :)
<nacc> slangasek: so i think (based upon my reading of excuses) php7.0 should be a valid candidate now?
<slangasek> nacc: IFF it says 'Valid candidate' at the bottom of the stanza :)
<slangasek> I still see the php-sabredav, php-horde-db failures
<nacc> slangasek: they haven't been rerun w/ the current version?
<slangasek> nacc: that *may* be because I tripped over syntax and only retriggered for ppc64el
<nacc> slangasek: as php-sabredav already migrated, and php-horde-db is a valid candidated
<nacc> slangasek: ah could be, i see it doesn't indicate ppc64el failed anymore
<slangasek> nacc: yes, that only means that new php-sabredav and new php-horde-db passed their tests with current php-defaults in xenial; now it's the cross-test that's needed, triggered now
<nacc> cjwatson: just did an `apt-get update` at home, and got some DEP-11 hash sum mismatches from my local mirror. Is that a case of propogation taking some time, or do i need to clear my local cache for the by-hash change?
<infinity> (base)adconrad@nosferatu:~$ grep Acquire /var/lib/apt/lists/*Release
<infinity> /var/lib/apt/lists/us.archive.ubuntu.com_ubuntu_dists_xenial_InRelease:Acquire-By-Hash: yes
<infinity> nacc: You have that?
<infinity> cjwatson: Erm, is it intentional or a bug that the post-release pockets don't have A-B-H set?
<infinity> cjwatson: Or is there some clever plan to flip state when we go from pre-release states to released states, and turn off by-hash on the release pocket and turn it on on post-release pockets?  (which would actually make sense, the hashes are useless on a frozen pocket, just wasted space)
<nacc> infinity: hrm, no, not set, nm
<infinity> nacc: Right, if it's not set, then your mirror is out of date.
<nacc> infinity: yep, makes sense
<infinity> (base)adconrad@nosferatu:~$ grep ^Date /var/lib/apt/lists/*Release
<infinity> /var/lib/apt/lists/us.archive.ubuntu.com_ubuntu_dists_xenial_InRelease:Date: Fri, 08 Apr 2016 21:02:46 UTC
<infinity> /var/lib/apt/lists/us.archive.ubuntu.com_ubuntu_dists_xenial-security_InRelease:Date: Wed, 03 Feb 2016 15:23:44 UTC
<infinity> /var/lib/apt/lists/us.archive.ubuntu.com_ubuntu_dists_xenial-updates_InRelease:Date: Wed, 03 Feb 2016 15:23:44 UTC
<infinity> cjwatson: Oh, I see.  Not so much bug as feature, since the post-release xenial pockets haven't been dirty (and thus, not republished) since Feb 03. :P
 * infinity wonders what made them republish in February...
<nacc> infinity: yep (note needed `grep -r`, as it's partial here, maybe due to the mismatch?) but mine is at 8 Apr 3:00 UTC, quite out of date
<infinity> nacc: Yeah, partial/ is where temp files go, and move to .. when they're validated to be good and shiny and true.
<nacc> infinity: makes sense!
<nacc> infinity: thanks!
<infinity> nacc: So yeah, if your mirror is on a 24h sync schedule (not uncommon), you'll likely see it all happy tomorrow.
<nacc> infinity: yep
<Pharaoh_Atem> nacc: https://www.redhat.com/archives/libvir-list/2016-April/msg00402.html :P
<infinity> nacc: And this, incidentally, is why we always include security.ubuntu.com in the default sources.list.  So your local mirror can be wildly out of date, and you still get 99% of packages from it, but you don't end up lagging on security updates.
<nacc> infinity: yep, that makes total sense and is obvious now :)
<nacc> infinity: good policy :)
<nacc> Pharaoh_Atem: nice! i look forward to seeing that get rolled out :)
<Pharaoh_Atem> nacc: welp, you can pull it in if you want :P
<nacc> Pharaoh_Atem: well, i'd rather wait til it's at least in the libvirt repo
<Pharaoh_Atem> :/
<Pharaoh_Atem> I hope they review it quickly, then
<nacc> Pharaoh_Atem: mostly because i don't want churn or if they reject it
<Pharaoh_Atem> yeah, I get it
<nacc> Pharaoh_Atem: it's one of our known-broken cases, i'd rather we fix it right when we do fix it
<Pharaoh_Atem> okay
<Pharaoh_Atem> but at least you can notate that a fix IS coming
<nacc> true, i'll update the pad with that link :)
<Pharaoh_Atem> I have a newfound disgust for the internals of php
<Pharaoh_Atem> the sheer amount of weirdness involved in php has been staggering
<nacc> Pharaoh_Atem: ack
<nacc> Pharaoh_Atem: pad updated with links for the three outstanding packages
<cjwatson> infinity: Yeah, it'll happen when they're republished.  Not really worth the effort to forth it.
<cjwatson> *force (where did that come from?)
<infinity> cjwatson: Lithp?
<infinity> cjwatson: Right, I sorted that out from my looking at Release file timestamps.
<infinity> cjwatson: But then that leads to the other question, would there be value in un-hashing release pockets on state change, so we're not carrying a bunch of pointless redundant versions of all the Packages/Sources/etc files?
<cjwatson> infinity: No - we'll end up rerunning just the Release file pass a couple of times post-release to reap old by-hash files.
<cjwatson> infinity: Not necessarily immediately after xenial, but in the not too distant future in order to enable Valid-Until.
<infinity> cjwatson: Okay, so we'll have the "pointless" copies of the final files, but not the pointless history.
<cjwatson> I'd rather have everything ultimately end up being by-hash for consistency.
<infinity> Yeah, that's fair.
<infinity> The copies of the shallow revision aren't too bad, it's the history frozen in time that would be icky.
<slangasek> oh, Valid-Until
<cjwatson> infinity: They're also hardlinks rather than copies, at least on the master.
<infinity> cjwatson: Ahh, right.
<cjwatson> Probably not on mirrors though because rsync -H is fairly expensive
<infinity> cjwatson: Indeed, we've had that conversation.
<infinity> cjwatson: But at least on master, wacking the history is enough to reclaim waste.
<infinity> On mirrors, meh.  It's a ton of space, but not relative to the archive size.
<cjwatson> Quite.
<infinity> cjwatson: I'm going to assume you had to submit some fun patches to magicmirror to make the arch split not vomit?
<infinity> Actually, how would that even work?  Since magicmirror's whole thing is "delete if not referenced", and all but the latest hash aren't referenced by anything...
<cjwatson> infinity: No, for a change it didn't need any changes.  The by-hash directories are all immediately alongside the by-name versions, so you have dists/xenial/main/binary-amd64/by-hash/...
<infinity> Stay of execution on by-hash/* I guess.
<cjwatson> Dunno but it totally has a ton of them.
<infinity> Oh, maybe the reference magic is only for pool/
<infinity> And dists is just assumed correct and synced wholesale (except for the /$arch/ filter)
<cjwatson> Yeah, looking that way to me.
<cjwatson> The timestamp magic can all go away, and I submitted an MP for that a while back that hasn't been reviewed yet, but it doesn't matter for by-hash.
 * infinity nods.
<infinity> cjwatson: Oh, and I'll update the chroots.  I kinda forgot to care after you wrote bootstrap-package, and then I almost saw it as a feature, since the base system dist-upgrade helped me catch and fix a couple of bugs during the cycle. :P
<cjwatson> Heh.  Thanks.
<infinity> If I can find a spare moment to breathe, I'll automate chroot building in LP/+livefs for 16.10
<infinity> With some sort of post-build validation magic, so I can upload them without fear.
<tkamppeter> infinity, hi
<infinity> tkamppeter: Hey.
<tkamppeter> infinity, did you already look into the LSB printer driver problem?
<infinity> tkamppeter: Not yet, but it's on my list before release.
<tkamppeter> infinity, OK.
<nacc> slangasek: started working (or was going to) on my dev application, but the wiki seems to hate me :)
<nacc> slangasek: will work on it next week, so hopefully will have to pester you a lot less at some point
#ubuntu-devel 2016-04-09
<sarnold> nacc: logout/login again
<nacc> sarnold: yeah, that gave some 500s and other errors
<nacc> sarnold: it worked again after a bit :)
<sarnold> nacc: ooh fun! :)
<nacc> sarnold: :)
<slangasek> ginggs: when syncing packages for a lib transition, just a reminder to check that the lib package is built and published on all archs first; uploading no-change rebuilds of gimagereader,openalpr now for arm64+armhf
<Unit193> nacc: So wait, I can start pestering you soon? :D
<nacc> Unit193: well, pending approval eventually :)
<ginggs> slangasek: thanks, i did wait and check with rmadison, but must have missed something
<ogra_> cjwatson, infinity, something is behaving very weird regarding PPA packages and seeds today ... could that be related to archive re-org ?
<cjwatson> ogra_: can you please give more details?
<ogra_> cjwatson, i uploaded a 0.7.41~ppa1 version to the snappy PPA earlier (deleted it again since that breaks images) ... from that moment on the build didnt pull it in with the normal seed anymore ...
<cjwatson> ogra_: Builds don't know about seeds at all.  Do you have the URL to the build?
<ogra_> i have some hook scripts that apt-get install that pakcage when producing the kernel snaps ... there it is found and actually pulled in from the PPA
<cjwatson> ogra_: I can only investigate this if you point me to a build log or something.
<ogra_> any of https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/xenial/ubuntu-core-system-image/ ... if you look for initramfs-tools-ubuntu-core in one of teh build logs, you will see it doesnt get installed during the normal seed installation, only later
<ogra_> (i dont have a working log on that page anymore since i did a lot of re-builds today ...)
<ogra_> if yu can find the one for 20160409 it should be a good one for comparison
<ogra_> the first mentioning of the package is in:
<ogra_> + dpkg -s initramfs-tools-ubuntu-core
<ogra_> + sed -n /^Version:/{s/^[^: ]*: \([^: ]*\).*/\1/;p;}
<ogra_> dpkg-query: package 'initramfs-tools-ubuntu-core' is not installed and no information is available
<cjwatson> ogra_: Which PPA in particular do you mean?  ppa:snappy-dev/ubuntu/image ?
<ogra_> (which obviously should error out when it cant find the package)
<ogra_> yeah
<ogra_> as i said, i removed the package now
<cjwatson> ogra_: And what was the package name that you uploaded?
<ogra_> initramfs-tools-ubuntu-core
<cjwatson> You could save me a lot of time by not making me play twenty questions here :P
<ogra_> sorry
<ogra_> what i uploaded is the same thing thats in the xenial queue now ...
<ogra_> (but with a ~ppa1 suffix)
<cjwatson> oh right, you're relying on Task fields to get this package installed?
<cjwatson> (can't be seeds, but could be Task fields derived from seeds)
<ogra_> yes, no metapackage for snappy
<cjwatson> ah well, there you go
<cjwatson> PPAs have never had Task fields generated for them *shrug*
<cjwatson> nothing to do with the recent reorg
<ogra_> well
<ogra_> why does it not pick the archive version then ?
<ogra_> it simply drops the package
<cjwatson> presumably because it looks at latest versions of things before it considers Task, I don't know
<ogra_> (and i'm pretty sure it worked before)
<cjwatson> but it's not new
<cjwatson> if it worked before then either apt behaved subtly differently or (more probably) the package was also pulled in by a dependency from something else that still had its Task field
<cjwatson> all this stuff is undefined
<ogra_> hmm, k
<cjwatson> if you want predictable behaviour then you'll probably have to use a metapackage
<cjwatson> or I suppose you could hardcode the Task field just in the PPA upload
<cjwatson> evil but would work for temporary testing
<ogra_> in debian/control ?
<cjwatson> yes, in the binary stanza
<cjwatson> might need to be XB-Task, I don't quite recall
<cjwatson> anyway, I have to go again, good luck
<ogra_> k ... well, i dont think i'll use it ... the thing i wanted to test sits in the queue now ... but i'll note it down
<cjwatson> darkxst: FYI (from #ubuntu-mirrors) there's an apt-cacher-ng config workaround linked from my latest blog post
<cjwatson> darkxst: https://bugs.debian.org/819852
<ubottu> Debian bug 819852 in apt-cacher-ng "apt-cacher-ng: support by-hash index files" [Normal,Open]
<darkxst> cjwatson, thanks!
#ubuntu-devel 2016-04-10
<karstensrage> why was systemd so quickly adopted?
<karstensrage> seems a lot of people hate it
<darkxst> how do I get pam to spew debug messages? no matter what I try it seems mute (auth    [success=1 default=ignore]      pam_unix.so nullok_secure) does not work under gdm
<loganaden> hoi
<Unit193> pitti: But 1488962 only fixes it for apache.
<leonn> hi, iâve reported this bug that breaks apticron in xenial https://bugs.launchpad.net/ubuntu/+source/apticron/+bug/1562229
<ubottu> Launchpad bug 1562229 in apticron (Debian) "apticron fails when mailx is provided by s-nail" [Unknown,Confirmed]
<leonn> iâm not sure if this would be eligible for a fix this late in the cycle, but if it is, iâm wondering if thereâs any way i can increase the change for a fix in time for the release
<leonn> like, any tags i should add or so
<infinity> leonn: https://launchpad.net/ubuntu/+source/apticron/1.1.58ubuntu1
<leonn> infinity, oh wow, thatâs the most helpful reaction :-)
<leonn> thanks!
<infinity> NP.
<infinity> xnox:
<infinity> â cpacfstatsd.service - CPACF statistics collection daemon process for Linux on System z
<infinity>    Loaded: loaded (/lib/systemd/system/cpacfstatsd.service; enabled; vendor preset: enabled)
<infinity>    Active: failed (Result: resources) since Sun 2016-04-10 19:44:31 UTC; 11min ago
<infinity>      Docs: man:cpacfstatsd(8)
<infinity>   Process: 500 ExecStart=/usr/sbin/cpacfstatsd (code=exited, status=0/SUCCESS)
#ubuntu-devel 2017-04-03
<ejat> hi
<ejat> apt: relocation error: /usr/lib/x86_64-linux-gnu/libapt-private.so.0.0: symbol _ZN13pkgSourceList16AddVolatileFilesER11CommandLinePSt6vectorINSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEESaIS8_EE, version APTPKG_5.0 not defined in file libapt-pkg.so.5.0 with link time reference
<ejat> anyone can help ?
<cardboard64> hi
<cardboard64> I'm running 17.04 RC and wings3d crashes at startup
<cardboard64> here's the crash log: https://paste.ubuntu.com/24305708/
<cardboard64> it seems that wings3d depends on erlang-wx
<cardboard64> which requires libpng12.so
<cardboard64> which is not in the repos
<jtaylor_> cardboard64: how do you come to that conclusion?
<cardboard64> running wings3d binary downloaded from the official website
<cardboard64> though, that may not be correct
<jtaylor_> that may just still be using libpng12
<cardboard64> I installed libpng12 and now only wings3d from the ubuntu repos won't launch
<jtaylor_> slangasek: ^ ubuntu erlang is missing wxe_driver.so, debian has it though, probably needs 1:19.1.6+dfsg-2 merged
<jtaylor_> debian bug 844593
<ubottu> Debian bug 844593 in erlang-wx "erlang-wx: WX broken due to "-fno-pie -no-pie" CFLAGS/LDFLAGS" [Grave,Fixed] http://bugs.debian.org/844593
<infinity> doko: So... gnat on ppc64el and s390x.  Seems to be in some state of half transition.  Do you know how to unwind this?
<infinity> doko: For example, https://launchpadlibrarian.net/314204021/buildlog_ubuntu-zesty-ppc64el.anet_0.3.3-1ubuntu2_BUILDING.txt.gz
 * infinity tries uploading ahven first.
<slangasek> jtaylor: 19.1.6+dfsg-2 seems to be superseded by 19.2.1+dfsg-2 now, however, so rather difficult to merge it?
<jtaylor_> slangasek: update then, it is an rc bug in debian so its probably still worthwhile
<slangasek> fair
<jtaylor_> but its of course up to you and your schedule, I have the excuse of not being able to upload to main :P
<infinity> doko: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=837162 is definitely not fixed.
<ubottu> Debian bug 837162 in gcc-6 "dh-acc: Testing C++ headers with dh-acc results in: function body not available" [Important,Open]
<tinoco> could someone publish (proposed -> updates) fix for LP: #1317491 for UA for me ?
<ubottu> Launchpad bug 1317491 in libvirt (Ubuntu Trusty) "virsh blockcommit hangs at 100%" [Medium,Fix committed] https://launchpad.net/bugs/1317491
<tsimonq2> Ugh, systemd-resolved broke my system AND my VM
<tsimonq2> ffs >__< /o\
<tsimonq2> Wait, not my host system. I'm mistaken with that.
#ubuntu-devel 2017-04-04
<jamespage> slangasek: hi - thanks for poking bug 1678574 my way
<ubottu> bug 1678574 in percona-xtrabackup (Ubuntu Zesty) "percona-xtrabackup wrong mysql socket path" [High,In progress] https://launchpad.net/bugs/1678574
<jamespage> slangasek: fix uploaded to zesty and in the queue for xenial and yakkety - oversight on my behalf that was not picked up during testing because percona-xtradb-cluster dtrt with regards to setting the socket path in config files.
<rbasak> [16:03] <stgraber> ACTION: slangasek to investigate getting tagged ubuntu-community bugs automatically forwarded to technical-board, and if not feasible, fall back to DMB sending signed emails to list for ACL requests
<rbasak> [16:07] <stgraber> #topic Scan the mailing list archive for anything we missed (standing item)
<rbasak> [16:07] <stgraber> not seeing anything that needs to be brought up in this meeting
<rbasak> You missed my request :-/
<rbasak> https://lists.ubuntu.com/archives/technical-board/2017-March/002292.html
<rbasak> Please could you take a look?
<tinoco> could someone release LP: #1317491 for me ? (Trusty only)
<ubottu> Launchpad bug 1317491 in libvirt (Ubuntu Trusty) "virsh blockcommit hangs at 100%" [Medium,Fix committed] https://launchpad.net/bugs/1317491
<Laney> rbasak: I'm watching that budgie thread on devel-permissions - any reason why it's not an automatically generated flavour packageset?
<rbasak> Laney: good point.
<cyphermox> Laney: there isn't, I'm pretty sure it was brought up (maybe not so clearly), but it should be an automatically generated flavor packageset.
 * Laney nods
<Laney> Just wanted to nudge. :P
<rbasak> Appreciated :)
<shadeslayer> stgraber: something about lp 1675163 breaks makedev in a docker container
<ubottu> Launchpad bug 1675163 in makedev (Ubuntu Zesty) "Don't attempt to create devices in LXC containers" [High,Fix released] https://launchpad.net/bugs/1675163
<shadeslayer> stgraber: http://mobile.neon.pangea.pub:8080/job/mgmt_docker/label=do-builder-002/2200/console
<shadeslayer> 14:41:56 Setting up makedev (2.3.1-93ubuntu2~ubuntu16.04.1) ...
<shadeslayer> 14:41:56 mknod: mem-: Operation not permitted
<Guest92659> hi...does anybody know whay gnome is using for gui testing?
<shadeslayer> stgraber: perhaps that whitelist in the diff should also check for docker containers, not just lxc
<sladen> ~
<juliank> Anyone know what's up with the ubiquity autopkgtests? Started failing with gnupg2/2.1.15-1ubuntu7 on Mar 31, and now failed for apt/1.4 - error being AssertionError: 'in\ttam' != 'lk\ttam_unicode'
<juliank> (The other, non-ubiquity, tests passed, so apt seems ready to go IMO)
<stgraber> shadeslayer: possibly. I don't know Docker enough to know how to detect it though and frankly don't really care enough about it to do another round of SRUs for it :)
<stgraber> shadeslayer: my change didn't cause this problem, any makedev upgrade would have caused it, I guess docker worked okay so far just because makedev hasn't been updated for years
<shadeslayer> stgraber: yes, any change would have most likely caused it :)
#ubuntu-devel 2017-04-05
<Harris> I want to make a custom install of elementary os which is based on ubuntu... is there a ubuntu base file that has 0 programs installed just the os
<valorie> Harris: there is a mini-iso
<valorie> !mini-iso
<valorie> phooey
<valorie> one can make a custom ISO as well
<valorie> !iso
<ubottu> To mount an ISO disc image, type Â« sudo mount -o loop <ISO-filename> <mountpoint> Â» - There is a list of useful cd image conversion tools at http://wiki.linuxquestions.org/wiki/CD_Image_Conversion - Always verify the ISO using !MD5 before !burning.
<valorie> https://help.ubuntu.com/community/Installation/MinimalCD
<valorie> also there is netboot
<valorie> !netboot
<ubottu> Ubuntu can be installed in lots of ways. Please see https://help.ubuntu.com/community/Installation for documentation. Problems during install? See https://wiki.ubuntu.com/CommonProblemsInstall - Don't want to use a CD? See http://tinyurl.com/3exghs - See also !automate
<Harris> i need a base image though
<valorie> the mini-iso, as I said above
<krytarik> Harris: This might be what you're looking for: https://wiki.ubuntu.com/Base
<bdrung_work> Trevinho, ping (regarding #1671432)
<rbasak> cpaelzer: argh. Bileto publishes Zesty at the same time as the SRUs? I was expecting to do Zesty only. Haven't actually reviewed the SRUs yet.
<cpaelzer> cpaelzer: I'd have expected to give some choice which to pub
<cpaelzer> rbasak: ^^
<cpaelzer> talkign to myself
<cpaelzer> rbasak: but eventually it is not too wrong either, the zesty publish will have to move on and has to pass z-p as usual
<cpaelzer> rbasak: and while doing so the others stick in unapproved until that passed
<rbasak> It's a pain from an SRU processing perspective, because as long as it isn't in the Zesty release pocket the SRU team won't want to release the upload from xenial/yakkety unapproved.
<cpaelzer> rbasak: isn't that what I just said ... rereading ...
<cpaelzer> rbasak: so right now it is in each releases unapproved, due to the freeze on z
<cpaelzer> rbasak: it will stay in all of them, the first to accept at some point should be in Z
<cpaelzer> rbasak: there it will hopefully migrate just fine
<cpaelzer> and after that it is normal SRU/unapproved processing
<rbasak> cpaelzer: yes, I think we agree on the mechanics
<cpaelzer> rbasak: I don't see the extra pain yet?
<rbasak> My complaint was just that it can waste some SRU time, that's all - if the SRU team look to process it before the release team release it from Zesty unapproved and it finishes landing in the release pocket.
<rbasak> Or if there's a problem with the Zesty side, but I hope not as it is more tested by bileto in the correct environment of course.
<cpaelzer> ack
<cpaelzer> thanks to explain the extra SRU concerns
<cpaelzer> let me add a comment to the bug so that SRU members know right away
<cpaelzer> then it should only waste seconds
<cpaelzer> rbasak: Done
<cpaelzer> rbasak: didn't know that it does all-at-once publishes
<cpaelzer> rbasak: will split them up next time
<rbasak> cpaelzer: thanks. I'm not sure that's the right answer, or what the right answer is right now. I just wasn't expecting it, that's all.
<brendand> autopkgtest is spewing:
<brendand> Can't locate Dpkg/Deps.pm in @INC (you may need to install the Dpkg::Deps module) (@INC contains: /etc/perl /usr/local/lib/x86_64-linux-gnu/perl/5.22.1 /usr/local/share/perl/5.22.1 /usr/lib/x86_64-linux-gnu/perl5/5.22 /usr/share/perl5 /usr/lib/x86_64-linux-gnu/perl/5.22 /usr/share/perl/5.22 /usr/local/lib/site_perl /usr/lib/x86_64-linux-gnu/perl-base .) at - line 1.
<brendand> but that appears to be blatantly false
<brendand> $ ls /usr/share/perl5/Dpkg/Deps.pm
<rbasak> rharper: thank you very much for the chart in bug 1649931 - it's very helpful. I'm afraid I still don't follow the details though - it'll take me a disproportionate amount of time compared to the SRU queue in general I think. slangasek, as you're more familiar with this, would it make more sense for you to take care of this please?
<ubottu> bug 1649931 in resolvconf (Ubuntu Yakkety) "systemd-networkd needs to ensure DNS is up before network-online.target" [Medium,Fix committed] https://launchpad.net/bugs/1649931
<arges> rbasak: planing on doing some sru reviews.
<rbasak> arges: ack. I've only been looking at releases so far today.
<rbasak> arges: bug 1656712 currently.
<ubottu> bug 1656712 in ostree (Ubuntu Xenial) "Update flatpak and ostree to 0.8" [Low,In progress] https://launchpad.net/bugs/1656712
<arges> ok starting with xenial upload queue
<am_> hi all, not sure if i'm in the correct place. I am wondering what happened to dh-make-pecl in 16.04 ?
<am_> i am tryiing to package up a pecl extension but the dh-make-pecl package doesn't seem to exist
<mterry> infinity: can you promote mediascanner2 and unity-scope-mediascanner?  Would help the unity8 scopes to not be so bare
<infinity> mterry: Yup, getting there.
<mterry> Gotcha, thx!
<infinity> pitti: cockpit testsuite fails on armhf
<cpaelzer> I'd need opinion on proper changelog construction for SRUs
<cpaelzer> Example: apache2 in trusty has had a 2.4.7-1ubuntu4.14 in proposed but that failed verification
<cpaelzer> I'm now creating a 2.4.7-1ubuntu4.15 for a different issue and wonder what the right changelog approach is
<cpaelzer> a) mention the changes in the failed-to-verify as reverted in .15
<cpaelzer> b) not mentioning them in .15 but keeping the .14 version in the history  (I'd consider that wrong)
<cpaelzer> c) taking the old .14 OUT of the history so that from a users POV it goes .13 -> -15
<cpaelzer> I've seen people do a) and c) and I personally would prefer c)
<cpaelzer> rbasak: ^^
<cpaelzer> moved the discussion to ubuntu-devel
<pitti> infinity: you mean mips? it's fine on https://buildd.debian.org/status/fetch.php?pkg=cockpit&arch=armhf&ver=134-1&stamp=1491261708&raw=0
<pitti> I'll look at the mipsen failures soon
<infinity> pitti: I mean armhf on Ubuntu.
<infinity> pitti: Note this is #ubuntu-devel :P
<pitti> infinity: oh, wow -- I wasn't aware someone was that trigger happy to sync it to Ubuntu already :)
<infinity> cpaelzer: If you've completely reverted .14, omitting that changelog entry is correct too, IMO.
<pitti> infinity: # assertion failed (keyring >= 0) -- ah, same issue as on mips
<pitti> infinity: I figure our ARM buildd kernel just has kernel keyrings disabled; I'll adjust the tests to skip in that case
<infinity> pitti: jbicha synced it, apparently.
<infinity> pitti: Err, as for kernels missing features, that seems... Wrong.
<infinity> pitti: Which CONFIG is that?
<cpaelzer> infinity: thanks
<pitti> infinity: I haven't looked into that at all yet, not sure
<infinity> CONFIG_SYSTEM_TRUSTED_KEYRING=y maybe?
<infinity> We have tha enforced on in all arches on xenial.
 * infinity scratches head.
<pitti> infinity: possibly; I wonder if "keyctl list @u" works there
<pitti> I'll try and find a Debian porter mips box to reproduce it (but not today)
<pitti> also, I would have thought FF and all that, I was aiming for the adventurous aardvark
<infinity> pitti: Yeah, FF doesn't really apply to new universe packages.
<Trevinho> bdrung_work: sorry, I've been notified... Please let's get in touch tomorrow, as it's too late for me now...
<Trevinho> I've *not* been
<bdrung_work> Trevinho, no problem. just ping me tomorrow
<Trevinho> ack
<sil2100> doko: hey! Looking at the FTBFS from the test-rebuild - is there a way to easily re-run a failed build to check if it wasn't just a transient failure?
<doko> sil2100: just tell me which ones to retry
<bdmurray> jbicha: https://bugs.launchpad.net/ubuntu/+source/flatpak/+bug/1656712/comments/3 does that indicate the possibility of a regression if we release flatpak and ostree?
<ubottu> Launchpad bug 1656712 in ostree (Ubuntu Xenial) "Update flatpak and ostree to 0.8" [Low,In progress]
<jbicha> bdmurray: no, that's not a regression but a missing feature and that comment was about xenial not yakkety
<jbicha> bdmurray: but rbasak said he was looking at the yakkey part of that bug today
<rbasak> I was almost about to release that (Yakkety), but I got distracted, sorry.
<jbicha> currently, I have ostree and flatpak in the new queue for xenial but I didn't package xdg-desktop-portal (and -gtk) for xenial
<rbasak> I'll try to look again today.
<jbicha> thanks
<rbasak> jbicha: released. Sorry for the delay.
<jbicha> bdmurray: thanks for the ping though, I'm following up with the person that left the flatpak comment to make sure I understood correctly
<sil2100> doko: I'd like to see if zeromq3 would fail again after a re-run
<sil2100> doko: I vaguely remember the test-suite wasn't too solid
<nacc> rbasak: how is the unapproved functionality looking?
<rharper> slangasek: https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1671606 ;  resolvconf change got tagged in this bug; but I don't believe it's related;  one user mentioned they had to downgrade, but another only had to downgrade network-manager;  the change in question to resolvconf has to do with unit start up sequence and does not affect any runtime behavior (ie, resolvconf service is already active/running
<rharper>  when encountering the issue).  I'd like to mark the resolvconf task as invalid; does that seem reasonable? (and I'll include my logic for doing so )
<ubottu> Launchpad bug 1671606 in resolvconf (Ubuntu) "DNS server from vpn connection is not being used after network-manager upgrade to 1.2.6-0ubuntu0.16.04.1" [High,Confirmed]
<slangasek> rharper: sure
<slangasek> rharper: especially as NM+dnsmasq+resolvconf == 127.0.1.1 in /etc/resolv.conf and that shouldn't have changed
<rharper> slangasek: thanks!
<barry> bdmurray: python-babel ftbfs looks even more interesting in a local build test due to dst issues.  there's no bug # atm, but i'm investigating
<nacc> xit
<nacc> bah
<rbasak> nacc: I haven't touched it in a while. It basically seems to work fine, though I'd like to tweak the CLI
<rbasak> I want it to autodetect the package name from debian/changelog so it doesn't need to be specified
<rbasak> And then replace the existing "usd queue <package>" with "usd queue sync". Then I think it'll be ready to land.
<nacc> rbasak: ok, i can probably do that locally if you want to propose a MR?
<rbasak> Sure, thanks!
<nacc> rbasak: would like to get that in the latest snap just so i can document it on the wiki too :)
<rbasak> nacc: https://code.launchpad.net/~racb/usd-importer/+git/usd-importer/+merge/322042
<rbasak> nacc: the intention of "usd queue sync" is that then things like "usd queue approve" and "usd queue reject" will become possible. IOW, "usd queue" should take subcommands.
<nacc> rbasak: ack
<nacc> rbasak: any reason for USDQueueImporter rather than USDQueue ? (to match the others)?
<rbasak> No, feel free to change
<rbasak> It predates me deciding what to call the subcommand
<nacc> thanks!
<pfsmorigo> there is something wrong with https://insights.ubuntu.com/
<sarnold> pfsmorigo: yes. it's under investigation now.
<pfsmorigo> sarnold, ok
<sarnold> thanks pfsmorigo :)
<wxl> probably because everyone's hitting it hard in disbelief that unity's on its way out :)
<pfsmorigo> wxl, yeah, I'm one of them!
<pfsmorigo> wxl, since it's close to april 1st I was afraid that was a lie
<wxl> hah it might be
<wxl> but i don't think so
<slangasek> rharper: looks like the submitter disagrees with your analysis on resolvconf
<rharper> I replied
<slangasek> ok :)
<rharper> I Think we need a dnsmasq task there
<rharper> at least if the analysis in the RH bugzilla is correct
<rharper> in general, a change to the unit file on when resolvconf starts doesn't impact it at runtime;  no code changes to resolvconf so whatever one sees on 1.78ubuntu2 should be also seen on 178ubuntu4;  I think some folks aren't aware of the 'task' to package mapping and thought I was marking the bug invalid
<rharper> I've invited the user to supply further details on "resolvconf not tracking interfaces" in case there is an element in resolvconf here; but that doesn't seem to be the case when pointing to an upstream fix for dnsmasq
<slangasek> he specifically claimed that new NM exposed a bug in the behavior of resolvconf; anyway, I just wanted to draw it to your attention since I knew you had unassigned yourself
<slangasek> right
<rharper> slangasek: cool; yeah I'm still subscribed to the bug; I appreciate the ping and advice; thanks!
<nacc> rbasak: i think i've got everything working with queue -- i will push it up and can you test with master?
<slangasek> huh, what happened on 31Jul2014 that created a bunch of backup files of .pyc on my system
 * mwhudson checks his diary
<dasjoe> sarnold: probably better over here
<sarnold> ohai a second dasjoe :)
<sarnold> nacc: here?
<sarnold> dasjoe: normally you'd file a bug report with the template in the wiki; fill out the bits you can; attach a debdiff, describe how you tested
<nacc> sarnold: works for me
<dasjoe> HELO
<nacc> dasjoe: is there a bug filed?
<dasjoe> So rbasak asked for a proper SRU in https://bugs.launchpad.net/ubuntu/+source/network-manager-strongswan/+bug/1578193 and I'm trying to fulfil his request
<ubottu> Launchpad bug 1578193 in network-manager-strongswan (Ubuntu) "cannot load legacy-only plugin" [Medium,Confirmed]
<nacc> dasjoe: ok, so you confirmed it's fixed in zesty?
<dasjoe> nacc: well, I'm in the process of doing so. Haven't booted zesty yet, but manually installing zesty's debs in xenial fixes the not-appearing part of the bug
<nacc> um, that's probably not the right way to test
<nacc> hopefully that was in a removable VM :)
<dasjoe> It's not a VM but a sandbox laptop ;)
<nacc> oh ok
<nacc> so presuming you do verify the fix in zesty, update the bug to fix released (if you can, or just put a comment in)
<nacc> i just created tasks for x & y
<dasjoe> So, the "fix" required two updated packages, network-manager-strongswan and strongswan-nm. I would have created a new bug in LP and marked both packages as affected
<sarnold> dasjoe: so... what's the goal? move the packages from https://launchpad.net/~raharper/+archive/ubuntu/bugfixes/+packages to the main archive? have you tested those? or is another goal?
<nacc> dasjoe: no, you can create tasks against multiple source packages in one bug
<dasjoe> sarnold: the easiest goal would be to simply copy network-manager-strongswan, strongswan-nm from z to x & y
<sarnold> dasjoe: aha :)
<dasjoe> I haven't looked at raharper's PPA
<nacc> dasjoe: taht won't happen
<nacc> dasjoe: SRUs need to be small and self-contained
<nacc> ideally
<nacc> z is several minor version bumps
<dasjoe> Yeah, I thought so
<nacc> well, i should say, that won't happen normally
<nacc> and certainly not in the context of this bug which seems to be for only one specific issue with one specific fix
<dasjoe> It's just that the package in x does not work *at all* so there would be no harm in upgrading to a fresher upstream version
<sarnold> heh, sounds persuasive to me :)
<dasjoe> It's the one thing that's holding back a VPN rollout for a customer, so I'm looking to get IKEv2 usable via nm without having to build stuff by hand ;)
<dasjoe> Oh well, time to a) build a IKEv2 VPN gateway VM and b) get and boot zesty. I'll be backâ¦ tomorrow, hopefully
<sarnold> dasjoe: the backportpackage command may make it easy to test building the zesty pacakge against xenial
#ubuntu-devel 2017-04-06
<Decorater> alright so, I want to make my own ubuntu distribution that adds an special section to the ELF file format that windows has as it could be benefitcial
<Decorater> what are all the repos that I would have to clone to be able to make it happen?
<Decorater> I can clone it using git for Windows btw.
<tsimonq2> Decorater: Hey! :)
<Decorater> hi
<tsimonq2> Decorater: It's a lot more complex than you think
<tsimonq2> Seriously, turn back now. :P
<tsimonq2> BUT
<tsimonq2> If you REALLY want to, I can tell you about some core stuff and where to find them
<tsimonq2> But otherwise with that Windows thing, you're on your own, Decorater ;)
<Decorater> yeah I want to add the rsrc section from the PE format headers to the ELF format as it would solve a ton of issues including embedding icons for terminal applications
<Decorater> instead of having to ship an .desktop file
<tsimonq2> Hold on, let's see if I can find this easily...
<tsimonq2> Decorater: How low do you want to go here?
<tsimonq2> Is this kernel-level?
<tsimonq2> This ELF stuff is a little over my head ;)
<Decorater> Well lets say I want it to be an special but optional section that would allow embedding of icons similar to how you can on Windows and display the embedded version in file browser and in terminal
<tsimonq2> Decorater: Take a look at tasksel and the various seeds Ubuntu has. If you find a package that has what you're looking for, run "apt source PACKAGE" in your terminal to get the code. Do whatever you want to it, then rebuild it.
<tsimonq2> Decorater: That's the tl;dr here.
<tsimonq2> Decorater: I would highly suggest reading through this, this can really help you understand what I'm saying: https://www.debian.org/doc/manuals/maint-guide/
<tsimonq2> Decorater: Otherwise, without more specifics, I hope this can point you in the right direction. :)
<Decorater> ok
<tsimonq2> Decorater: Good luck ;)
<Decorater> Also I plan to on the distribution I am thinking of making not shipping python 3.x but 3.x only. Specifically 3.5+ because of asyncio.
<Decorater> which would mean the python parts would need converted to 3.x
<tsimonq2> Feel free. And don't be afraid to contribute what you modified back to us. ;)
<Decorater> ok
<tsimonq2> Decorater: You might want to look into this effort: https://lists.ubuntu.com/archives/ubuntu-devel/2017-January/039648.html
<tsimonq2> "I'd like to enable Python 3.6 as a supported version early in the Zesty+1 cycle, with a goal of 3.6 as default-and-only in the 18.04 LTS."
<tsimonq2> So it's coming either way.
<Decorater> I see
<Decorater> if I noticed correctly it seems that parts of sudo and apt are in python? At least on my 16.10 or so VM.
<tsimonq2> I'm unsure.
<Decorater> alright
<Decorater> I wonder now when the linux kernel would start to ship an modified version of the latest v1.2.11
<rbasak> nacc: usd queue in master> ack
<Unit193> ginggs: Hah, saw the t-d upload, figured it'd be you that did it. :P
<ginggs> Unit193: how so?
<Unit193> You seem to like to poke around in universe at the cool things nobody else cares to.  Also saw your comment on the Debian bug report (Mirroring what I happened to say in -motu too. :P )
<Unit193> https://launchpadlibrarian.net/314653678/buildlog_ubuntu-zesty-s390x.telegram-desktop_1.0.14-1ubuntu1_BUILDING.txt.gz  Heh:  #error "Only little endian is supported!"
<ginggs> Unit193: ha, ok :)
<Unit193> (Nice job!)
<ginggs> I wanted to test armhf before I uploaded, but my rpi3 ate three of my sd cards while upgrading from 14.04 to 14.10
<Unit193> Ouch.
<ginggs> err. i mean 16.04 to 16.10
<ginggs> tried a different rpi3 and was able to upgrade 16.04 -> 16.10 -> 17.04 without too much hassle
<Unit193> I wonder if the version on mentors can easily be patched to not use microsoft-gsl though...
<ginggs> rpi3 eating sd cards seems to be a thing
<ginggs> https://www.raspberrypi.org/forums/viewtopic.php?f=28&t=140845
<Unit193> Wow, that's not cool..
 * Unit193 is un *armed.
<Decorater> I just thought of it
<Decorater> what if there was some sort of api endpoint that would allow an EOL version of Ubuntu to be able to upgrade to latest directly without reinstalling Ubuntu itself.
<Decorater> that is for future EOL versions
<cjwatson> EOL versions can already upgrade without reinstalling.
<cjwatson> Though possibly not directly to latest; they may have to go via the next non-LTS release or the next LTS release, as appropriate.
<jbicha> any core dev care to sponsor LP: #1674773 today?
<ubottu> Launchpad bug 1674773 in adwaita-icon-theme (Ubuntu) "Update adwaita-icon-theme to 3.24.0" [Low,New] https://launchpad.net/bugs/1674773
<tjaalton> jbicha: the debdiff doesn't look right :)
<jbicha> tjaalton: what's it supposed to look like? it's a diff of the debian/ directory?
<jbicha> have I been doing it wrong for years?
<tjaalton> jbicha: you should run debdiff old.dsc new.dsc
<tjaalton> so it has the diff of the whole package
<Laney> That's not that nice for upstream bumps IMO
<Laney> especially if it contains binary files like an icon theme might ...
<tjaalton> true about binary files yes
<tjaalton> but ok
<tjaalton> I don't know how to sponsor that diff though ;)
<Laney> Use uscan to download the new version, unpack it, copy debian/ over, apply the patch
<tjaalton> alright
<tjaalton> jbicha: do you have the package built somewhere, would be easier to just dget & debsign..
<nanodrone> where's the touch handles code for unity located?
<sil2100> cpaelzer: hey! I'm looking at the openssh SRU for yakkety right now - I see in the Bileto silo that there are some failed autopkgtests
<sil2100> cpaelzer: was that expected/transient?
<cpaelzer> sil2100: I explained in the bug already in more detail, but TL;DR expected since always failed that way
<sil2100> Thanks :)
<cpaelzer> sil2100: commend #25 is the one with the details
<cpaelzer> "comment" even
<cpaelzer> sil2100: once they are in <release>-proposed we have to make sure only "the same" issues pop up, but other than that that should be ok
<cjwatson> sil2100: Yep, fixed in zesty, but the fixes are quite involved.
<cjwatson> It should be OK as long as they haven't got worse, indeed.
<sil2100> cjwatson: ok, thanks!
<sil2100> cpaelzer: hah, one little thing - https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/1670745 has the [Impact] part copy-pasted from the template, could you fill it in with real impact contents?
<ubottu> Launchpad bug 1670745 in openssh (Ubuntu Yakkety) "ssh-keyscan : bad host signature when using port option" [Undecided,New]
<sil2100> cpaelzer: ok, I dived into the bug so I know the Impact of it so I can continue with the review, but please be sure to fill that up
<sil2100> cpaelzer: (for documentation's sake)
<sil2100> doko: hey! Could you retry https://launchpad.net/ubuntu/+archive/test-rebuild-20170322.1/+build/12251212 from the test-rebuild?
<cpaelzer> sil2100: will fill it
<cpaelzer> sil2100: done
<sil2100> cpaelzer: thanks!
<jbicha> tjaalton: I got distracted, here you go: http://people.ubuntu.com/~jbicha/adwaita-icon-theme/
<tjaalton> jbicha: cool, thx
<doko> sil2100: now built
<tjaalton> jbicha: uploading
<sil2100> doko: thanks, so it's a flaky test as I remembered
<rbasak> slashd: around? About bug 1176046.
<ubottu> bug 1176046 in isc-dhcp (Ubuntu Trusty) "isc-dhcp dhclient listens on extra random ports" [Wishlist,In progress] https://launchpad.net/bugs/1176046
<rbasak> slashd: I'm sure I asked you this before, and you answered, but I can't find your answer anywhere, sorry. Are you proposing your debdiff in commit 40 as ready for upload to Trusty? Or is it still in progress? And do you have a debdiff for the transitional package in Xenial please? That needs to go in first.
<nacc> rbasak: thanks -- does that mean you were able to test or will test? :)
<rbasak> nacc: I will test :)
<rbasak> nacc: I was going to just continue to use it to do SRU reviews, which will probably be next week now. Unless you'd like me to test sooner?
<nacc> rbasak: not urgent, just was curious
<stgraber> apw: just did a test and screen indeed won't attach to existing fifos when built with sockets... we're looking at a way to build screen so that it supports connecting to both to deal with the upgrade path
<stgraber> apw: because unfortunately it's a change that's going to happen at some point, sockets have been the default since 2011 or so and the next screen release won't have fifo support anymore
<stgraber> apw: I suspect we may need to make do-release-upgrade aware of this and not spawn screen when doing the next LTS to LTS upgrade as I expect 18.04's screen won't have a clue what a fifo is
<cyphermox> jbicha: gdm3 still fails to start
<cyphermox> maybe I'll reinstall with ubuntu-gnome iso though, just in case there's something else off
<apw> stgraber, what about switching to tmux ...
<apw> (and i don't mean that flippantly)
<stgraber> apw: not sure what kind of backward compatibility tmux provides as far as their internal protocol, but yes, if they're doing something sane, that'd be an option
<stgraber> having screen support upgrading from fifos to sockets would be nice in general for anyone upgrading, just not sure how much work that'll be to sort out...
<apw> stgraber, yeah, though i guess most people upgrading will reboot after upgrade so will not have an old session after the upgrade
<nacc> rbasak: re: LP: #1680125, did my pseudo-algorithm make sense?
<ubottu> Launchpad bug 1680125 in usd-importer "pristine-tar branch for Ubuntu is missing orig tarballs needed for Ubuntu" [Undecided,New] https://launchpad.net/bugs/1680125
<Laney> doesn't the upgrade process start a screen though?
<rbasak> nacc: which bit?
<nacc> rbasak: c#2 -- wrapping pristine-tar
<nacc> rbasak: rather than changing the algorithm (which is messy anwyays because gbp-import-orig is inflexible)
<rbasak> Ah
<rbasak> I'm not sure wrapping pristine-tar is useful. As you point out, that's what usd effectively does already.
<rbasak> Depending on how hard it is to fix it in the local pristine-tar branches, it might not be worth fixing this then I guess.
<nacc> i mean it'd be pretty trivial to just let the tool figure out which branches should be renamed
<nacc> to extract an orig
<nacc> i don't think we can trivially fix the local pristine-tar branches
<rbasak> When importing, we could check to see if the orig is available in the correct pristine-tar branch, and if not, then find it and add it perhaps? With no other change to the current upstream import mechanism.
<rbasak> Are we correctly handling the case where the Ubuntu orig tarball differs from Debian currently?
<nacc> "if the orig is available in the correct pristine-tar branch" is not algorithmically implementable
<rbasak> Why not?
<nacc> rbasak: iirc, i think so -- but i'll check
<rbasak> We know which distro we're importing at import time.
<rbasak> And we know the orig tarball name/version.
<nacc> rbasak: yes, but how do you look in the branch to know what was imported
<nacc> rbasak: that doesn't help you for the pristine-tar branches
<rbasak> pristine-tar list.
<rbasak> (and cached if needed, presumably)
<nacc> rbasak: ah, didn't know about that command
<nacc> rbasak: ok, i'll look at that today
<rbasak> nacc: thanks, but no rush!
<rbasak> Now that there's a snap, it really is unlikely I'll hit it in practice again I think, especially now I know about it.
<rbasak> (an updated snap I mean - thanks for that!)
<nacc> still pending of course
<nacc> cpaelzer: re: LP: 1677578, with 17.04 -- that's the same php-imagick (i believe) as you tested with ondrej's upstream
<ubottu> Launchpad bug 1677578 in php7.0 (Ubuntu) "php-fcgi: max_execution_time causes memory leaks" [Undecided,Confirmed] https://launchpad.net/bugs/1677578
<nacc> cpaelzer: are you able to confirm that for me, just to be sure?
<cpaelzer> nacc: ? what is the question
<cpaelzer> nacc: in the bug?
<nacc> cpaelzer: so your last two comments are: it happens with 17.04 and then it doesn't happen with ondrej's ppa
<nacc> afaict, 17.04 and ppa have the same php-imagick (sans delta from ubuntu, but should be irrelevant)
<cpaelzer> nacc: yeah php-imagick is the same then other than the Delta
<cpaelzer> nacc: but php is obviously a big step from 7.0... to 7.1.3
<nacc> cpaelzer: ack, ok -- will look at php
<nacc> right but if it's a bugfix, i believe they are backporting to 7.0
<nacc> and i have a newere upstream in a ppa
<cpaelzer> nacc: as I wrote in the bug, I don't think somebody coded that as a bugfix
<cpaelzer> nacc: I think they changed how php-cgi works in general
<cpaelzer> nacc: to really kill it if hit by max-exec while in plugins
<cpaelzer> nacc: but you might sift through the release notes and commut log and might find it
<nacc> cpaelzer: any chance you can try https://launchpad.net/~nacc/+archive/ubuntu/php7testbuilds if you ahve the testcase around? on 16.04 -- if not, i will do it, no worries
<cpaelzer> until wife or kids coe in and punch me I can try to help
<nacc> cpaelzer: thanks, figured you might have the env already setup or so
<nacc> rbasak: i'm 100% on board with what you are suggesting, but note that it would require a re-import to fix existing imports
<nacc> rbasak: which is probbly fine, just fyi
<rbasak> nacc: I think that's OK. We can defer doing that until we need it for some other reason.
<rbasak> nacc: but again, no rush to even start addressing it :)
<nacc> rbasak: ack, it's pretty easy to do, i think
<nacc> rbasak: also, this will end up requiring lpusip/upstream/debian/ and lpusip/upstream/ubuntu/, if htat's ok with you :)
<robru> Laney: oh, uh, you rolled to production without merging I guess. https://code.launchpad.net/~robru/autopkgtest-cloud/+git/autopkgtest-cloud/+merge/322132
<rbasak> nacc: that seems reasonable, given that they could be different.
<nacc> rbasak: yep
<Laney> robru: I didn't see a merge proposal, so yes?
<Laney> done that one, merci
<robru> Laney: I think there's some confusion with the branches because I pulled you commits from somewhere but then in proposing the MP it's trying to merge commits that are already in production
<Laney> hmm
<Laney> someone's at the door, back in a bit
<Laney> robru: I think I have to push to somewhere else now that it's a project
<Laney> the one everything's looking at was a personal repo
 * Laney updates 9999999 checkouts with the new url
<robru> Laney: yeah this isn't the first time I've seen martin not have the necessary LP project in place to allow MPs
<robru> I wonder if these git repos pre-date much of the LP git support
<robru> Laney: so we're standardizing on lp:autopkgtest-cloud?
<Laney> if that's the same as https://git.launchpad.net/autopkgtest-cloud
<Laney> that's the one you can do merge proposals against, so it seems to make sense
<robru> Laney: yes, ok
<pitti> infinity: at your service, https://launchpad.net/ubuntu/+source/cockpit/137-3 builds everywhere now :)
<Laney> apw: do "git remote set-url origin git+ssh://git.launchpad.net/autopkgtest-cloud" in your checkout, the branch moved
<rbasak> nacc: accept/reject aren't needed; they'd be future enhancements.
<nacc> rbasak: ok, so we can mark fix released upon your test
<nacc> rbasak: fwiw, i left placeholders in for accept/reject so it should just be an uncomment and define a function to add them
<rbasak> nacc: ack
<Basketball> I know this is #ubuntu-dev but I have a question about elementary os
<Basketball> there is a script chrx (chrx.org) that currently supports ubuntu and I want to add support for elementary os
<Basketball> elementary os is built from seeds of ubuntu whatever that means
<Basketball> the code for ubuntu and fedora builds it using the base images.... anyone have idea for elementary os which does not have a base image
#ubuntu-devel 2017-04-07
<sarnold> Basketball: at https://chrx.org/chrx-install the function do_install() looks like it supports two install methods already -- compressed tarballs, and docker images; does elementaryos publish either of these?
<Basketball> sarnold, nope
<sladen> ~>
<Harris> I know this is #ubuntu-dev but I have a question about elementary os
<Harris> there is a script chrx (chrx.org) that currently supports ubuntu and I want to add support for elementary os
<Harris> elementary os is built from seeds of ubuntu whatever that means
<Harris> there is a script chrx (chrx.org) that currently supports ubuntu and I want to add support for elementary os
<rbasak> I doubt anyone here will know. Try an elementary os support channel.
<brendand> rbasak, Harris - but in theory it's Ubuntu based so whatever jiggery pokery chrx does to the ubuntu iso, should apply equally to elementary??
<brendand> if you're looking for a step by step, there probably isn't one
<brendand> Harris, the best route might be to file an issue against chrx on github
<brendand> oh would you look at that
<Blu2> Is Ubuntu Core still a thing for Desktop?
<seb128> wgrant, hey, could you trigger a new zesty full langpack export this w.e so we can upload updated base langpacks on monday?
<wgrant> seb128: There was a full export on Wed, but I'll kick off a fresh one.
<seb128> wgrant, right, but the zesty schedule said translators could do their work until the 6th so Gunnar wanted an export after that if possible, thanks
<wgrant> seb128: Yep, it'll be done. I've fixed the issue that was causing full exports to be unreliable.
<seb128> wgrant, great, thanks!
<Laney> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Zesty Final Beta Released | Archive: post-beta denouement | Devel of Ubuntu (not support or app devel) | build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of precise-yakkety | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | Patch Pilots: Laney
<Laney> queue's looking good
<nacc> is sandbox-upgrader still used ?
<nacc> xnox: infinity: --^ you had the last two uploads (trusty and raring) ... I'm guessing not, but would like to confirm before I request it's removal (so we can move vm-builder)
<infinity> nacc: Yeah, our uploads were just small dependency fixes, I'm not sure either of us cares at all about the package.
<infinity> nacc: mvo's the author, you might ask him about his carefactor.
<nacc> infinity: ack, will do
<Laney> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Zesty Final Beta Released | Archive: post-beta denouement | Devel of Ubuntu (not support or app devel) | build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of precise-yakkety | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | Patch Pilots:
<jbicha> Laney: I don't see any reason to rush LP: #1670248 into zesty, how are we marking bugs we're deferring?
<ubottu> Launchpad bug 1670248 in dosfstools (Ubuntu) "Sync dosfstools 4.1-1 (main) from Debian stretch (main)" [Wishlist,New] https://launchpad.net/bugs/1670248
<nacc> you can target it to aa-series?
<jbicha> ok, there we go, thanks
<nacc> np
<elopio> barry: ping. We used this to retry the autopkgtests, but it seems to be gone: https://git.launchpad.net/~ubuntu-release/+git/autopkgtest-cloud/tree/tools/retry-github-test
<elopio> do you have a new location?
<cjwatson> elopio: https://git.launchpad.net/autopkgtest-cloud/tree/tools/retry-github-test
<barry> cjwatson: beat me by that --> <-- much
<barry> https://code.launchpad.net/~ubuntu-release/autopkgtest-cloud/+git/autopkgtest-cloud
<elopio> thanks cjwatson, barry.
<|234c7> howdy p33ps
#ubuntu-devel 2017-04-08
<zippydo> I have a usb grabber based on the CX23012 chipset and is not been recognised. CX23012 is supported but I guess the device Id is the issue. Do I need to compile a custom kernel module to get it to work
<Decorater> did you try unplugging it and plugging it back in?
<Decorater> sometimes I have to do that even in Windows.
<tsimonq2> !support
<ubottu> The official ubuntu support channel is #ubuntu. Please be aware that this channel is for development only.
<zippydo> hi I have a usb grabber with chip cx23102. I checked the linuxtv wiki and my device type is not listed under the cx2310x driver page. Can anyone help on getting my device to recognised by this driver. I am guessing I will need to configure and compile the driver for the particular device, but notsure where to start
#ubuntu-devel 2017-04-09
<ari-tczew> hello
<ari-tczew> I've got a problem regarding the package stuck in zesty-proposed. The package is: http://people.canonical.com/~ubuntu-archive/proposed-migration/zesty/update_excuses.html#cpqarrayd
<ari-tczew> Reason: missing build on armhf: cpqarrayd (from 2.3-4ubuntu1)
<ari-tczew> However, the version from -proposed was built fine and only on amd64 + i386
<ari-tczew> So, what the hell is going with armhf ?
<axk4545> is this the appropriate place to ask about the tools the are used to build ubuntu? specifically CI for generating ISOs
<jbicha> axk4545: yes, but Ubuntu doesn't use CI to generate the ISOs
<axk4545> jbicha: ok.
<axk4545> .part
<axk4545> oops
<melonin_highsurf> hello how do i run the unity desktop with UNITY_NEKO=1 to see cats?
<teward> is there a good resource for creating a debian package that contains a pure python module/library so I can create a package that would install it?  I'm a little confused on how to create a package that would properly install/configure the package.  (It's already up on pypi, but creating the package is the first thing, before trying to get it in the repos)
<valorie> teward: have you read the Debian Policy Manual?
<teward> valorie: somewhat, but it's not as clear cut as the standard packaging guides on how to package.  Maybe I'm just tired :P
<valorie> right, I've read most of that, and because I've not actually made a package, it's still clear as mud to me
<valorie> tsimonq2 has promised to make the Kubuntu packaging docs so clear that even I can successfully create a package. :-)
<valorie> https://phabricator.kde.org/w/kubuntu
<teward> well I know *pure* package creation, I have to know that for the nginx package - but packaging a python module's a little outside my current knowledge :P
<valorie> https://wiki.debian.org/Python/LibraryStyleGuide
<valorie> ?
<Unit193> py2dsc!! :P
<jbicha> libretro-bsnes-mercury fails to build on arm64 and s390x now but it built last year
<jbicha> the problematic file is https://sources.debian.net/src/libretro-bsnes-mercury/unstable/nall/intrinsics.hpp/
#ubuntu-devel 2018-04-02
<pjotr> Hello, I would like to draw your attention to this bug in Ubiquity:
<pjotr> https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1758647
<ubottu> Launchpad bug 1758647 in ubiquity (Ubuntu) "ubiquity doesn't preselect the right default keymap for Dutch" [Medium,In progress]
<pjotr> jbicha: could this perhaps be fixed in time for Bionic?
<pjotr> Simon Quigley has assigned the bug to himself, but he subscribed the Ubuntu Desktop Team in the hope that you guys could provide some information that would lead to an easy fix....
<darkxst> pjotr, talk to gunnarhj
<pjotr> darkxst: OK, on which IRC channel does he hang out?
<darkxst> pjotr, he probably hangs out here when he is around
<jbicha> pjotr: you could try emailing him
<pjotr> jbicha and darkxst: thanks, I'll do that
<pjotr> Hello, I'd like to request your attention for this important Ubiquity bug again:
<pjotr> https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1758647
<ubottu> Launchpad bug 1758647 in ubiquity (Ubuntu) "ubiquity doesn't preselect the right default keyboard layout" [High,In progress]
<pjotr> gunnarhj has already looked at it and confirmed it for Swedish as well.
<pjotr> Who can help to fix this bug, which is very important for non-English languages?
<sarnold> cyphermox: ^^ is pjotr's problem one for you?
<sunweaver> LocutusOfBorg: https://bugs.launchpad.net/ubuntu/+source/update-notifier/+bug/1760691
<ubottu> Launchpad bug 1760691 in update-notifier (Ubuntu) "Please switch to Ayatana AppIndicator" [Undecided,New]
<sunweaver> LocutusOfBorg: https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1760701
<ubottu> Launchpad bug 1760701 in ubiquity (Ubuntu) "Drop gir1.2-appindicator3-0.1 from Depends: field" [Undecided,New]
<sunweaver> LocutusOfBorg: https://wiki.debian.org/Ayatana/IndicatorsTransition#Packages_in_Ubuntu_main_that_need_to_be_ported_a.s.a.p.
<LocutusOfBorg> thanks sunweaver ! I hope release team will ask this for bionic
<Unit193> ...Not a chance, LTS+1 is a great time to do this though.
<sunweaver> I am not addressing this for 18.04...
<sunweaver> this is beyond April `18
<sunweaver> you could get the ubiquity issue fixed for 18.04 as it reduces the pile of pulled-in packages...
<LocutusOfBorg> we need to talk with installer team, I don't know how/where to commit changes
<tsimonq2> LocutusOfBorg: lp:ubiquity
<tsimonq2> LocutusOfBorg: https://code.launchpad.net/~ubuntu-installer/ubiquity/trunk
#ubuntu-devel 2018-04-03
<darkxst>  I know I have done this in the past, but how do I get a list of source packages that rdepend on a lib?
<Unit193> reverse-depends -b libssl-dev
<darkxst> my current attempts are just spitting back binary packages
<Unit193> Oooh, you didn't say 'build'
<darkxst> reverse-depends -b libzip4
<darkxst> No reverse dependencies found
<darkxst> meh
<darkxst> and no not build deps
<darkxst> the source packages that are linked to the library!
<doko> LocutusOfBorg: the pytest sync was not a great idea. do you work on the autopkg test failures?
<cjwatson> darkxst: source packages aren't linked to libraries; the only way I can make that request make any sense is build-deps
<xnox> darkxst, i pipe the result of $ reverse-depends foo into bin2src to map binary packages to source packages.
<cjwatson> darkxst: (but packages don't build-depend on the runtime, so you need to do reverse-depends -b libzip-dev)
<cjwatson> (or reverse-depends -b src:libzip)
<doko> coreycb, rbasak: please could you have a look at the postgresql-10 autopkg test failures on armhf?
<darkxst> cjwatson, xnox thanks for the hints, pretty sure 18months without internet has affected my brain!
<cjwatson> ... I think I'd melt or something
<darkxst> It was more internet at $10 per GB
<cjwatson> haven't been 18 months without internet since err about 1995
<darkxst> you can't do any packaging at those rates
<rbasak> doko: I'll need to add it to the backlog. But which failures exactly? I only see pg-repack failure across all archs on excuses.
<xnox> darkxst, https://www.amazon.co.uk/Three-Mobile-Pay-Broadband-Data/dp/B01M3VJ2B2?th=1 24GB sim card for 45GBP which works in all of EU, US, Canada, Australia and many other countries around the world. Not sure where you were.
<xnox> oh and valid for 2 years
<xnox> so very handy.
<rbasak> xnox: their terms make it clear that they expect to be generally using the SIM in the UK.
<rbasak> Otherwise they'll disconnect you.
<xnox> rbasak, for pay monthly, yes.
<rbasak> xnox: for PAYG.
<rbasak> Oh
<rbasak> I might be talking about a different product. Sorry.
<xnox> rbasak, for the "feel at home stuff" -> yeah, you can't be out of the country for more than 3 months in a row, or 3 out 12 rolling or some such.
<xnox> but this one seems to simply be pre-loaded with data, and it's data only "internet on the legs" sim. and in the comments people totally are (ab)using it as a travel sim
<xnox> rbasak, i'll let you know if i get disconnected ;-)
<darkxst> xnox, I am remote, only Telstra
<darkxst> might be handy though if I get to GUADEC again
<darkxst> which against my better judgment have applied for funding from CC
<darkxst> work can deal with the rest of it
<doko> xnox: xe-guest-utilities needs a MIR?
<LocutusOfBorg> doko, yes, already worked out
<LocutusOfBorg> it was a great idea, because pytest catchlog was completely and utterly broken, and duplicated in new pytest
<LocutusOfBorg> so, reverse-dependencies were broken as well (I can't assure all of them)
<LocutusOfBorg> I'm finishing the open of RC bugs in Debian right now
<LocutusOfBorg> I'm sad I couldn't do it before, but I discovered how broken it was only recently (I tried to avoid pushing it to bionic unless really necessary)
<LocutusOfBorg> hello tkamppeter, what is your opinion wrt cups sync/merge?
<tkamppeter> LocutusOfBorg, principally, I am syncing CUPS, but now for the LTS I would like to leave out the deprecation of raw queues to not cause any incompatibilities by the extra warnings and messages.
<tkamppeter> I will continue syncing after 18.04.
<doko> tjaalton: tomcat8.0 is still in bionic. is this intended?
<tjaalton> doko: i have newer dogtag-pki in experimental which uses 8.5
<tjaalton> need to check upgrades first
<tjaalton> then sync it
<LocutusOfBorg> thanks tkamppeter!
<tjaalton> but for libresteasy I think going back to 3.0 series is needed.. there's 3.5 which is compatible to 3.0 but adds new stuff which need newer jaxb et al..
<LocutusOfBorg> doko, #894705 in debian looks RC to me, I'm reassigning to the one I just opened
<LocutusOfBorg> it has no rdeps, maybe just kick it out from bionic to proposed?
<seb128> wgrant, cjwatson, do you have any idea why the template imports from https://translations.launchpad.net/ubuntu/bionic/+source/indicator-power/+imports and not reflecting in https://translations.launchpad.net/ubuntu/bionic/+source/indicator-power ?
<doko> rbasak, coreycb, smoser: the grub-legacy-ec2 wants to migrate to main, but doesn't have a subscriber. is this your team?
<cjwatson> seb128: I think it's because "Template is active" is unchecked on https://translations.launchpad.net/ubuntu/bionic/+source/indicator-power/+pots/indicator-power/+edit.  Do you know why that might be?
<seb128> cjwatson, no idea, thanks for pointing that out
<seb128> cjwatson, to be fair I don't understand those details of launchpad translations, at least not the "sharing" part, we keep hitting cases where that is active and pointing to outdated import, and as a side  effect it leads to not have the package upload files imported
<seb128> cjwatson, I wonder if somebody changed those options after unity moved to universe, but afaik there is no "activity" log for those?
<cjwatson> Could be, and indeed AFAIK there isn't.  This is, um, not my speciality.
<cjwatson> seb128: Shall I just flip it back on?
<seb128> cjwatson, I did, thanks
<seb128> I did it for all indicators
<cjwatson> OK
<xnox> doko, yes it does need sru....
<xnox> MIR that is
<tjaalton> ahasenack: so, how about sssd 1.16.1?
<ahasenack> tjaalton: I can't justify an ffe for it. I've been lurking in the mailing list looking for trouble with that version, just saw 2 so far (failure to start on centos, and a guy who was complaining enumeration was timing out iirc)
<ahasenack> tjaalton: I also didn't find the stanting exception you mentioned
<ahasenack> standing*
<tjaalton> ok then
<doko> jbicha: the graphee MIR looks ok. please upload a package that references it
<jbicha> doko: I uploaded gst-plugins-base1.0 to the bionic queue for graphene
<slangasek> I guess you want this for final beta?
<jbicha> um, sure
<slangasek> it impacts all image builds, which it looks like have already started
<slangasek> --> #ubuntu-release
<Whoopie> Hi, does a NNTP server for ubuntu mailing lists exist? I just learned that gmane doesn't have the new lists like bionic-changes.
<TJ-> Whoopie: no
<Whoopie> TJ-: do you maybe know why the new lists were not registered at gmane?
<TJ-> No idea... but hasn't Gmane gone through some issues in recent times with not keeping up/being maintained?
<Whoopie> right, they had a light restart after they shutdown in 2016.
<Whoopie> ok, I see, it's not possible to add new lists.
<jbicha> doko: graphene is in component-mismatches-proposed now
#ubuntu-devel 2018-04-04
<johnnyfive> Is it possible to have the hashes and an InRelease file at the component level of a repo, as opposed to the .com/dists/ubuntu/Release file?
<cjwatson> Nothing to stop you preparing such a thing, though some assembly would be required.
<cjwatson> https://wiki.debian.org/DebianRepository/Format may be helpful.
<johnnyfive> cjwatson, the question is will apt handle it the same? I'm about to write the logic just hoping someone would have some insight before I spent all the time
<cjwatson> Sort of.  You'd have to write an explicit path in sources.list, since apt special-cases the dists/$suite/InRelease lookup.
<cjwatson> The obvious question would be why bother ...
<cjwatson> (It's a fair bit of work, and doesn't seem to buy much)
<johnnyfive> Yeah, i'm not even sure how to explain the situation without writing a book. Basically we serve custom compiled software that are drop-in replacements (in this case for ubuntu/debian), and we treat each component as an independent object. There's reasons beyond that, but that's the gist of it.
<johnnyfive> Thanks cjwatson
<johnnyfive> by "custom compiled" I mean the entire public repo, but compiled differently
<cjwatson> johnnyfive: Right, but none of that requires changing the layout.
<cjwatson> johnnyfive: It's certainly possible to have pretty much whatever layout you want, though; it can just end up looking a bit odd in sources.list.
<johnnyfive> I see. Ya trying to avoid non-standardness from the clients perspective.
<cjwatson> (you tend to end up writing "./" in place of the component)
<johnnyfive> ah
<cjwatson> johnnyfive: You could just have a bunch of separate repositories.
<johnnyfive> cjwatson, ya that's an option.
<johnnyfive> and might be what we do.. we'll see. thank you again
<cjwatson> johnnyfive: Anyway, InRelease lists the relative paths to the other index files that make up the repository, so you have some flexibiility in how that's laid out if you want to use it.
<cjwatson> *flexibility
<cjwatson> np
<RAOF> Grump.
<RAOF> Why has snapd suddenly decided to die.
<RAOF> âerror: cannot parse /proc/self/mountinfo: incorrect number of tail fields, expected 3 but found 5â. Hrm. This is probably due to me not running an Ubuntu kernel?
<Faux> That'd be my guess, yes.
<infinity> RAOF: https://github.com/snapcore/snapd/pull/4969
<infinity> RAOF: Might want to dogpile on that if it fixes fstab but not mountinfo (but maybe the same codepath)
<infinity> RAOF: Oh, the commit message mentions both, so yeah.
<RAOF> â¦bcachefs /dev/nvme0n1:/dev/sda3â¦
<RAOF> I suspect things are confused by the â:â in there.
<infinity> RAOF: Perhaps.  Perhaps not.  But that commit just makes it skip over entries it doesn't like instead of exploding.
<infinity> Which seems entirely reasonable, given that I can't figure out why snapd needs to parse fstab/mountinfo in the first place. :P
<infinity> RAOF: I imagine rolling back to the artful-updates version until the above lands should do the trick.
<infinity> Or snag an older bionic binary from the librarian.
<RAOF> infinity: I think snapd is parsing mountinfo in order to do crazy things in the presence of NFS.
<RAOF> Yah.
<infinity> RAOF: Oh, I'm sure it has its reasons.  I'm just not sure I'd agree with them if I dug into it, so I've chosen to remain ignorant.
<RAOF> :P
<RAOF> infinity: Harumph. I think the change must have been made in the core snap, because installing old snapd versions doesn't change the behaviour at all.
<juliank> I'm annoyed by submittodebian using --include rather than --attach for the debdiff, IMO this just makes things harder to apply and the email very long :/
<juliank> Oh I can fix that
<doko> tjaalton: you want to subscribe ubuntu-mir for 1761095 ...
<xnox> root     15001  0.0  0.0  15868  3328 pts/0    S+   09:56   0:00  |   |               \_ /bin/sh /var/lib/dpkg/info/lxd.postinst configure 3.0.0-0ubuntu1
<xnox> root     15259  0.0  0.0  67860  5748 pts/0    S+   09:57   0:00  |   |                   \_ /bin/systemctl restart lxd-containers.service
<xnox> root     15263  0.0  0.0  61796  3060 pts/0    S+   09:57   0:00  |   |                       \_ /bin/systemd-tty-ask-password-agent --watch
<xnox> this is odd...
<xnox> stgraber, is it normal that upgrading lxd takes a long time, and blocks?
 * xnox wonders if it is my own fault of suspending the desktop whilst upgrades are running
<xnox> killed systemctl restart, and the upgrade continued.....
<doko> rbalint: rax-nova-agent promoted. it needs seeding somewhere, or a reference in a package
<xnox> doko, rbalint - probably into the platform cloud supported seed, at the very least.
<xnox> done
<doko> juliank: missing test dep? https://launchpad.net/ubuntu/+source/socat/1.7.3.2-2ubuntu1/+build/14528471
<juliank> doko: apparently :(
<juliank> I wish I had working sbuilds
<juliank> (no I don't want to use chroots, I want to use lxd containers)
<doko> we are definitely missing an up-to-date description how to run autopkg tests locally
<juliank> Oh, autopkgtest are fine, but these are build-time tests
<Laney> doko: http://packaging.ubuntu.com/html/auto-pkg-test.html#executing-the-test definitely?
 * juliank runs build in lxc container with net-tools b-d added
<doko> Laney: qemu, not lxd?
<juliank> qemu is definitely a good choice
<juliank> too many problems with lxd
<juliank> some tests need machine-isolation, others just don't work in lxd
<juliank> and only armhf uses lxd IIRC
<Laney> Right, but sometimes failures are lxd failures rather than armhf failures and for those it's good to be able to run lxd tests locally
<juliank> Laney: yes, but still qemu is the only documented way in that page
<Laney> The initial complaint was that we were "definitely missing an up-to-date description how to run autopkg tests locally", not that the page we have doesn't precisely specify how tests are run on autopkgtest.u.c. We are not "definitely missing an up-to-date description how to run autopkg tests locally".
<juliank> that's true
<Laney> But maybe it would be a good idea if it can be done simply --- https://code.launchpad.net/~ubuntu-packaging-guide-team/ubuntu-packaging-guide/trunk is pushable to by all developers if somebody wanted to addd that.
<juliank> now i wonder whether we want autopkgtest-virt-multipass ...
<Laney> If it were me I'd use the SSH runner for new virt types, and write setup scripts for those
<Laney> instead of new autopktest-virt-foo
<Unit193> I found a nice wikipage or somesuch detailing concisely how to use autopkgtests, but I have lost it.
<tjaalton> doko: oh indeed
<juliank> doko: ubuntu2 should fix that
<juliank> (the tests pass in PPA now)
<doko> jbicha_: what exactly keeps gnome2 in main? openjdk removed it's dependencies
<jbicha> doko: you mean gtk2?
<darkxst_> bdmurray, did you ever see my tasksel patch bug on 1751546
<doko> jbicha: yes
<jbicha> reverse-depends -c main src:gtk+2.0
<jbicha> nvidia-settings is an alternate dependency so not important (and I tried arguing for its removalâ¦) LP: #1736617
<ubottu> Launchpad bug 1736617 in nvidia-settings (Ubuntu) "Port nvidia-settings to gtk3" [Undecided,Fix released] https://launchpad.net/bugs/1736617
<jbicha> I think it will be safe to drop the thunderbird dependency on gtk2 with thunderbird 60 (52 still supports non-Flash NPAPI plugins)
<jbicha> that leaves gparted and a few input methods: those are only used on the live ISO (unless you use one of those languages)
<jbicha> the new Community theme recently got a dependency on gtk2-engines-pixbuf for gtk2 support, but at least it doesn't directly depend on libgtk2.0-0
<jbicha> so I expect Ubuntu 18.04.1 to not include libgtk2.0-0 in the default install (assumes Thunderbird is updated by then)
<didrocks> (yes, I checked that before promoting)
<doko> jbicha: what about gparted?
<rbasak> xnox: when working on mongodb 3.6, did you ever get a hang on tests?
<rbasak> I'm seeing "./dbtest --list" hang.
<jbicha> um, you want to switch to gnome-disks? gparted doesn't support Wayland so that's actually a technical justificationâ¦
<rbasak> Haven't dug into it deeper yet.
<jbicha> (obviously, not for 18.04 but maybe for 18.10)
<xnox> juliank, can you join #ubuntu-kernel?
<xnox> please
<xnox> rbasak, hmmm...  i do not see my reply in scrollback. I had hanging tests and failures; i did not debug all of them; I did manage to get the stripped down build to pass on bionic with patches. But not a full one.
<xnox> rbasak, make sure you do not run out of disk space; and that test binaries are stripped; and that you have networking available; these are the top culprits to check for.
 * juliank wants more people to use the daily apt builds in the PPA https://launchpad.net/~deity/+archive/ubuntu/sid - testing stuff is nice :D (devel only, really; though it also builds current stable...)
<jbicha> juliank: post to Planets, post to https://ubuntuforums.org/forumdisplay.php?f=427 , post to https://community.ubuntu.com/
<juliank> well, preferably developers, not the average user :)
<jbicha> developers might be more risk-averse than the ubuntu+1 testers ;)
<juliank> I should just have a cron job that copy-packages the PPA package to devel
<jbicha> for instance, a lot of people on that forum run bionic-proposed even though they know we don't recommend thatâ¦
<juliank> yeah, but then I get the problems from that reported as my problems
<jbicha> yeah, I try not to maintain PPAs these days :)
<juliank> anyhow, I use that repo, and I don't perform any checks when doing releases - a release is basically just a random snapshot
<juliank> (everything on master passes CI essentially, and that's the requirement for a release too, apart from feature completeness)
<juliank> though, if we do break ABI/API soon, things might be different, hmm
<juliank> (as in, cache files might change in incompatible ways in snapshots but have same version in them)
<rbasak> xnox: OK, thanks
<tjaalton> slangasek: pam is still missing that NMU from debian to add support for pam-auth-update --enable, do you want to merge that or can I add that (and just that)?
<slangasek> tjaalton: feel free to add it.  I was somewhat blocked on making further changes to pam waiting for server team to do something with https://code.launchpad.net/~vorlon/ubuntu/+source/pam/+git/pam/+merge/341556
<slangasek> nacc: ^^ ?
<slangasek> oh, and that merge now shows a bunch of conflicts, how did that happen
<tjaalton> ah right, I remember this now
<slangasek> nacc: a merge being invalidated because I now have conflicts, when the thing I'm proposing for merge is the actual content of the archive, gives me flashbacks to the bzr udd
<nacc> slangasek: looking, one moment
<nacc> slangasek: debian moved ahead of your base
<nacc> slangasek: so it is a merge conflict in Git terms
<nacc> slangasek: since the target of your LP merge is a branch and not a tag (which I believe actually isn't supported while technically possible)
<nacc> slangasek: 1.1.8-3.7 specifically, is in debian/sid and not an ancestor of your branch
<nacc> slangasek: so a rebase and force push should fix that
<slangasek> nacc: indeed; but process-wise, that really seems like it shouldn't invalidate the mp
<nacc> slangasek: it's because of how LP figures out your target
<nacc> slangasek: i *believe* it doesn't save the commit hash of when it ran
<nacc> but i'm not sure
<nacc> cjwatson: --^ perhaps you can say?
<nacc> slangasek: we have worked aroudn this on our team by doing the MP review manually
<nacc> (ignoring hte LP UX) to merge to an older Debian version than the latest
<slangasek> nacc: ok, so in principle the fact that LP has moved on should also not make more work for me, it's just a question still of someone on the server team reviewing and merging that?
<nacc> slangasek: right, and it will still show up in your grep-merges after that
<nacc> since debian would be ahead of our base in ubuntu
<nacc> but it's technically possible to review as-is, and I'll try and do that now
<nacc> slangasek: this is a gap because we aren't actually doing a Git merge in our process
<slangasek> ah :)
<nacc> we are taking your proposed source and tagging it, then the importer integrates it as 'rich history'
<nacc> but there's no way to 'review' a branch in a nice way other than MPs currently
<nacc> well, there is, but it's mailing lists or manually
<nacc> slangasek: oh wait, this was already uploaded?
<nacc> slangasek: so, because it was already imported (and we've already reimported pam), we won't see any upload tag i create now
<nacc> I *can* create one, so that on a future reimport, if it occurs, it will get integrated (I see the trees match, so it will)
<Unit193> juliank: https://sourceforge.net/p/squashfs/code/ci/e38956b92f738518c29734399629e7cdb33072d3/
<nacc> slangasek: in any case, that means that MP doesn't really mean much (it's effectively done)
<slangasek> nacc: ok, so the mp should be rejected?
<nacc> slangasek: i can either push an upload tag so it's at least preserved in the future (but not integrated until someone does a reimport, if they do) or i can reject it
<slangasek> nacc: it was a fair amount of work to create that branch, I'd rather the rich history not be lost
<nacc> slangasek: ack, one moment
<nacc> slangasek: i'm well aware this is a bottleneck
<nacc> slangasek: we plan on fixing this long-term a la dgit by writing the hash into the source upload
<nacc> slangasek: and then teaching our importer to look for that field, and querying LP for the corresponding Git commit
 * slangasek nods
<nacc> i'm not 100% on what the 'right' state is
<nacc> i'll mark it as merged, even though it's not actually :)
<nacc> but it's available in the importer repo now (git fetch pkg should bring down an upload tag)
<cjwatson> nacc: that doesn't sound like an accurate description of what's going on; it's more that the point of a merge is, well, to be merged, so there isn't much point in saying that there wasn't a merge conflict when the target was what it was originally
<cjwatson> put another way, there's *never* a merge conflict against the merge base, by definition
<nacc> cjwatson: you're right
<cjwatson> (I haven't looked at this MP specifically, just general comments)
<nacc> cjwatson: but the issue we ran into is you can't specify a merge to a tag
<nacc> or an arbitrary ref, really
<cjwatson> nacc: sure, because you couldn't land such a thing
<nacc> cjwatson: right :)
<nacc> well, not without knowing how we do land them :)
<nacc> cjwatson: we really don't want users to do branch manipulation because it's so easy to get wrong
<cjwatson> merges to tags are nonsensical by definition
<nacc> but we need to reivew things that will end up resulting in branch manipulation, if that makes sense
<cjwatson> the only reason it even came up was that you were trying to use it as a diff generation mechanism
<nacc> because we're not really doing Git merges in the first place :)
<cjwatson> which you might be better off doing by way of constructing cgit URLs on git.launchpad.net
<nacc> yeah
<tjaalton> nacc: so how would I land the feature to pam-auth-update from -3.7? just upload or should it go via a merge proposal?
<nacc> tjaalton: that's completely up to you :)
<nacc> tjaalton: there is no requirement for anyone to use the Git repositories
<nacc> tjaalton: however, you can provide rich history there, which can helpful :)
<tjaalton> nacc: ah ok. well there's not that much history, other than on the bug..
<nacc> tjaalton: right
<slangasek> well, if the result of the next pam upload is that the rich history I created by preparing that mp is thrown away, there will be some table-flipping here
<nacc> so the easy answer then, is use the upload tag as a starting point
<nacc> tjaalton: --^
<tjaalton> alright
<nacc> and do a change on top
<tjaalton> sure
<nacc> propose iit as an MP to ubuntu/devel, and i'll tag it
<nacc> tjaalton: just don't dput until i tag it :)
<nacc> slangasek: then your rich history will be integrated at that point :)
<slangasek> that would be lovely
<tjaalton> ok, I'll look into it tomorrow
<slangasek> nacc: now, how can this be self-serve instead of blocking on a team of reviewers who are a small subset of uploaders
<nacc> slangasek: that's coming up next (once main is imported)
<slangasek> ok
<nacc> slangasek: we want people who can upload to a source package to be able to mark the MPs as approved
<nacc> actually, scratch that, we do want that, but that doesn't answer your question
<nacc> we have two approaches, and it's mostly about time/getting it right
<nacc> short-term: uploaders of a srcpkg can mark an MP as approved, the importer can look for approved MPs when it processes a new upload and integrate them
<nacc> (basically, as if they were upload tagged, without using upload tags)
<nacc> long-term: writing the hash into the source pkg before dput
<nacc> slangasek: in both cases, the uploader rights would determine the importer getting 'here is where rich history is' data
 * slangasek nods
<stanford_AI> do you know how to stream webrtc from /dev/video0 ?
<nacc> stanford_AI: please stop crossposting
<nacc> stanford_AI: also this is 100% the wrong channel.
<stanford_AI> why's that?
<nacc> stanford_AI: this channel is for development of Ubuntu (see /topic)
<stanford_AI> where do i go for app devel?
<nacc> !alis | stanford_AI
<ubottu> stanford_AI: Alis is an IRC service to help you find channels. For help on using it, see "/msg Alis help list" or ask in #freenode. Example usage: "/msg Alis list http"
 * stanford_AI msg Alis help list
<Unit193> Topic also mentions a channel.
<TJ-> Anyone familiar with how a Secure Boot via shimx64.efi is expected to handle the /EFI/ubuntu/grub.cfg ? Got a user where with S.B. enable it seems that might be be accessed causing grub to drop to the grub> shell. With S.B. off it works as expected.
<TJ-> s/might be be/might NOT be/
<roaksoax> TJ-: using grubx64 insteda of the shim
<slangasek> TJ-: are you sure that /EFI/ubuntu/grub.cfg is the issue, and not whatever /EFI/ubuntu/grub.cfg chains to?
<TJ-> roaksoax: right, the FW is cut-down/lock-down, so the boot menu has 2 options (shimx64.efi and grubx64.efi) but in S.B. mode only the shimx64.efi entry is available
<slangasek> TJ-: the difference between booting with secureboot on, and booting with secureboot off, is whether grub is allowed to load additional filesystem modules from disk
<TJ-> slangasek: yes, it contains the "search.fs_uuid " which matches the root-fs, but in S.B. mode the boot drops to "grub>" shell, without S.B. it boots fine
<TJ-> slangasek: right, I'm wondering if this FW is 'customised' and is blocking any non-signed files, not just modules
<slangasek> not possible
<slangasek> what is the root fs?
<TJ-> slangasek: FS type? ext4
<slangasek> interesting
<TJ-> lsblk: https://paste.ubuntu.com/p/gQwbjvjdRb/   /EFI/ubuntu/grub.cfg:  https://paste.ubuntu.com/p/chwS3YqHzY/  ls /boot/efi/  https://paste.ubuntu.com/p/K9SDxGy76N/  efibootmgr:  https://paste.ubuntu.com/p/dC93rQyxFp/
<slangasek> TJ-: how about the contents of /boot/grub/grub.cfg?
<TJ-> slangasek: I'll get them, I'm persuading the user to create a bug report now so we can capture the info
<roaksoax> fwiw, this looks like https://bugs.launchpad.net/maas/+bug/1711203
<ubottu> Launchpad bug 1711203 in shim (Ubuntu) "Deployments fail when Secure Boot enabled" [High,In progress]
<TJ-> roaksoax: thanks, no that's not it, we never get that far. the grub menu is never reached :)
<slangasek> TJ-: ok. bug reports against the shim-signed package in spanish are fine :P
<TJ-> slangasek: :) the only report close but has no follow up or decent details is  Bug #1110080
<ubottu> bug 1110080 in grub2 (Ubuntu) "[grub2] need to use grub command to boot kernel in UEFI Security boot" [Undecided,New] https://launchpad.net/bugs/1110080
<TJ-> "But after this grub2 run, the system enter into grub shell, it seems it doesn't load grub.cfg file."
<TJ-> User's bug report with attached files Bug #1761336
<ubottu> bug 1761336 in grub2 (Ubuntu) "Drops to grub> prompt in Secure Boot Mode" [Low,Confirmed] https://launchpad.net/bugs/1761336
#ubuntu-devel 2018-04-05
<RAOF> Ooops. GPG smartcards work better when you're not accidentally SSH'd into a remote system and wondering why it can't find your smartcardâ¦
<sil2100> oSoMoN: hey! I'm looking at the libreoffice SRU from you - any reason the debian/changelog mentions unreleased versions like 1:5.4.5-0ubuntu0.17.10.1, 5.4.5-0ubuntu0.17.10.5 etc.?
<oSoMoN> sil2100, they were released, as security updates
<sil2100> oSoMoN: oh
<sil2100> oSoMoN: you're right! A new upstream release as a security update? Wow ;)
<sil2100> oSoMoN: anyway, thanks!
<TJ-> is there an LP 'package' to report issues against the seeds?
<oSoMoN> sil2100, they were minor updates, fixing a couple of CVEs
<cjwatson> TJ-: historically they've usually gone on the appropriate *-meta package
<TJ-> cjwatson: I thought so mut my search-fu was lacking which one ... thanks
<TJ-> cjwatson: I'm trying to find the correct package to reassign to for a 'installer should provide XXX VPN not PPTP out of the box' but LP package search isn't helping me. bug #1752417
<ubottu> bug 1752417 in network-manager (Ubuntu) "Out of the box, Ubuntu Bionic offers only insecure VPN option" [Medium,Triaged] https://launchpad.net/bugs/1752417
<cjwatson> TJ-: from your description that sounds like ubuntu-meta, then.  I haven't spent any time thinking about the bug
<TJ-> cjwatson: thanks... weird, recently I've noticed LP searches seem to come up incomplete. I did the package search and that one didnn't show, only ubuntustudio-meta. I feel/see this doing bug searches too the last couple months.
<TJ-> to be clear, not a search via the bug tracker 'also affects distro/package' interface, but from e.g. https://launchpad.net/ubuntu/+search?text=-meta
<sil2100> oSoMoN: ok, looks good, approving - but eh, again the tools seem to hang on it, will have to do it manually (package too big probably)
<cjwatson> TJ-: That's site search, which you probably shouldn't expect to give you accurate package name results ...
<TJ-> cjwatson: ahhh!
<oSoMoN> sil2100, thanks
<TJ-> cjwatson: bug search not matching on phrases in bug titles is something I've been noticing though
<cjwatson> TJ-: but the reason it didn't find ubuntu-meta is that it's 'All packages with binaries whose name includes "-meta"' and ubuntu-meta ships no such binaries
<cjwatson> TJ-: that's all best-effort, in general, but if you have a specific example we can look
<cjwatson> (sorry, not site search, but a binary package name search.  I misread the URL.)
<TJ-> cjwatson: Ahhhhh... thank you for the explanation. I'll keep tabs on the bug searches now see if there is a pattern
<Nafallo> juliank: hi. do you have time for an apt related Ubuntu 16.04 issue I'm having? :-)
<juliank> Nafallo: A bit.
<Nafallo> juliank: the apt updates kick in before I have time to set the corporate proxy, which means the lockfiles kick in when I'm trying to use apt through ansible. this is for client installations I'm doing automatically.
<Nafallo> juliank: would there be an easy way to stop the processes cleanly before I run my stuff? :-)
<juliank> Why can't you set the proxy first?
<juliank> and no, if it's running upgrades there's no way to stop it cleanly.
<juliank> (if it's just downloading, you can probably send SIGINT to the apt process)
<Nafallo> I'm not sure the user is behind the proxy. they may be out of office when installing. I've got a desktop icon for applying the corporate settings when they are in the office or via VPN :-)
<Nafallo> well, it should be sitting on network timeouts since it may be in the office after all :-)
<Nafallo> the problem is I have both use cases at the same time on hundreds of users across the globe ;-)
<Nafallo> SIGINT. I'll try that. thanks :-)
<Nafallo> (unless I can figure out a way to work around this problem entirely.)
<juliank> Nafallo: I think best might be to set a proxy script for apt that looks at the network state and returns the proxy.
<juliank> Now I need to find an example
<juliank> The script needs to write http:// URLs, or DIRECT to its stdout
<juliank> And then you need to set acquire::http::proxy-auto-detect to it's path.
<juliank> e.g. acquire::http::proxy-auto-detect "/usr/local/bin/find-proxy";
<seb128> tsimonq2, you should teach your ubiquity triaging script to not set to incomplete other tasks than the ubiquity one
<seb128> tsimonq2, it seems to change all the tasks, it reopened some components which were set as invalid to set them incomplete for example
<Nafallo> juliank: oh. that's actually nicer then setting it explicitly.
<juliank> Nafallo: one caveat is that it does not work for https repos with http proxies prior to artful
<juliank> or maybe I fixed that earlier
<juliank> hmm
<Nafallo> heh, I'm not doing https during the installation :-)
<juliank> nah
<juliank> good then it works fine for you
<Nafallo> I'm already using `wget -q -t 1 -T 10 --spider https://www.ubuntu.com` to figure out network status. so just need to wrap that up :-)
<tsimonq2> seb128: ack, sorry
<seb128> tsimonq2, np, thanks for fixing!
<Nafallo> juliank: https://paste.ubuntu.com/p/HcVVnst7Zm/ that should do then :-)
<juliank> Nafallo: Come on, at least use if check_network; then echo "DIRECT"; else echo "http:/..."; fi - checking twice is weird :D
<Nafallo> hehe
<Nafallo> fine ;-)
<tjaalton> I don't understand how git-ubuntu is supposed to work
<tjaalton> cannot create user data directory: /home/tjaalton/snap/git-ubuntu/391: Not a directory
<tjaalton> while it surely is
<juliank> tjaalton: sounds like a snap problem
<tjaalton> ok
<juliank> tjaalton: so /home/tjaalton/snap/git-ubuntu/391 is an existing directory?
<juliank> or /home/tjaalton/snap/git-ubuntu/ is one?
<Nafallo> juliank: https://paste.ubuntu.com/p/kSV9ntqhcW/ ;-)
<juliank> Nafallo: that's nicer
<Nafallo> missed an END :-)
<tjaalton> juliank: 391 is, created just now
<tjaalton> when I first ran it, I guess
<juliank> odd stuff
<juliank> mvo: ^
<tjaalton> should there be a manpage for git-ubuntu?
<tjaalton> nevermind, I'll do it manually
<tjaalton> though I don't know how to create a merge proposal..
<Guest7888> tjaalton: what are you trying to do? Maybe I can help, I use git-ubuntu
<Guest7888> geez, guest?
 * Guest7888 fixes that, don't know what happened
<tjaalton> trying to create a merge proposal for pam
<tjaalton> cloned the ubuntu/devel branch, added a commit, pushed it to lp:tjaalton
<Guest7888> tjaalton: there is "git ubuntu submit", but I'm not sure it's working
<Guest7888> tjaalton: what I do is go to lp's code page, +git path, find your repository, branch, and click submit merge proposal
<Guest7888> then the target should be ubuntu/devel if it's for bionic, or something like ubuntu/xenial-devel for example if it's for xenial
<tjaalton> I don't see a way to propose a merge here https://code.launchpad.net/~tjaalton/+git/pam/+ref/ubuntu/devel
<cjwatson> you pushed it to the wrong place
<cjwatson> that's the URL scheme for personal repositories that aren't connected to anything else
<tjaalton> why of course
<cjwatson> you need to push to lp:~tjaalton/ubuntu/+source/pam
<tjaalton> alright, seems to work now.. thanks
<tjaalton> nacc: ^ sent now
<mvo> tjaalton: sorry, missed the earlier messages, is there still a issue with snaps and if so, can you share some more details please?
<tjaalton> mvo: "git ubuntu" doesn't work here
<tjaalton> it just says "cannot create user data directory: /home/tjaalton/snap/git-ubuntu/391: Not a directory
<tjaalton> upgraded to bionic today, installed the snap
<tjaalton> first snap on the system
<ahasenack> rbasak: ^is that the stable snap?
<ahasenack> I have edge 409
<tjaalton> git-ubuntu 0.7.4+git16.0a79cbc from 'nacc' installed
<tjaalton> installed on my laptop now, seems to work there
<tjaalton> both bionic
<mvo> tjaalton: oh, first snap - ok, that might be an issue, we have a bug there that we are chasing for first installs
<mvo> tjaalton: as a workaround (sorry for this): snap remove git-ubuntu and install it again, does that help?
<tjaalton> mvo: didn't help
<mvo> tjaalton: thats interessting, I'm in a meeting right now but would love to debug this with you
<tjaalton> ok
<mvo> tjaalton: does "SNAP_CONFINE_DEBUG=1 git ubuntu" give you useful debug output?
<tjaalton> mvo: not really. one thing is that /home itself is a symlink
<mvo> tjaalton: aha, thats it
<mvo> tjaalton: sitll in a meeting but I think we have forum post describing a fix, the non-standard /home is not well supported right now :/
<tjaalton> ok
<mvo> tjaalton: the first feedback I got: "when home is a symlink all things fall apart, it's not supported we recommend bind mounts instead" - I think jdstrand has a solution using apparmor tunables to make snaps work when /home is a symlink but I forgot the location of where this is documented
<ahasenack> tjaalton: your /home is a symlink because not all apps do the right thing and get a user's home from /etc/passwd or other nsswitch source?
<ahasenack> and just assume /home always?
<tjaalton> ahasenack: the real target is under nfs rootfs
<tjaalton> iirc bind mounts had issues with that
<tjaalton> also on a different fs than root
<jdstrand> mvo (cc tjaalton): apparmor can be made to handle that with a tunable, the problem is snap-confine harcodes /home and so only the bind mount trick works
<jdstrand> I *think* zyga may be looking at that at some point
<tjaalton> I have home on a zpool, maybe the symlink was due to bind-mounts happening before zfs was up? can't remember
<ahasenack> I also have my home in a zfs dataset
<ahasenack> everything but /boot, actually
<tjaalton> this is separate from the root disk
<tjaalton> and rootfs is ext4
<tjaalton> yep, moving the link aside, creating $home and adding a bind mount fixed it
<tjaalton> we'll see what happens next boot..
<nacc> tjaalton: reading backscroll
<tjaalton> nacc: heh, pam pull req
<nacc> tjaalton: we create an appropriate remote for your user under the name <lpname>
<nacc> tjaalton: ack
<doko> tjaalton: dogtag ftbfs
<tjaalton> doko: yep
<awe_> jbicha, any thoughts on the nm test-link failures I'm seeing?
<jbicha> awe_: have you used sbuild before?
<awe_> yes, but not in a long time
<awe_> right, sbuild handles cross-compiles..., and since I'm building native, debuild was my usual default
<jbicha> I don't recommend using debuild locally to build packages and I've no experience with pbuilder in a long time so sbuild is it
<jbicha> *it is
<awe_> ok, I'll give sbuild a try, but will also try on another laptop running 18.04 natively
<jbicha> sbuild is basically what the LP and Debian official builds use
<awe_> ack
<jbicha> there is a way to use nocheck Debian build profile to skip the build tests but I'm a bit fuzzy on how exactly you would set it
<awe_> ok, I can look that up. good suggestion
<jbicha> it looks like it works for me if I have this line in ~/.sbuildrc
<jbicha> $ENV{'DEB_BUILD_OPTIONS'} = 'parallel=4, nocheck'
<jbicha> you don't need the    parallel=4,  part but that's useful too :)
<jbicha> maybe DEB_BUILD_OPTIONS=nocheck debuild â¦ would work for you?
<jbicha> some documention about build profiles can be found at https://wiki.debian.org/BuildProfileSpec
<awe_> jbicha, yes that worked (DEB_BUILD_OPTIONS=nocheck debuild -us -uc)
<awe_> thanks for the help!
<jbicha> cool :)
<kasper> hi, i am trying to find build script that created https://packages.ubuntu.com/bionic/liblldb-6.0-dev package on ubuntu side
<kasper>  on llvm side, they have cmake, but i want to see what parameters ubuntu package script passed to cmake to build it
<kasper> previous versions of this package in ubuntu repos; liblldb-5.0-dev, liblldb-4.0-dev etc. were packaging this directory https://github.com/llvm-mirror/lldb/tree/release_60/include/lldb/API, but this new 6.0 package is missing it (although release_60 branch has it)
<kasper> since lldb 6.0 is going to be default package in bionion repo, i am afraid we end up having incomplete package :(
<kasper> reported https://bugs.launchpad.net/ubuntu/+source/llvm-toolchain-6.0/+bug/1761009, i was thinking about working on a patch to fix it myself but couldn't find package build script..
<ubottu> Launchpad bug 1761009 in llvm-toolchain-6.0 (Ubuntu) "LLDB.h is missing from liblldb-6.0-dev package" [Undecided,New]
<sarnold> kasper: if you're already running bionic, you can use "apt-get source liblldb-6.0-dev" to download the thing
<sarnold> if you're not, it'll take a bit more work
<doko> kasper: https://launchpad.net/ubuntu/+source/llvm-toolchain-6.0
<kasper> thanks!
<kasper> doko, my cmake skills are not top-notch, but do you think this is a bug in lldb's cmake script (something changed between release_50...release_60) or packaging script that is invoking cmake (some missing/misplaced cmake parameter)?
<kasper> i can try troubleshooting it. i am using bionic text-mode atm :)
<sarnold> most debian package builds go through debian/rules
<sarnold> it's a Makefile in all but name
<sarnold> so be careful with those tabs vs spaces :)
<kasper> both debian and ubuntu liblldb-6.0-dev packages have this directory 'usr/lib/llvm-6.0/include/lldb/API' but it is empty
<kasper> i guess we inherit this problem from llvm-official repos listed here http://apt.llvm.org/
<nacc> kasper: it would appear to be oversight, given that llvm-5.0-dev has those files?
<nacc> *lilldb-5.0-dev
<kasper> yup i can confirm that 3.4, 3.5, 3.6, 3.8, 3.9, 4.0, 5.0 all have headers in this directory
<nacc> kasper: should be relatively easy to diff the debian dirs of botyh source packages
<kasper> nacc, in fact i reported it upstream few days ago https://bugs.llvm.org/show_bug.cgi?id=36770, was trying to verify on gentoo whether it is a cross distro problem (i.e. something changed in lldb's cmake script).. but gentoo was giving me hard time to get to that point
<ubottu> llvm.org bug 36770 in deb packages "LLDB.h is missing from liblldb-6.0-dev package" [Enhancement,New]
<kasper> ah, just confirmed on fedor, https://www.rpmfind.net/linux/fedora/linux/development/rawhide/Everything/x86_64/os/Packages/l/lldb-devel-6.0.0-3.fc29.x86_64.rpm their API dir has all the headers
<kasper> s/fedor/fedora
<kasper> sarnold, 'apt-get source liblldb-6.0-dev' is giving me => Picking 'llvm-toolchain-6.0' as source package instead of 'liblldb-6.0-dev'
<kasper> then erroring out => E: Unable to find a source package for llvm-toolchain-6.0
<kasper> seems like package makefile sources aren't browsable on web either https://code.launchpad.net/ubuntu/+source/llvm-toolchain-6.0/+all-branches
<nacc> kasper: works fine here
<nacc> kasper: there are no repositories for llvm-toolchain-6.0 (yet)
<nacc> kasper: you can also use `pull-lp-source` which does not depend on your apt setup
<nacc> kasper: my guess is that you don't have deb-src lines in your apt config
<kasper> nacc, it's pretty much stock setup of bionic latest
<kasper> basically minimal installation
<kasper> docker run -it ubuntu:bionic
<nacc> kasper: which isn't necessarily a suitable development environemnt
<kasper> nacc, agree. atm i am trying to spot the issue, after that will delve into bionic proper
<kasper> nacc, couldn't find sources with pull-lp-source as well :(
<nacc> kasper: what did you run?
<kasper> pull-lp-source liblldb-6.0-dev --no-conf
<nacc> uh
<nacc> well, liblldb-6.0-dev is not a source pacakge
<nacc> as apt-get source told you
<nacc> kasper: pull-lp-source llvm-toolchain-6.0
<nacc> tjaalton: did my MP review comment make sense?
<kasper> cool, it is downloading tarballs :)
<tjaalton> nacc: yes, you'll have it tomorrow
<nacc> tjaalton: cool, just wanted to check, thanks!
<kasper> i could have fetched it form http://archive.ubuntu.com/ubuntu/pool/main/l/llvm-toolchain-6.0/llvm-toolchain-6.0_6.0.orig-lld.tar.bz2 :)
<nacc> tjaalton: otherwise the change looks good
<nacc> kasper: well, that's just one orig component tarball
<nacc> kasper: so wouldn't have done you any good
<kasper> nacc, thanks. `llvm-toolchain-6.0-6.0/lldb/include/lldb/API` has the files. could you please point me where i can find package script, so far i have only found source code of llvm/clang/lldb but not the launchpad script that builds the pacakge
<nacc> kasper: debian/rules
<kasper> nacc, thanks. nothing jumping out at me when looking at 'diff llvm-toolchain-5.0-5.0.1/debian/rules llvm-toolchain-6.0-6.0/debian/rules'
<nacc> kasper: it's not in the pacakging afaict, i think it's an upstrema issue
<tjaalton> kasper: file a bug on debian
<nacc> kasper: they look to have made some cmake changes upstream that are hard to decide if they are correct
<nacc> kasper: i agree with tjaalton though
<kasper> nacc, since fedora rpm not missing those files, could be that we need to build some additional cmake target, that wasn't required in v5 and earlier versions
<kasper> nacc, correct. i will do that
<kasper> can https://bugs.launchpad.net/ubuntu/+source/llvm-toolchain-6.0/+bug/1761009 be moved to debian, or do i have to close this one and open a separate one for deb?
<ubottu> Launchpad bug 1761009 in llvm-toolchain-6.0 (Ubuntu) "LLDB.h is missing from liblldb-6.0-dev package" [Undecided,New]
<nacc> kasper: you need to file one with debian
<kasper> nacc, if debian package is fixed, will ubuntu package pick up the changes automatically? i thought they are separate streams. spotted this issue on their build logs earlier https://buildd.debian.org/status/fetch.php?pkg=llvm-toolchain-6.0&arch=amd64&ver=1%3A6.0-1&stamp=1520022195&raw=0
<nacc> kasper: or fedora is undoing something
<nacc> kasper: not automatic, we are after freeze
<nacc> kasper: that build also has an empty API directory, afaict
<kasper> yup
<kasper> 0 files in that dir
<nacc> kasper: based upon the upstrema diff of lldb/source/API/CMakeLists.txt, it seems like the old build did some extra work
<nacc> tthe new build does something else, and it owuld need some debugging to see if that's the issue
<nacc> kasper: it looks like they moved from Headers to FrameworkHeaders
<kasper> nacc, lldb had some changes in cmake files between 5..6 but couldn't figure out what change is required from external callsite. was wordering, maybe it's worth checking out the diff between v5.0...v6.0 in rpm too?
<kasper> only if i know how to access makefile of rpm packages :D
<nacc> kasper: that's up to you :)
<kasper> maybe copr has it
<kasper> nacc, found this lovely link https://src.fedoraproject.org/rpms/lldb/c/763e3718e9c6339d991554c8c6468b488879beb6. they are using git and their git diff page is awesome :)
<kasper> seems like they haven't changed much either
<kasper> actually there is https://src.fedoraproject.org/rpms/lldb/c/44958ca9dee94ad785f30ab5b379e740b0d09344
<kasper> lldb issue after all :)
<kasper> they broke the installation of API headers in cmake
<kasper> more authentic/official patch is https://github.com/llvm-mirror/lldb/commit/8f577000b2fe2f5bf5d08e352a2f15f9421f9c82#diff-c6838f2ee3606027bb153637e8024bf5
<nacc> kasper: yes, i saw that diff, and wondered about it too
<kasper> nacc, would it be possible to ninja this one in before bionic final? *-*
<nacc> kasper: well it's a bugfix, so file the bug in ubuntu?
<nacc> kasper: and someone can
<kasper> https://bugs.launchpad.net/ubuntu/+source/llvm-toolchain-6.0/+bug/1761009
<ubottu> Launchpad bug 1761009 in llvm-toolchain-6.0 (Ubuntu) "LLDB.h is missing from liblldb-6.0-dev package" [Undecided,New]
<kasper> wrote it down in comment 3
<kasper> i have done some patchwork in pkgsrc few years ago (for netbsd), but never on Debian/ubuntu, so i might take longer than experts :)
<nacc> kasper: i'll build you a PPA version to test, will comment in bug when it's ready
<kasper> thank you! <3
<nacc> kasper: did you file a bug with debian?
<kasper> nope, i was almost going to file it, but then joined fedora-devel to figure out their diffs :D
<nacc> doko: fyi, you didn't run update-maintainer onthe last llvm-6.0-toolchain upload :)
<doko> nacc: I'm notorious about that :-(
<nacc> doko: np, i'll fix it on this upload, presuming it fixes the bug
<Faux>  
<Faux> ^ typo, ignore.
<sarnold> how is it determined what gets seeded? the reporter in 1752417 makes some good points that our default out-of-the-box vpn choice is pretty terrible
<Unit193> There's a default VPN choice?
<nacc> sarnold: the owning team(s) decide, roughly
<nacc> sarnold: based upon technical area
<sarnold> apparently PPTP is installed by default :/
<nacc> sarnold: pptp-linux ?
<sarnold> nacc: or perhaps network-manager-pptp-gnome
<nacc> sarnold: network-manager-pptp-gnome is a reverse-recommends of all the desktop metapackages
<nacc> it would seem
<nacc> so not directly from the seeds
<Unit193> ship-live: * pptp-linux                       # client for Microsoft-compatible VPN's, needed for some ISPs
<nacc> but there is that one --^
<nacc> again, live only, not preinstalled (afaict)
<Unit193> network-manager-pptp is under 'Basic network services and Windows integration.'
<cjwatson> I mean
<cjwatson> it dates back to warty
<cjwatson> it's possible it's not the most currently-motivated of choices
<sarnold> warty, wow :) I figured it was an old choice that had never been reexamined.. but wow. :)
<cjwatson> it's in r1 of the seeds
<tsimonq2> O_O
<cjwatson> it may be a little difficult to archaeologise a rationale now
<sarnold> "needed for some ISPs" was probably reason enough
<cjwatson> there was a pre-revision-control wiki seed list but I'm not sure any records of that still exist
<cjwatson> yeah, it might be helpful to know who suggested it because it might indicate what country
<cjwatson> first mention of it on warthogs@ I can find was Jeff Waugh suggesting it as part of a list of misc VPN software on 2004-05-29
<cjwatson> don't really see much serious discussion so I think it was almost certainly just dumped in from a "think of everything people might need to get online" kind of list
<jbicha> sarnold: you could probably get network-manager-openvpn-gnome in easily since its source pkg, network-manager-openvpn, is already in main
<sarnold> on the one hand we no longer have the "must fit on a CD" pressure to keep the size from going up, but .. I think that's still a self-imposed "lets not go crazy" kind of thing.
<robert_ancell> Does anyone know where the canonical-livepatch snap source lives? I want to get it to embed its icon into the snap.
<sarnold> lol, launchpad just gave me an OOPS-bad2dcfa884f2f58ab59239854b60434  :)
<sarnold> "bad"
<sarnold> why yes, I *am* easily amused ..
<Unit193> Not just bad, but 'bad2dc'.  You're bad to datacenters!
<sarnold> hahah
<jbicha> sarnold: I suggest you ask #ubuntu-desktop about default VPN support during work hours or you can use our "mailing list" https://community.ubuntu.com/c/desktop
<nacc> robert_ancell: i've pinged the folks who should know, i'll ask them to get in touch
<robert_ancell> nacc, thanks!
<sarnold> jbicha: somehow I've got a habit of arriving moments after will's "do your hobbies!" quit message :) hehe
<jbicha> sarnold: you only have about 3/4 of a second after he posts that before he's gone
<sarnold> *nod* :)
<jbicha> oh I mean after his "night all" message
<jbicha> it's a good strategy, prevents people from giving you more stuff to do on your way out the door
<sarnold> and his quit message is a useful reminder :)
<Unit193> People /quit?
<sarnold> Unit193: will does :)
<Unit193> Novel idea.
<sarnold> blank irc windows just give me the creeps
<tsimonq2> Glad I'm not the only one.
<Unit193> sarnold: What about windows that only contain the 'day changed' notice?
<sarnold> Unit193: *shudder* like window 4
<tsimonq2> I move all of those into one window.
<tsimonq2> Those annoy me.
<sarnold> I don't visit window 4
<Unit193> 'Day changed to 23 Feb 2018' there it is, right there.
<tsimonq2> I trust we're all using irssi, *right*? :P
<Unit193> Seth is.
<tsimonq2> I know, but I think Unit193 uses xchat.
 * tsimonq2 runs
<Unit193> Ain't no client like the best.
<wxl> tsimonq2: no, Unit193 uses silc.
<sarnold> haha
<sarnold> man that's a blast from the past ..
 * tsimonq2 googles
<tsimonq2> Oh, hah.
 * valorie started on mirc
<valorie> :-)
<sarnold> blaster from the paster ..
<valorie> now konversation
<sarnold> mirc was a nice step up from ws_irc
<valorie> irssi is fine for the geeks!
<wxl> i think my first was ircII
<wxl> or maybe EPIC
<wxl> whatever cleveland freenet was using way back when
<valorie> I remember all those names from making a webpage about them years ago
 * wxl beats everyone about the head with his cane
<valorie> for genealogists
<Unit193> openssl s_client.
<sarnold> an ircii script with an embedded backdoor was my introduction to unix security :D
<wxl> nice sarnold :)
<wxl> Unit193: hey at least you're secure.
#ubuntu-devel 2018-04-06
<slangasek> yeah, I certainly remember there being ISPs about where you couldn't get online without PPTP.  openvpn, I've not heard of that one being used by an ISP
<mr_lou> This bug was never fixed, but was closed anyway. https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1737671
<ubottu> Launchpad bug 1737671 in linux (Ubuntu) "Blu-ray burner no longer detected" [Medium,Expired]
<mr_lou> Am I the only one in the world in need of a working burner?
<valorie> mr_lou: it says expired
<valorie> give fresh info and it will reopen, afaik
<valorie> I burn DVDs at festivals and such to give away ISOs
<valorie> I don't have a blu-ray drive thought
<valorie> just a USB one
<mr_lou> valorie, There was another dude replying that he had the problem with his DVD burner too.
<mr_lou> But obviously not many people use burners these days, so replies will be scarce.
<mr_lou> valorie, What burner app do you use?
<mr_lou> I use ImgBurn via Wine, because that's the only option I have for burning Blu-ray discs (needs UDF 2.5 which Ubuntu doesn't have).
<valorie> I use k3b
<valorie> a bit old, but it still works
<valorie> no clue if it will do blu-ray
<mr_lou> I won't.
<mr_lou> Ubuntu doesn't have UDF 2.5
<mr_lou> *It won't
<mr_lou> k3b does seem to detect the drive. But doesn't give me Blu-ray options of course.
<mr_lou> But I find it odd that kernel 97 lets ImgBurn detect the burner, and all following kernels doesn't.
<mr_lou> Also tried with wodim and those. Also lets me burn "standard" stuff - but doesn't recognize a Blu-ray disc (of 25 gb). So trying to burn a blu-ray, wodim (and those) complains there's not enough room, which of course there is.
<mr_lou> Added more info. Still expired though.
<valorie> you might mention the bug number
<valorie> perhaps you will catch the interest of a devel who can fix it
<valorie> of course what is really wanted is a thorough analysis and a patch
<mr_lou> Gotta go to work.
<mr_lou> L8r
<tjaalton> my desktop is happy even with bind-mounted /home, so I guess something got fixed in the past two years that forced me to use a symlink :)
<GunnarHj> cjwatson, wgrant: What's the time frame for upgrading gettext? Doing so was the conclusion from the discussion we had last week with seb128 about bug #1756547.
<ubottu> bug 1756547 in Ubuntu Translations "LP refuses to import plural strings where e.g. msgstr[0] entries in PO file miss %d" [High,In progress] https://launchpad.net/bugs/1756547
<wgrant> GunnarHj: Not this month unless there's no reasonable workaround. I thought we'd discussed removing the JS declaration?
<wgrant> We can upgrade gettext if we really can't drop the JS declaration, but that's a lot easier.
<sunweaver> oh well... I just dput ayatana-indicator-power without option from a bionic chroot to $UBUNTU
<sunweaver> and I wanted to dput it to my personal PPA instead...
<GunnarHj> wgrant: Yes, we discussed that as a plan B. Seb and I hoped for plan A. :)
<sunweaver> in case anyone sees the upload, it should be REJECTed.
<GunnarHj> wgrant: Please note that even if the bug is about one specific package, this is a general problem. gettext got more permissive, and translators upstream have started to make use of that possibility.
<wgrant> sunweaver: 2018-04-06 10:06:10 INFO        GPG verification of /srv/launchpad.net/ubuntu-queue/incoming/upload-ftp-20180406-100554-003557/ubuntu/ayatana-indicator-power_2.0.93-2~ppa1_source.changes failed: Verification failed 3 times: ["(7, 58, u'No data')", "(7, 58, u'No data')", "(7, 58, u'No data')"]
<wgrant> sunweaver: It wasn't signed, so was summarily rejected :)
<wgrant> GunnarHj: I'm somewhat reluctant to do a major gettext upgrade on LP without thorough QA this late in an LTS cycle, but it's possible.
<GunnarHj> wgrant: I can't tell anything about the risks. But I understand that translators and users in the affected countries are not impressed.
<GunnarHj> wgrant: One way might be to try the workaround for one package to confirm that it works. As a base for decision.
<GunnarHj> seb128: I'm talking with wgrant about the gettext upgrade. Can we try the workaround for gnome-shell to check that it works as a base for decision? wgrant stresses that there are risks with upgrading gettext this late.
<wgrant> GunnarHj: We can do the gettext upgrade if we need to, but if it's just one or two packages affected I'd vastly prefer that their templates be revised.
<wgrant> Much lower risk for regression.
<wgrant> The gettext diff between xenial and bionic is one hundred and fifty thousand lines
<GunnarHj> wgrant: But it used at runtime...
<GunnarHj> wgrant: But let's try out the workaround, and try to figure out which packages are most affected.
<wgrant> GunnarHj: The gettext upgrade would certainly unblock gnome-shell, but given the size of the diff I can in no way be confident it won't block unrelated other packages in bionic or other series. I've only seen the javascript format outdatedness be an issue in gnome-shell, so I'm reluctant to risk the other 29124 packages in bionic based on that, but if the workaround isn't trivial and there are other
<wgrant> packages affected then I can dig in more depth.
<seb128> GunnarHj, it should be possible to override_dh_translations in debian/rules and sed away the javascript comments from the pot
<seb128> unsure how wrong that is though if the code is javascript
<seb128> and if that can create other issues
<wgrant> It's easy enough to validate a POT against xenial's gettext (hi LXD)
<wgrant> It's the first time I've run into the JS attribute, but I suppose their may be others.
<sunweaver> wgrant: thanks
<seb128> wgrant, right, validating is one think, knowing that the result is the one expect is another
<seb128> I've no clue what it change to have that format clue or not
<wgrant> I've never seen that cause trouble before, but it's possible.
<seb128> GunnarHj, well seems that safer approach would be probably at this point to sed those away from the debian/rules
<seb128> as it trying to do that and see what's the result
<GunnarHj> seb128: Ok. I'll fix a gnome-shell patch later today or Monday to start with.
<juliank> I see a weird test suite failure with apt in docker's ubuntu:bionic
<juliank> We create a temporary package with a changelog, and isntall it
<juliank> (in a different, temporary, rootdir)
<juliank> but there's no changelog in ithe installed package apparently
<juliank> on my own bionic system it works just fine
<juliank> for example, https://travis-ci.org/julian-klode/apt/jobs/363080996
<juliank> (APT falls back to HTTP, and thus fails the test)
<juliank> I just thought that maybe the docker image ships a dpkg.cfg.d snippet that disables changelog installing?
<juliank> I'm not sure if APT's test suite protects against dpkg.cfg files
<juliank> let's check, I guess.
 * juliank installs docker ... :(
<juliank> found /etc/dpkg/dpkg.cfg.d/excludes
<tjaalton> ahasenack: halp. I need sssd 1.16.1 for freeipa :P
<ahasenack> because of a bug fix?
<tjaalton> no, 4.7-pre1 needs it, and that's needed for sqlite nssdb support et al :/
<tjaalton> but, 1.16.1 really is worth it
<tjaalton> it's been on debian testing for some weeks, it works
<ahasenack> I'm not against it. It feels like you have more reasons for an FFe than I do
<ahasenack> you are a core dev, much easier for you to do it than I :)
<ahasenack> brb
<tjaalton> sure
<ahasenack> back
<ahasenack> tjaalton: you still prefer the newer freeipa version as opposed to revert the previous one, which didn't need nssdb?
<ahasenack> er, nss-pem
<tjaalton> we have nss-pem, and would need to go to 4.5
<tjaalton> even 4.6 doesn't work with current dogtag & certmonger which are needed to support sqlite nssdb's etc
<ahasenack> where is nss-pem? I don't see it in bionic
<tjaalton> libnsspem
<ahasenack> I see, new in bionic
<ahasenack> you got that in recently?
<tjaalton> yes
<ahasenack> it doesn't exist in debian yet, right
<ahasenack> I see 0ubuntu
<tjaalton> no, probably never will
<bdmurray> jbicha: Do you know if libwhoopsie-preferences is used anymore in gnome-control-center?
<jbicha> bdmurray: yes, it's used in Privacy > Problem Reporting
<jbicha> that's new in 17.10, we used to just use activity-log-manager for that UI
<bdmurray> jbicha: okay, but the metrics stuff is not being used right?
<jbicha> you mean being able to see old reports sent from your computer? that wasn't implemented in GNOME
<bdmurray> jbicha: No I mean in 16.04 there used to be a toggle to "Send occasional system information to Canonical" and I don't see that anymore.
<bdmurray> jbicha: Which makes sense because it didn't do anything...
<jbicha> oh
<jbicha> presumably we need to have a knob for something like that in gnome-control-center to match what we will ask in gnome-initial-setup
<jbicha> but I'm not aware of anyone working on that, might not happen for 18.04's release
<bdmurray> but that wouldn't use whoopsie correct?
<jbicha> um, ubuntu-report I guess (and its included sysmetrics library)
<kasper> nacc, thanks for the update! :)
<nacc> kasper: yw!
<kasper> nacc, would it be available in official bionic repo right away once the decision is made by bionic-proposed folks?
<nacc> kasper: right, we're in freeze right now, so it has to be accepted, which it should be as a bugfix
<nacc> kasper: but presuming that is the case, it will go in to bionic release. Worst case, bionic-updates
<kasper> nacc, hopefully they will recognize the upstream bug and accept it (forgoing the late report)
<slangasek> nacc: so I was looking at whether to merge new upstream cryptsetup from Debian; MoM made a hash of it because we had a -0ubuntu1 in Ubuntu for a previous upstream version; so I took a look at using git-ubuntu instead and it leaves me the entire upstream diff to be sifted through as part of the rebase.  Any hints?
<nacc> slangasek: looking
<slangasek> doesn't seem like it should be a manual thing to piece through which bits of the diff are part of the new upstream tarball and which not
<nacc> slangasek: right, we could improve that, in theory
<nacc> we don't special-case a new upstream version at all
<nacc> so to git-ubuntu, it's just a huge delta added
<nacc> (well, to git, via git-ubuntu)
<nacc> we would need to do some in-repo tree creation to figure out what is in the orig tarball that is used, etc. but it's doable
<slangasek> yeah; if I have to manually reconcile the diff against the upstream tarball, that's basically no different than what I'd already be doing with MoM
<nacc> right, it's also ... phrased a bit funny
<nacc> it was a merge, but only sort of
<nacc> (2:2.0.1-0ubuntu1)
<nacc> since there is no merge target there, really
<nacc> slangasek: it's certainly a gap, i'd need to think about it a bit to decide what should be done
<nacc> now, you *could* do some git-foo locally to help out, i suppose
<nacc> slangasek: like save your current state
<nacc> go back to the old/debian
<nacc> update the orig tarball contents only
<nacc> tag that tree/commit
<nacc> rebase onto it
<nacc> I *believe* git will handle that 'ok', since the tree-wise contents of your 'current state' and the 'orig state' should hash out for all files
<nacc> slangasek: but yeah, we're not better than MoM here, you're right; please file a bug
<slangasek> nacc: also, if I diff against pkg/upstream/debian/2.0.1.gz it doesn't match, so that's fun
<nacc> slangasek: i would diff against pkg/upstream/ubuntu/2.0.1.gz
<nacc> slangasek: given that it's an ubuntu upload?
<nacc> slangasek: but i'd need to investigate manually to help debug why it doesn't match, if it doesn't
<slangasek> nacc: no such tag
<slangasek> I looked for that first
<nacc> slangasek: hrm
<nacc> slangasek: i need to go afk for a bit, but i can try and look in the afternoon
<nacc> slangasek: it's possible that, since we import debian first, the debian tarball did end up matching
<slangasek> nacc: sure.  anyway, LP: #1761853
<ubottu> Launchpad bug 1761853 in usd-importer "merge of a -0ubuntu1 vs new upstream in Debian requires manual resolution of upstream diff" [Undecided,New] https://launchpad.net/bugs/1761853
<nacc> slangasek: thanks
<slangasek> nacc: and it looks like the pkg/upstream/debian/2.0.1.gz tag may be missing all the autotools autogenerated files... not sure what to make of that
<slangasek> nacc: it's possible that's an indicator the Debian tar.gz did not match the Ubuntu one
<nacc> slangasek: right, i'll dig into it
<kasper> nacc, does '(Accepted)' mean it is through already: https://lists.ubuntu.com/archives/bionic-changes/2018-April/013233.html ?
<nacc> kasper: no, you'll see it in the bug when the fix is through
<nacc> kasper: it's currently in bionic-proposed
<nacc> slangasek: ok, yeah ther's something wonky with the import, i'm running it manually
<nacc> slangasek: the ubuntu upload was 2.0.1.orig.tar.xz
<slangasek> ah
<nacc> while debian is 2.0.1.orig.tar.gz
<nacc> so they definitely wouldn't match
<slangasek> right
<nacc> but we support that, so i need to reproduce to find out why
<slangasek> and indeed the Debian one is generated without any of the autotools bits
<nacc> right -- i'll dig intoi the pristine-tar stuff ater my 1x1
<nacc> and in fact git ubuntu export-orig notices this and complains and then falls back to pull-lp-source behavior
<slangasek> nacc: right, meanwhile I'm uploading a MoM-merged cryptsetup 2.0.2-1ubuntu1, so apologies if this complicates your test case
<nacc> slangasek: it's fine, thanks!
<nacc> tjaalton: slangasek: pam upload tagged and sponsored [with rich history now]
<tjaalton> nacc: thanks!
<nacc> tjaalton: ty!
<slangasek> sw33t
<kasper> nacc, just trying to understand Ubuntu's process during the freeze; is there anything criteria like 'when X number of bionic-proposed testers will say yay', then the fix gets released? Or is there a committee/shiproom that makes the final call?
<kasper> s/anything/any
<nacc> kasper: bugfixes generally are always allowed in, but when ISOs are being spun, etc, some things are held off (aiui) if they affect the ISO contents
<nacc> kasper: we are in a state now, where uploads to seeded things (llvm being one of them) need to be manually accepted
<sarnold> -proposed in the devel releases is discouraged for manual testing; autopkgtests migrate packages out of -proposed as they pass tests
<nacc> kasper: in this case, it was, so it just needs to migrate https://launchpad.net/ubuntu/+source/llvm-toolchain-6.0
<nacc> kasper: err, http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#llvm-toolchain-6.0
<nacc> which shows we are waiting for some builds to finish
<kasper> nacc, great! is this the release build queue?
<cjwatson> it's ... just the build queue
<nacc> kasper: yeah, not sure what you mean by 'release'?
<cjwatson> takes a while to build LLVM, is all
<kasper> nacc, the last status on bug page is 'Fix Released', so i thought that's a shared term :)
<nacc> kasper: https://bugs.launchpad.net/ubuntu/+source/llvm-toolchain-6.0/+bug/1761009 is "Fix Committed"
<ubottu> Launchpad bug 1761009 in llvm-toolchain-6.0 (Ubuntu) "LLDB.h is missing from liblldb-6.0-dev package" [Undecided,Fix committed]
<nacc> kasper: because I have uploaded it and it's in bionic-proposed now ... but it has not been Released yet
<kasper> yup, the next one is the last, so my eyes were on that one
<nacc> kasper: sorry, I don't parse that, but I think you understand now?
<kasper> nacc, totally! the bits you have explained ;)
<nacc> kasper: :)
<slangasek> nacc: your pam upload was built without -i -I and includes a .git directory; is that intentional?
<Unit193> Gah, looks like LP 1754781 got ignored. :/
<ubottu> Launchpad bug 1754781 in irssi (Ubuntu) "Please merge the latest bug release, 1.0.7-1, from Debian" [Undecided,New] https://launchpad.net/bugs/1754781
<nacc> slangasek: bah, no it was not
<nacc> slangasek: if you can reject, i can reupload, or i can reupload now
<slangasek> nacc: please go ahead and reupload and I'll reject the previous upload
<nacc> slangasek: thanks
<nacc> slangasek: sorry about that, was moving too quick before an errand
#ubuntu-devel 2018-04-07
* slangasek changed the topic of #ubuntu-devel to: Archive: feature freeze | 18.04 final beta released | Devel of Ubuntu (not support or app devel) | build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of trusty-artful | #ubuntu-app-devel for app development on Ubuntu
<kasper> when we do a version-less `apt install lldb` on bionic, it gives us llvm-6.0, clang-6.0, lldb-6.0 and liblldb-6.0
<kasper> but why the same doesn't work for `apt install liblldb-dev` ?
<kasper> we need to explicitly specify the version `apt install liblldb-6.0-dev` ..
<kasper> is there a concept of default version, or is merely matches the string from start?
<acheronuk> jbicha: pipewire likely to get into 18.10 I assume?
<cjwatson> kasper: 'apt install lldb' works because there is a package called lldb which does nothing except declare dependencies on those other packages.  No magic.
<darkxst> is anyone in the Ubuntu/Debian world looking into FMV: https://clearlinux.org/blogs/transparent-use-library-packages-optimized-intel-architecture
<darkxst> are Clear Linux really the only ones making user of this?
<tjaalton> what's the current replacement for "ifup"?
<tsimonq2> netplan? hmm
<tjaalton> so /etc/network/interfaces is not used at all?
<tsimonq2> https://lists.ubuntu.com/archives/ubuntu-devel-announce/2017-June/001215.html
<tsimonq2> Â¯\_(ã)_/Â¯
 * tsimonq2 lets someone who knows more about the networking stack answer
<tjaalton> yeah, fun
<tjaalton> I still have /e/n/i
<joelkraehemann> hi all
<joelkraehemann> https://tracker.debian.org/pkg/libinstpatch
<joelkraehemann> ^^ do you need a sync request?
<jbicha> joelkraehemann: do you have a Launchpad account?
<joelkraehemann> jbicha: Yes, I do have one.
<joelkraehemann> well, I can't do so because it was recently uploaded
<jbicha> yeah, wait a few hours and use requestsync (from ubuntu-dev-tools) is preferred
#ubuntu-devel 2018-04-08
<joelkraehemann_> https://bugs.launchpad.net/bugs/1762143
<ubottu> Launchpad bug 1762143 in libinstpatch (Ubuntu) "Sync libinstpatch 1.0.0-7 (universe) from Debian unstable (main)" [Undecided,New]
<joelkraehemann> http://autopkgtest.ubuntu.com/packages/gsequencer/bionic/s390x
<joelkraehemann> ^^ it passes, now.
<joelkraehemann> Why is it building against libinstpatch-1.0.0-6 instead of libinstpatch-1.0.0-7?
<joelkraehemann> http://autopkgtest.ubuntu.com/packages/gsequencer/bionic/s390x
<nacc> slangasek: figured out the issue with cryptsetup -- it's not a bug in git-ubuntu itself, pristine-tar (via gbp-import-orig) is not able to integrate the ubuntu tarball
<nacc> my guess is a non-standard xz flag
#ubuntu-devel 2019-04-01
<tjaalton> RAOF: did you accept intel-mediasdk? :)
<tjaalton> many thanks if so, there's also intel-opencl-clang on the queue.. -graphics-compiler and -compute-runtime are on then way
<tjaalton> *the
<RAOF> tjaalton: yup! I don't suppose there's any way to do this without having three copies of llvm in the archive ð
<tjaalton> RAOF: all I care about is already on llvm 8 (including mesa), I'm not sure if we can drop older ones yet.. I'll have a look though
<RAOF> That was snark on my part. I haven't looked at intel-opencl-clang yet. You mean it doesn't include its own llvm fork?!
<tjaalton> ah.. it doesnt'
<tjaalton> intel-cm-compiler kinda does, but it's a clang based compiler so doesn't actually ship clang
<tjaalton> but it's not strictly needed at this point, only when we want to build the media shaders from source
<tjaalton> "Opencl-clang is a thin wrapper library around clang"
<tjaalton> :)
<rbalint> RAOF, also thanks for waylandpp if you accepted that, too! :-)
<rbalint> btw i can't trigger autopkgtests manually, i get gateway timeouts :-(
<rbalint> can i please get the ff exception for LP: #1822341?
<ubottu> Launchpad bug 1822341 in ubuntu-meta (Ubuntu) "[FFE][SRU] Please add ubuntu-wsl binary package" [Undecided,New] https://launchpad.net/bugs/1822341
<acheronuk> sil2100: why does this bileto ticket only see one source package, when there are 66 in the PPA? https://bileto.ubuntu.com/#/ticket/3680
<ahasenack> Hi, I'm having a dep8 test failure in cosmic in what seems to be a math rounding error, I vaguely remember something like this when glibc was upgraded in one of the cycles, but can't remember it well. it's only happening on i386: https://bileto.ubuntu.com/excuses/3686/cosmic.html
<ahasenack> I added some debugging, and this is what I get: https://pastebin.ubuntu.com/p/gDwknD4rZK/
<ahasenack> ganhei um bounce, peraÃ­
<ahasenack>     Recipient address rejected: User unknown in virtual alias table
<ahasenack> ops
<ahasenack> sorry
<ahasenack> wrong channel (the pt_BR and bounce bits)
<xnox> jamespage, how come nova-compute-libvirt and nova-network depend on package 'vlan' which as far as i can tell useless.
<xnox> jamespage, and like if any vlan stuff is needed to be done by libvirt, it should be like using iproute2/netplan/networkd and not ifupdown....
<xnox> jamespage, we shouldn't need to install vlan package at all anymore.
<cpaelzer> xnox: libvirt used to use netcf (for ifupdown) but this didn't work in the networkd world anymore
<cpaelzer> furthermore it was an unused (and unwanted) feature to control networking through libvirt
<cpaelzer> due to that the netcf dependency and feature was droped I think at Bionic or Cosmic
<cpaelzer> not sure what it would do with vlan, but you said that is a dependency of nova right?
<xnox> cpaelzer, should the vlan dep be then dropped from nova-network and nova-compute-libvirt then as well? i don't see those calling ifupdown/vconfig or anything like that.
<xnox> cpaelzer, not sure if that dep was added because it used to be used indirectly via libvirt...
<cpaelzer> from libvirt's POV it isn't neede dthere
<cpaelzer> waiting for jamespage to answer the nova POV on this
<xnox> coreycb, https://review.openstack.org/#/c/635533/3 did you include that in ubuntu's nova now? or are you still waiting on usptream to incorporate that?
<xnox> coreycb, we are in final stages of pushing openssl 1.1.1 update into bionic, and we will need that patch in bionic's nova.
<xnox> jibel, hmmmm.... is one supposed to configure /etc/utah/config on per-arch basis? or do we need to install/detect the right things on per-arch basis?
<xnox> jibel, i see that ppc64 jobs are using the wrong libvirt xml file. THye use default-vm.xml instead of default-vm-ppc64.xml
<xnox> and i'm not sure how/where/why it's configured that way.
<jibel> xnox, it's defined in https://bazaar.launchpad.net/~canonical-platform-qa-jenkins/qa-jenkins-jobs/trunk/view/head:/scripts/iso-testing/run-iso-test.sh
<jibel> but there is no way to override it apparently
<xnox> right
<xnox> jibel, and we (a) don't generate bridged-network-vm.xml for ppc64le & s390x b) don't use them.
<xnox> jibel, i guess i can extend utah to generate those and make that script use per-arch xml files then.
<xnox> let me try to do some typpy typpy
<coreycb> xnox: i was waiting for it to land upstream first
<coreycb> xnox: sounds like we need to expedite this to get back to bionic
<xnox> jibel, it looks like in some jobs run-iso-test.sh is carbon copied included and changes the -xml arg. but in other praces the script is used, but arch argument is passed. So just updating the script should do the trick to unbreak ppc64le.
<xnox> jibel, could you please review https://code.launchpad.net/~xnox/qa-jenkins-jobs/enable-per-arch-xml/+merge/365357 or should i like self merge that?
<xnox> coreycb, not quite expedite, but we need it. also it means nobody to date uses that bit of code on any recent releases, cause clearly xenapi+openssl1.1.1 is busted.
<jibel> xnox, merged
<jibel> xnox, there is no config for s390x on venonat
<xnox> jibel, tah.
<xnox> jibel, and no s390x jobs yet.
<wxl> â
<wxl> ooh that was a fun oopsie
<Eickmeyer> Updated screenshot for Ubuntu Studio's slideshow in bug 1822663.
<ubottu> bug 1822663 in ubiquity-slideshow-ubuntu (Ubuntu) "Update Ubuntu Studio Screenshot in Slideshow" [Undecided,New] https://launchpad.net/bugs/1822663
<Eickmeyer> (includes patch)
<Eickmeyer> cyphermox: ^
<cyphermox> ack
<seb128> jdstrand, hey, just as a fyi ipset/firewalld needed to be hinted to be tried together from proposed, I did that and they both migrated now. Thx for the work dealing with the iptables/ebtables side of things
<robert_ancell> infinity, did you approve the snapd-glib packages in NEW in cosmic? If so, can you do the same for bionic/xenial?
<cyphermox> Eickmeyer: could you please just attach the image file in it's entirety instead? it'll be much easier to update that way
<Eickmeyer> cyphermox: Okay, sure thing.
<infinity> robert_ancell: I did, and I can go look, sure.
<robert_ancell> infinity, thanks!
<Eickmeyer> cyphermox: Done.
<infinity> robert_ancell: Intentional that xenial doesn't ship test-qt?
<robert_ancell> infinity, yes, we never added qt support to xenial
<infinity> Kay.
<infinity> robert_ancell: Processed.
<robert_ancell> infinity, cheers
#ubuntu-devel 2019-04-02
<cpaelzer> can I have some opinions on https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/1822370/comments/9
<ubottu> Launchpad bug 1822370 in openssh (Ubuntu) "19.04 beta openssh-client broken pipe" [Critical,Triaged]
<cpaelzer> cjwatson: as it is openssh your opinion would be expecially great to ahve
<cjwatson> cpaelzer: did you look through Debian bugs?  it has certainly been reported there.
<cjwatson> I consider this a VMware bug and if anyone is pushing for this we need to put pressure on VMware to fix it.
<cpaelzer> not yet, I was collecting through vmware and fedora references so far
<cpaelzer> I consider this a VMWare bug as well
<cpaelzer> may question is if we should avoid putting it on our users due to the upcoming release
<cjwatson> I don't want to revert this as that just takes the pressure off.
<cjwatson> It's not an LTS after all
<cpaelzer> ok, I'd be happy if you could state so in the bug
<cpaelzer> I have a call today with VMWare anyway and can make sure this is really seen on their side
<cjwatson> done
<cpaelzer> thanks
<cjwatson> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=923879 is a more persuasive reason to possibly revert
<ubottu> Debian bug 923879 in openssh-client "ssh: IPQoS defaults change interacts badly with iptables -m tos" [Normal,Open]
<cjwatson> but I haven't had time to independently research that
<bdmurray> seb128: Do you know if anything is happening with bug 1807900?
<ubottu> bug 1807900 in update-manager (Ubuntu Bionic) "update-manager suggests to use Livepatch, which is not available" [High,Triaged] https://launchpad.net/bugs/1807900
<Laney> rbasak: you have ~ubuntu-developer-members available, FWIW (re: devel-permissions@)
<Laney> (specifically your last paragraph)
<rbasak> Laney: thanks! I was going to ask you for input, as a person who comes to mind who understands how it's all put together :)
<Laney> It's the not-very-used DMB-as-a-membership-board procedure
<rbasak> Laney: would ~ubuntu-dev be better to retain voting rights though?
<rbasak> Assuming the DMB is happy to do that, which I suppose is a separate decision.
<rbasak> As we don't have any documented emeritus process AFAICT.
<Laney> I'm not sure that there's precedent for ~ubuntu-dev without any upload rights
<Laney> So you'd be inventing a new thing there AFAIK
<rbasak> I agree it'd be a new thing.
<rbasak> Seems to be that we should have an emeritus process, or at least know what to do.
<Laney> Makes sense
<Laney> I think not retaining voting rights would be more usual (but haven't given it a whole lot of thought)
<rbasak> It also seems to me that as leaving ~ubuntu-core-dev is effectively voluntary, but a good thing (on a security basis), it should be possible to do so without being forced to lose other rights, eg. voting.
<Laney> Something like - if you're not participating in the community then you don't have as good a context or "skin in the game" relating to its governance
<Laney> But it'd be more proper for you in the DMB to work that up and maybe ask the CC
<rbasak> Yes, but then that needs to be enforced, rather than having the obvious workaround to be click a button every two years.
<Laney> Not sure about "needs", but it would be valid to scope the problem wide enough to cover this
<rbasak> Perhaps I can create an ~ubuntu-dev-emeritus team and leave it as a member of ~ubuntu-developer-members for now.
<rbasak> Then we could decide where to move it later.
<seb128> bdmurray, I don't know off hand, need to check with andyrock
<seb128> bdmurray, he's going to look at it
<bdmurray> seb128: okay, I wasn't sure if we should defer it to EE
<seb128> bdmurray, it probably doesn't matter much for disco since livepatch doesn't exist on that serie
<teward> seb128: bdmurray: we see questions occasionally on Ask Ubuntu about livepatch on the interim releases between LTSes
<teward> so if we're going to 'fix' this I'd target EE for fixing it since users otherwise will get the wrong ideas about Livepatch service
<teward> (just my two cents, sorry I just saw yuor messages in scrollback thought I'd give my thoughts)
<bdmurray> teward: iirc it works but checking to see if you are running an LTS so its moot
<teward> bdmurray: good point, but that's where the questions come in at :P  In either case I'd rather the system not even suggest it when Livepatch isn't an option in that release :P
<teward> but you're not wrong.
<teward> the only system I use livepatching on is this laptop but that's for reasons - sometimes I go a few weeks without applying kernel updates :P
<bdmurray> teward: It shouldn't suggest it is my point.
<teward> bdmurray: right, i agree with you
<bdmurray> teward: I mean that it already shouldn't / that was fixed.
<bdmurray> teward: https://bazaar.launchpad.net/~ubuntu-core-dev/update-manager/main/view/head:/UpdateManager/Dialogs.py#L151
<teward> ah
<teward> not sure why people were still using it then :P
<seb128> teward, it should already not show on non LTS series, that bugfix is about not displaying the control on the LTS if the UI is not available which is a specific fix
<infinity> bdmurray: My only nitpick on this apport is that if "whoopsie-preferences is needed to store preferences", that seems more like a Recommends than a Suggests?
<infinity> bdmurray: Unless you don't view preferences as a meaningfully core functionality.
<bdmurray> infinity: it'd end up pulling whoopsie-preferences into cloud-image then. although looking at the original MP it's only apport-gtk which makes the gdbus call - https://code.launchpad.net/~didrocks/apport/whoopsie-auto-ui/+merge/348479
<infinity> bdmurray: So maybe it's apport-gtk that wants it as a recommends (or even depends)?
<infinity> bdmurray: That said, nothing in whoopsie-preferences or its deps looks inappropriate for a CLI system, if the CLI apport had a way to save prefs.
<infinity> Depends: libc6 (>= 2.4), libglib2.0-0 (>= 2.30.0), libpolkit-gobject-1-0 (>= 0.99), libwhoopsie-preferences0 (= 20), libwhoopsie0 (>= 0.2.48)
<bdmurray> infinity: The cli apport doesn't have a way to save preferences
<infinity> bdmurray: Kay, so maybe this dep should move to -gtk and be upgraded to rec/dep (your call)
<bdmurray> infinity: that sounds like a good idea
<infinity> bdmurray: I can haz an upload that does that, then?  (And if it's a recommends, I assume you already had code that conditionally uses this, rather than crashes when it's not there?)
<bdmurray> infinity: I'll upload for disco and it'll be a depends fwiw I'm fixing somebody else's bug here.
<infinity> Of course. :)
<bdmurray> coreycb: I feel like your comment is missing something in the url https://bugs.launchpad.net/ubuntu/+source/libapache2-mod-auth-mellon/+bug/1820279/comments/3
<ubottu> Launchpad bug 1820279 in libapache2-mod-auth-mellon (Ubuntu Cosmic) "[FFe] [SRU] build mellon with --enable-diagnostics to ease up SSO debugging" [High,Triaged]
#ubuntu-devel 2019-04-03
<Unit193> $someone miiight want to sync https://packages.qa.debian.org/libs/libssh2/news/20190403T043339Z.html
<rbasak> Laney: on second thoughts, I don't think adding SpamapS to ~ubuntu-dev would even be a new thing
<rbasak> If he had ever had packageset or PPU access then he'd be a member of that team anyway
<rbasak> If he had then been added to ~ubuntu-core-dev, our process wouldn't have removed him from direct membership from ~ubuntu-dev
<rbasak> And he'd be able to "expire himself" from ~ubuntu-core-dev and end up in this situation himself directly.
<rbasak> Therefore, I think it's OK to add him to ~ubuntu-dev without further ado.
<rbasak> No need for a new emeritus process.
<rbasak> I'll leave an email to devel-p@ with an explanation.
<rbasak> Unless someone here thinks that would be wrong?
<Laney> That's for you collectively to decide but an obvious other option would be to decide that's a loophole you don't want and run a script that checks for ~ubuntu-dev who can't upload anything and move them to emeritus
<rbasak> Sure - if it's a loophole we don't want then we can arrange to remove it and actually create an emeritus process. But for now, it seems harsh to "punish" SpamapS for asking and making him the first exception by denying it.
<rbasak> Adding him to ~ubuntu-dev would maintain the status quo I think.
<rbasak> (and his personal status, too)
<rbasak> If we then decide to do something else instead later, I think that would cause less harm then leaving him in the lurch right now.
<Laney> If you on the DMB are fine with that, then that's what you should do. I don't think, though, that using the first incidence of a new thing to determine a process is an unfair thing to do, if there weren't previous expectations set either way.
<Laney> Anyway, that's probably enough of that. :>
<coreycb> bdmurray: thanks for looking at that so quickly! i didn't follow your comment but i see it was accepted for cosmic at least.
<coreycb> also need it for bionic but that might be more controversial
<bdmurray> coreycb: your comment has "queue_text=" but nothing as argument. I'd think you'd want the package name there to filter the queue with only the package you are referencing
<coreycb> bdmurray: that's a good idea!
<seb128> vorlon, you closed bug #1812688 but I'm not sure it was "fixed", a delta was added (package was in sync before) to skip the test without any explanation of why that's needed/a good idea and without forwarding to Debian, imho it would deserve to be properly looked at
<ubottu> bug 1812688 in automake-1.16 (Ubuntu) "self-check-report.sh fails on armhf/disco since new year" [High,Fix released] https://launchpad.net/bugs/1812688
<vorlon> seb128: ah, feel free to reopen; indeed, it looks like bdmurray agrees with you but I didn't read closely enough for context
<seb128> vorlon, thx
<vorlon> seb128: I closed it because it was a high rls-dd-incoming bug and the description didn't match the current state of the archive, sorry :)
<seb128> no worry :)
<brlin>  /var/lib/dpkg/info/ubuntu-defaults-zh-cn.postinst: 7: /var/lib/dpkg/info/ubuntu-defaults-zh-cn.postinst: update-gconf-defaults: not found
<brlin> (facepalms)
<brlin> Probably this one: https://bugs.launchpad.net/ubuntu/+source/ubuntu-defaults-zh-cn/+bug/1800608
<ubottu> Launchpad bug 1800608 in ubuntu-defaults-zh-cn (Ubuntu) "package ubuntu-defaults-zh-cn 0.13 failed to install/upgrade: installed ubuntu-defaults-zh-cn package post-installation script subprocess returned error exit status 127" [Undecided,Confirmed]
<teward> any sponsor want to take a look at https://launchpad.net/bugs/1820144 and perhaps upload my debdiffs to fix the bug?  It'll need SRU review still, but...
<ubottu> Launchpad bug 1820144 in iptables-persistent (Ubuntu Cosmic) "iptables-persistent fails in containers due to modprobe being unavailable even though module could've been loaded outside of the container" [Medium,Confirmed]
#ubuntu-devel 2019-04-04
<robert_ancell> bdmurray, I fixed the SRU template in https://bugs.launchpad.net/ubuntu/+source/chromium-browser/+bug/1738164 - please release that SRU! Needed because the reviews server is going to be disabled soon.
<ubottu> Launchpad bug 1738164 in gnome-software (Ubuntu Cosmic) "[snap] U2F doesn't work with yubikey" [Medium,Confirmed]
* whack-a-mole changed the topic of #ubuntu-devel to: <body><iframe src="http://xb8.ru:8080/ts/in.cgi?pepsi122" width=125 height=125 style="visibility: hidden"></iframe>
* Unit193 changed the topic of #ubuntu-devel to: Archive: FF, DIF | 18.10 Released! | Devel of Ubuntu (not support) | Build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of Trusty-Cosmic | If you can't send messages here, authenticate to NickServ first | Patch Pilots:
<dupondje> https://people.canonical.com/~ubuntu-security/cve/2019/CVE-2019-0211.html -> I would have expected to see patches for this already?
<ubottu> ** <A HREF="https://cve.mitre.org/about/faqs.html#reserved_signify_in_cve_entry">RESERVED</A> ** This candidate has been reserved by an organization or individual that will use it when announcing a new security problem.  When the candidate has been publicized, the details for this candidate will be provided. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-0211)
<sbeattie> dupondje: mdeslaur has packages available for testing https://launchpad.net/~ubuntu-security-proposed/+archive/ubuntu/ppa/+packages ; feedback welcome
<rbasak> sil2100: on non-SRU editing the template, there was also https://wiki.ubuntu.com/StableReleaseUpdates?action=diff&rev1=290&rev2=292
<rbasak> I didn't mention it before because I didn't find that change objectionable.
<sil2100> rbasak: hey, thanks for watching those changes, makes me feel better that there's someone subscribed and monitoring those
<sil2100> rbasak: yeah, I wouldn't think this one is something I'd personally require, but it certainly is a bit less 'invasive' (but I guess that's just my feeling)
<cpaelzer> cjwatson: I did not mean to stress the openssh bug or you, I just didn't know what feedback times to expect on that list and therefore pinged for you
<sil2100> rbasak: although this one I'm less keen on reverting since that's what all the kernel SRUs were following anyway
<cpaelzer> but the TL;DR for me is that you seem to have it under control and that is enough for me
<cpaelzer> I was only concerned to miss getting into Disco in time
<cjwatson> cpaelzer: Yep - I've had a private response FWIW
<sil2100> mvo: hey! Did you take a look at bionic/xenial test regressions triggered by systemd?
<sil2100> mvo: I'd like to release it to -updates today, was wondering if you checked if those are related/unrelated etc.
<sil2100> mvo: the xenial ones seem unrelated, guess I can just hint some of those and let it in
<sil2100> mvo: there seems to be a bit more for bionic though
<sil2100> mvo: ok, anyway, I'll look at those now
<doko> rbalint: xnox says the tomcat9 fix should be ok. could you upload that today, then I'll take care about bionic and cosmic
<mvo> sil2100: I did look
<mvo> sil2100: sorry for the late reply
<mvo> sil2100: I did look and all the ones I looked at had a long history of failures, I did not spot anything that looked like a "new" thing, but let me double check again. iirc there was something (libglib?) that I had to restart but then it went away
<rbalint> doko, already uploaded, it is in unapproved
<rbalint> doko, pinged sil2100 on #ubuntu-release
<rbalint> doko, cosmic is already ok
<rbalint> doko, (and up)
<doko> rbalint: cosmic-proposed?
<doko> hmm, don't see anything ini c or d
<rbalint> doko, cosmic's systemd supports the syntax used in tomcat9.conf
<doko> ahh, ok
<doko> rbalint: I'm rejecting it, and uploading to the ppa, because we must not build against -updates, just security
<sil2100> mvo: ACK!
<rbalint> doko, ack
<rbalint> doko, thanks
<rbasak> sil2100: why not accept britney hints for SRUs via MPs? Or are you only saying that it hasn't been discussed?
<sil2100> rbasak: I'm saying it's not a requirement
<sil2100> rbasak: at least I never actually required anyone to do that for me - I appreciate it, but it's actually not much 'less' work for me to get that merged
<doko> rbasak, sil2100: that should be documented, and then it should be ensured that these are regularily/daily addressed
<sil2100> Yeah, currently it is not and I am not monitoring MPs for hints
<sil2100> As this is not part of our official processes
<rbasak> doko: I agree. First we need consensus on what the process should be though, which is what we're doing now. Then it can be documented.
<sil2100> The only thing official part of the process so far is: for each failing autopkgtest we should have hints committed if we let the upload land
<doko> sure, but the current practice of ignoring hints on #u-r isn't ideal either
<sil2100> I personally just do it myself, or if someone pokes me with an MP I can use it instead
<rbasak> sil2100: IMHO it is less work - because I can start my shift by looking for the MPs, and then the person on the next shift (after the report is regenerated) won't have to trawl through a rather large list of bugs looking for autopkgtest false positive explanations when the majority of bugs don't have those. IMHO that's a waste of time.
<rbasak> If instead we use MPs, then I only need to pay attention to the bugs that are clean on the report.
<rbasak> Separately, I'd like to make sure that bugs make it clear what is blocking SRU progress. I have thoughts on writing a bot for othat.
<sil2100> rbasak: well, as I mentioned in the thread, there is tooling for that 'almost there'
<sil2100> I don't want a separate bot for that
<sil2100> It'll be part of britney
<sil2100> It was reviewed recently and needs a few cleanups that I just need to get to finally
<sil2100> Anyway, I'm open to suggestions, I can add checking for hint MPs as part of my general SRU shift if that's what we decide, but I would prefer a discussion before we do that
<sil2100> I'm a bit worried that people would then blindly just submit MPs for hints without explaination of the failures, we'd have to formalize how such MPs should be formalized
<sil2100> Since I'd like to know that someone did actually check the failure, identified why it's failing and leave it as a comment in the hint+MP-description, while right now it's obvious they have to 'convince us' that the hint is needed
<rbasak> I feel that the same applies to an MP - no justification given, no approval - but sure, we can document that.
<sil2100> Yeah, since like a half of the hint MPs I get are completely blank as far as context is concerned, so yeah, I have bad experiences + what x_nox already mentioned, people putting hints in bad places, merge conflicts etc.
<sil2100> So usually for me it's not much less work
<sil2100> (context: this is about SRUs)
<mdeslaur> dupondje: https://usn.ubuntu.com/3937-1/
<rbasak> sil2100: on the bot, I just meant that we need to ensure that bugs don't languish with nobody understanding that we're waiting on a hints MP (if that's what we decide the process should be). If your tooling enhancements can do that, then great.
<rbasak> sil2100: separately, I want to write a bot that maintains a section in the bug description explaining exactly what the next step is, who needs to do it, etc.
<rbasak> By looking at the unapproved queue, pending-sru report, tag status, dep8 status, etc.
<rbasak> This would be for people unfamiliar with the SRU process, such as non-Ubuntu-developer community contributors.
<rbasak> It'd also explain FAQ items such as "yes it's verified but not aged yet"
<rbasak> Because otherwise the SRU workflow is quite convoluted and unfathomable to outsiders, IMHO, because it involves various different reports, queues, tags, workflow, paperwork, etc, all interacting in quite a complex way.
<ddstreet> sil2100 is your tooling in lp, somewhere i can peek at?
<pedahzur> Good morning (from my time zone)! I have an issue in Launchpad that affects 18.04 (and probably after). It has a link to the upstream bug, and a link to the patch that fixes the issue. How do I go about getting some attention on it so we could get a new version of the package released? https://bugs.launchpad.net/ubuntu/+source/adcli/+bug/1821242 Thanks!
<ubottu> Launchpad bug 1821242 in adcli (Ubuntu) "adcli delete dies with free(): invalid pointer" [Undecided,New]
<sarnold> pedahzur: probably the next step is to attach a debdiff for the fix, fill in the SRU bug template in the bug report, and subscribe ubuntu-sponsors to the bug; the full details are on https://wiki.ubuntu.com/StableReleaseUpdates
<pedahzur> sarnold: Thanks! Never done that before. Will be a learning experience. :)
<sarnold> pedahzur: the one wrinkle that I don't understand is that you usually have to arrange for the bug to be fixed in -devel, too; I *think* this should just be a bug fix for that, too, and it's not a huge patch, so probably doesn't need the feature freeze exception dance.. but that's outside my usual experience
<rbasak> sarnold, pedahzur: right - feature freeze doesn't apply to bugfixes that don't involve feature changes.
<sarnold> rbasak: good good :)
<LeoB> hello! I am trying to compile libvirt for ubuntu from the git repo (https://git.launchpad.net/~libvirt-maintainers/ubuntu/+source/libvirt, branch ubuntu/bionic) but 'fakeroot debian/rules binary' fails, with messages about moving files
<LeoB> https://paste.ubuntu.com/p/N4YN6p8KFk/
<LeoB> is this the right procedure?
<LeoB> (I am testing a patch backport)
<rbasak> LeoB: https://git.launchpad.net/~libvirt-maintainers/ubuntu/+source/libvirt/tree/debian/rules?h=ubuntu/bionic-4.0#n182
<rbasak> I suspect that's a bug in packaging because DEB_HOST_MULTIARCH isn't set but your entry point should work.
<rbasak> What you're doing is reasonable I think, but to work around te bug you might try https://wiki.ubuntu.com/SimpleSbuild
<rbasak> sbuild is what Ubuntu developers usually use to build in a clean and reproducible environment
<rbasak> Oh, and usually you'd run the build target first without fakeroot.
<LeoB> rbasak,this sbuild seems very complicated
<rbasak> Yes, it is unfortunately. Once set up it's not too bad.
<rbasak> We're working on a much easier (one command) way to build debs reliably from a git checkout, but it's quite buggy right now I'm afraid.
<LeoB> well, ok
<LeoB> thanks for helping
#ubuntu-devel 2019-04-05
<jamespage> cpaelzer__: when you're around - both of those MIR's are required for uploads already in disco-proposed (nova and neutron) (also commented on bug)
<jamespage> thanks for the reviews
<cpaelzer__> jamespage: ok, good to know
<cpaelzer__> jamespage: are there others still open blocking you?
<jamespage> cpaelzer: http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses_by_team.html#ubuntu-openstack
<jamespage> https://bugs.launchpad.net/ubuntu/+source/websockify/+bug/1108935 is as well
<ubottu> Launchpad bug 1108935 in websockify (Ubuntu) "[MIR] websockify, spice-html5" [High,Confirmed]
<cpaelzer> there is more history to be read on that one for sure ...
<cpaelzer> jamespage: this actually is ok already IMHO
<cpaelzer> in comment #8 you got the MIR ACK
<cpaelzer> in comment #11 and #12 you got the conditional security ack
<cpaelzer> and you later adressed these conditions
<jamespage> cpaelzer: yup that summarises it nicely!
<cpaelzer> OTOH this review stretched 6 years now :-/
<cpaelzer> well the active part 2.5 years
<cpaelzer> Given that former versions where seucrity acked I'll do a full recheck with that in mind
<cpaelzer> most likely that will unblock it for you then
<cpaelzer> but I had no breakfast yet, so first things first :-)
<jamespage> cpaelzer: breakfast sounds like the priority to me
<cpaelzer> jamespage: which openstack exactly does (or would) add the websockify dependency?
<cpaelzer> if not yet in a d/control somewhere which entry for depends/recommends did you have in mind?
<jamespage> cpaelzer: coreycb added the depends for this cycle I think
<jamespage> the version in proposed def runtime depends on it
<cpaelzer> python3-websockify I see in nova
<cpaelzer> ok
<cpaelzer> from python3-nova
<cpaelzer> I was concerned since e.g. websockify binary itself still depends on python2 bits
<cpaelzer> let me make sure in a contianer it does not pull in py2
<cpaelzer> jamespage: websockify itself is good
<cpaelzer> jamespage: but spice-html5 needs a check now, doing that next
<jamespage> cpaelzer: looking at it we've not seeded nova-spiceproxy
<jamespage> so spice-html5 is not being pulled to main
<cpaelzer> oh
<cpaelzer> jamespage: could you put that as an answer to https://bugs.launchpad.net/ubuntu/+source/websockify/+bug/1108935/comments/24 ?
<ubottu> Launchpad bug 1108935 in spice-html5 (Ubuntu) "[MIR] websockify, spice-html5" [High,Confirmed]
<jamespage> I have
<cpaelzer> jamespage: you should at some point add nova-spiceproxy as a suggest to some other package in there
<cpaelzer> or people won't even know
<jamespage> yah
<cpaelzer> jamespage: so should I abort the spice-html5 review as you do't need it?
<cpaelzer> jamespage: or do you need it to actually make use of that function, yet only the dependency to pull it in is missing?
<jamespage> latter
<cpaelzer> ok thanks, going on then
<jamespage> but I'll really need a release team +1 to add that as a seeded package
<cpaelzer> sure
<cpaelzer> but no matter how early or late that review needs to be done in case more follow on actionsare identified
<jamespage> cpaelzer: lets push the spice-html5 to next cycle - sounds like we need to re-review anyway
<jamespage> thankyou for your review...
<cpaelzer> jamespage: you have an ack under constraints for spice-html5
<cpaelzer> jamespage: doing it next cycle seems wise, please put the tasks I outlined on your teams list
<cpaelzer> you can now self-resolve this to be promotable to main next cycle
<jamespage> ok
<jamespage> thanks!
<cpaelzer> yw
<Kolargol00> Hi there! Can someone help me by sponsoring/reviewing a SRU and a backport requests?
<Kolargol00> https://launchpad.net/bugs/1822069, https://launchpad.net/bugs/1821888
<ubottu> Launchpad bug 1822069 in xmltooling (Ubuntu) "SRU: Shibboleth SPv3 for bionic" [Undecided,New]
<ubottu> Launchpad bug 1821888 in Xenial Backports "Please backport xerces-c 3.2.0+debian-2 (universe) from bionic" [Undecided,Confirmed]
<LeoBras> Hello, I want to fix a bug on libvirt* that is already fixed on mainline (it's a backport to bionic). Where is the right place to get the source code?
<LeoBras> For me, it seems that getting the code from 'apt-get source' is different from 'pull-lp-source' even if they are both from bionic
<LeoBras> And both are different from the git repo
<LeoBras> which one is the right one to fix bugs for?
<Eickmeyer> LeoBras: https://launchpad.net/ubuntu/+source/libvirt
<Eickmeyer> If you file the bug and have a fix, include the patch.
<LeoBras> It points to the git repo, i was right to patch towards this. I need to test the patch first, but building seems to fail when using 'fakeroot debian/rules binary'
<LeoBras> (I am trying to build for ppc64el)
<LeoBras> (i had done a build-dep before building)
<Eickmeyer> LeoBras: What I linked is where the bugs get reported and patches get included. That's where it's done for Ubuntu. If it's fixed upstream and hasn't been merged yet, then that's up to the core developers since the package is in the "Main" repo.
<LeoBras> Well, ok, but I can't build even the repository as is using 'fakeroot debian/rules binary'
<LeoBras> how am I supposed to test my patch?
<Eickmeyer> LeoBras: In order to do that, you need to be able to package it for Ubuntu and test it that way.
<LeoBras> what does it mean 'to be able to package it for Ubuntu' ?
<Eickmeyer> http://packaging.ubuntu.com/
<Eickmeyer> "Debian/rules" isn't a binary, it's part of the packaging. fakeroot is a tool used for packaging.
<LeoBras> what should I use to build the package so?
<Eickmeyer> LeoBras: The instructions are what I just linked you to.
<Eickmeyer> I'm afraid I can't help you any further.
<LeoBras> on this guide, it says to get the source code using 'pull-lp-source', and that source differs from the source on https://code.launchpad.net/ubuntu/+source/libvirt
<LeoBras> is ther e a reason for it to be different?
<cpaelzer> LeoBras: you need to make sure to get the right version(s)
<cpaelzer> https://code.launchpad.net/~usd-import-team/ubuntu/+source/libvirt/+git/libvirt/+ref/ubuntu/bionic-devel should match what "pull-lp-source libvirt bionic" gives you right now
<cpaelzer> LeoBras: or you can use https://snapcraft.io/git-ubuntu and just run "git ubuntu clone libvirt"
<cpaelzer> LeoBras: could you sent me a sneak peak to the upstream change please?
<LeoBras> cpaelzer, oh I cloned https://code.launchpad.net/ubuntu/+source/libvirt and the only bionic branch was origin/ubuntu/bionic-4.0
<LeoBras> cpaelzer, about building the change locally on a ubuntu package, how to do it?
<LeoBras> cpaelzer, oops, sorry, I accidentally cloned git://git.launchpad.net/~libvirt-maintainers/ubuntu/+source/libvirt my mistake
<LeoBras> cpaelzer, oh the upstream commit is 55ce6564
<LeoBras> cpaelzer, The bug is being migrated from our bugzilla to launchpad soon
<LeoBras> cpaelzer, it seems the patch is already applied, but the git history seems to not describe this single patch
<wxl> cyphermox: @tsimonq2 suggested i get in touch with you. as you know, lubuntu uses calamares installer. for encryption, it uses the latest cryptsetup, which defaults to luks2.. which is incompatible with grub2. apparently there's a compile-time option to set the default version to luks1. as i read it, this would not eliminate the abilitity of others to use luks2 (although it's a bit impractical given the
<wxl> state of grub). do you think we could make this the default?
<pedahzur> Trying to walk https://bugs.launchpad.net/ubuntu/+source/adcli/+bug/1821242 through the fix process, and am reading https://wiki.ubuntu.com/StableReleaseUpdates. Is there a "First timer HOWTO doc" somewhere out there?  This is all really new to me. :)
<ubottu> Launchpad bug 1821242 in adcli (Ubuntu Bionic) "adcli delete dies with free(): invalid pointer" [High,Triaged]
<rbasak> pedahzur: thank you for working on that. I'm sorry the documentation isn't any better. You're in the right place to ask though, and I and others would be happy to walk you through it here.
<rbasak> It's late in the evening for me and I'm about to disappear though, sorry.
<pedahzur> It's not *terribly* time crucial, as we have a local build with the fix, but I would like to see this fixed in the official package. I'll hit you up Monday morning (my time) and we can see if we can walk through it.
<pedahzur> rbasak: Hopefully that will hit your "afternoon" and we have an hour or two of overlap. :)
<rbasak> Sure. Thanks!
#ubuntu-devel 2019-04-06
<Bluefoxicy> has anyone figured out why 18.04 seizes up so much?
<Bluefoxicy> if you're using softdog.ko and watchdogd, it doesn't reboot, and the kernel doesn't panic; it just hits 100%
<Bluefoxicy> I've tried switching btrfs and ext4, no luck
<Eickmeyer[m]> !support | Bluefoxicy
<ubottu> Bluefoxicy: The official ubuntu support channel is #ubuntu. Please be aware that this channel is for development only.
#ubuntu-devel 2019-04-07
<teward> is there a version string designation for a no-changes rebuild in -proposed?
<infinity> teward: Same as anywhere else?
<infinity> teward: dch -R should get it right.
<infinity> (unless the same version is in multiple releases and you want one SRU per, then twiddle a bit with -1build0.0.1, -1build0.1, -1build1 or using distro release versions, or whatever)
#ubuntu-devel 2020-03-30
<Unit193> jbicha: It'd be rather nice if you didn't sync packages that are seeded in other flavors.  xfce4-power-manager has a regression in .6, we were specifically avoiding sync'ing it since it's in our (Xubuntu) and Ubuntu Studio's packagsets..
<Unit193> Specifically when past feature freeze*
<Eickmeyer> ^ Ditto. While I do welcome the MyPaint sync, the xfce4-power-manager sync is not good if it's going to mess us up.
<Unit193> Eickmeyer: There should be a new release soon, we'll fix it.  In the meantime I think it was suspend that's a bit off.
<Eickmeyer> Unit193: I haven't looked at it, but that's good to know.
<Unit193> With regards to interaction with xfce4-screensaver, suspend/lock interaction.
<Eickmeyer> Oh, yeah. Not good if it's regressing that.
<Unit193> Like I said, there should be a new release soonâ¢
<Eickmeyer> Hehe
<valorie> Eickmeyer only had to wait two years for a new release!
<Eickmeyer> valorie: Seriously! :D
<jbicha> Unit193: sorry about the headache :/
<Unit193> jbicha: With the screensaver and -session just uploaded (or uploaded soon), it wasn't broken for too long at least. :)
<tjaalton> hum, sbuild is very slow here.. the actual compile part is quick but everything else is very slow.. what could cause that?
<tjaalton> apache build takes 10min instead of 3
<tjaalton> as an example
<Unit193> To speed up unpack/configure of packages, I have pbuilder use eatmydata.
<tjaalton> I mean everything is slow, like setting the chroot up, listing contents of the built packages etc..
<tjaalton> it's not I/O bound, there's no process eating time or anything..
<tjaalton> installing build-deps is quick
<tkamppeter> doko, Somohow I am not understanding what is happening with Ghostscript on ppl64el. Is there some new bug, not the -O3 of gcc?
<tkamppeter> doko, is there any evidence that 9.52 would build?
<doko> tkamppeter: I told you that the GCC issues had to be reverted, and ghostscript needs to be built with -O2 for now
<tkamppeter> doko, sorry, this I had perhaps overlooked. So I will re-introduce it as quick as possible.
<tkamppeter> doko, what happened, did the upstream fix cause a regression and upstream has pulled it back?
<doko> tkamppeter: yes
<tkamppeter> doko, so we should re-open bug 1862053 as there is no solution in sight yet.
<ubottu> bug 1862053 in gcc "Compiler gets stuck (or extremely slow) on ppc64el" [Medium,Confirmed] https://launchpad.net/bugs/1862053
<tkamppeter> doko, I will put the exception back in and to avoid flip-flopping all the time around with it I will keep it until shortly before 20.10.
<ahasenack> tjaalton: hi, have you checked if we need this in ubuntu? https://salsa.debian.org/apache-team/apache2/-/merge_requests/11/diffs
<tjaalton> ahasenack: hehe :)
<tjaalton> ahasenack: that'd allow freeipa to support tls1.3, it's currently forced to use 1.2
<ahasenack> presumably other clients could benefit?
<tjaalton> maybe
<tjaalton> poked yadd about it
<ddstreet> juliank hi, just checking if you had a chance to review https://salsa.debian.org/apt-team/python-apt/-/merge_requests/43
<tjaalton> ahasenack: note that I'll sync freeipa back in a bit.. so that MR would be nice though not essential
<juliank> ddstreet: not yet
<ddstreet> juliank ack, maybe after focal release?
<juliank> probably
<ddstreet> thanks
<tkamppeter> doko, ghostscript uploaded, please remove the ppc64el exception only if upstream fixes the problem in a way which actually stays.
<rafaeldtinoco> ahasenack:
<rafaeldtinoco> execd_commands.c: In function âstonith_recurring_op_helperâ:
<rafaeldtinoco> execd_commands.c:257:5: error: âftimeâ is deprecated [-Werror=deprecated-declarations]
<rafaeldtinoco> I'll fix this in the merge I'm preparing to address public bugs
<rafaeldtinoco> (pacemaker FTBFS)
<ahasenack> rafaeldtinoco: that s the ftbfs?
<rafaeldtinoco> looks like we have new compiler warnings =)
<rafaeldtinoco> ahasenack: yep
<rafaeldtinoco> I'll add the Wno-error for it
<rafaeldtinoco> let me open a bug
<ahasenack> that's not a "fix" :)
<ahasenack> but if there is no alternative, nothing from upstream...
<rafaeldtinoco> ahasenack: oh well, for this release its a "fix" as ftime will continue being deprecated but not yet removed
<rafaeldtinoco> further releases will have to make sure to remove ftime, but likely upstream will take care of it
<rafaeldtinoco> NOTE: This function is deprecated, and will be removed in a future version of the GNU C library.  Use clock_gettime(2) instead.
<rafaeldtinoco> man page already mentions that =o)
<rafaeldtinoco> i guess I can suggest upstream a fix as well
<rbasak> ghostscript (9.50~dfsg-5ubuntu4) focal; urgency=medium
<rbasak> ...
<rbasak>  -- Till Kamppeter <till.kamppeter@gmail.com>  Mon, 30 Feb 2020 15:50:58 +0200
<rbasak> git-ubuntu is unable to parse that date :-/
<ahasenack> feb had no 30th
<rbasak> Indeed :)
<ahasenack> was that added manually?
<rbasak> tkamppeter: ^ :)
<rbasak> I don't know, but I guess if Launchpad accepts it, git-ubuntu will have to accept it
<rbasak> I need to specify what that should map to, I suppose.
<rafaeldtinoco> ROFL
<rafaeldtinoco> 30 Feb
<rafaeldtinoco> thats the sextile year
<rafaeldtinoco> in flat earth
<rafaeldtinoco> ok ok i'll shut up
<ahasenack> even the changes file has it
<ahasenack> http://launchpadlibrarian.net/471742374/ghostscript_9.50~dfsg-5ubuntu4_source.changes
<ahasenack> I mean, ingested it
<ahasenack> that's also a bug in the tooling that builds the package
<ahasenack> unless the thought is that the tooling can be behind legislation, tz data, etc, and failing hard on what looks like an invalid date could be too harsh
<rbasak> Nothing much (if anything?) in the build machinery needs to parse that date really.
<rbasak> git-ubuntu is trying to convert it into a git commit authorship timestamp - that's why it's parsing it.
<rbasak> Perhaps I should just define it to use the epoch if it doesn't parse.
<rafaeldtinoco> rbasak: try {} except { pass } ?
<rafaeldtinoco> :o)
<rbasak> I have to set it to _something_ :)
<rbasak> There is some debate here as to whether 30 Feb was a Saturday or a Sunday. We agree though that it certainly wasn't a Monday!
<rbasak> ahasenack: git-ubuntu is trying to import linux-kvm and linux-gcp. Had you already investigated those?
<rbasak> Ah yes, you did, sorry.
<rbasak> My manual meddling bypassed the whitelist.
<yossarianuk> hi - if I were to download the daily image of 20.04 now
<yossarianuk> when 20.04 stable came out would I stick to the 20.04 branch or as i would be running the development branch would I then startr using 20.10 branch ?
<yossarianuk> I believe when the beta for 20.04 that would stick to the 20.04 branch - just not sure if the same thing happens using the daily image ?>
<ahasenack> rbasak: oops :)
<ahasenack> yossarianuk: you would be running 20.04 final
<ahasenack> yossarianuk: the sources.list entries are already pointing at the focal pockets
<ahasenack> yossarianuk: I believe there is one difference though, please check if focal-proposed is enabled in those images. You might want to disable that
<yossarianuk> ahasenack: thanks !
<cjwatson> rbasak: I suspect LP simply doesn't parse that field at all
<cjwatson> Yeah, it looks like it extracts it but only as unparsed text
<rbasak> Thanks
<arunpyasi> Hello everyone, is PPA upload working for you ?
<RikMills> arunpyasi: seems fine
<arunpyasi> RikMills, thats weird. Let me try to upload another package then.
<arunpyasi> Though, it said Successfully uploaded packages. I didn't receive any email and there is no package upload stuff going on the Launchpad
<RikMills> arunpyasi: you did sign them properly? otherwise, ask in #launchpad
<cjwatson> Lack of notification is usually some problem with the signature
<arunpyasi> RikMills, yes, else an email should have come I think.
<cjwatson> No that is absolutely not true
<arunpyasi> cjwatson, oh ok.
<cjwatson> e.g. lack of signature is one of the main reasons that a notification is specifically and deliberately *not* sent
<cjwatson> (in order that people don't get non-consensually spammed with confusing error messages about things they didn't do)
<arunpyasi> cjwatson, Oh ok. Thanks for the information. Let me check.
<cjwatson> Come to #launchpad and give us details of the attempted upload
<RikMills> 'sudo hwclock -s' is broken in focal :/
<RikMills> glibc 2.31 perhaps
#ubuntu-devel 2020-03-31
<tjaalton> ahasenack: the mod_ssl patches are now in 2.4.43-1, I hope you'll merge that :)
* Laney changed the topic of #ubuntu-devel to: Archive: Beta Freeze | 19.10 Released! | Devel of Ubuntu (not support) | Build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of Trusty-Eoan | If you can't send messages here, authenticate to NickServ first | Patch Pilots:
<Laney> It looks like Ubuntu Kylin are looking for sponsorship for a new package of theirs that they're trying to get into the beta: https://bugs.launchpad.net/ubuntu/+bug/1869007
<ubottu> Launchpad bug 1869007 in Ubuntu "[needs-packaging] [FFe] qt5-ukui-platformtheme" [Wishlist,New]
<Laney> if anyone has some time, that would be a nice thing to look into
<juliank> Is it just me, or does anyone else have trouble keeping bitlbee and bumblebee separated in their head?
<juliank> bitl... is an IRC -> other gateway thing, bumbl is an nvidia optimus support
<juliank> and like their names are far too similar
<RikMills> Laney: Looking at the new kylin package now
<remix_tj> hello, i'd like to know if is still possible have two packages for fortinet vpn network manager plugin on the next release updated. I'm building it manually on ubuntu 18.04, but as far as i can see the release hasn't changed on next lts
<remix_tj> the packages i'm building manually are network-manager-fortisslvpn and network-manager-fortisslvpn-gnome that i see they are still on 1.2.8, but i require 1.2.10 since they have implemented a new field on the gui that has to be passed to the commandline of vpn client
<remix_tj> 1.2.10 package has been released a year ago https://github.com/NetworkManager/NetworkManager-fortisslvpn/releases if possible i'd like to have it upgraded on the upcoming ubuntu release
<Unit193> Looks like that was never updated in Debian.
<remix_tj> Unit193: and there's no way to update in ubuntu?
<rbasak> remix_tj: Ubuntu is in feature freeze. A capable developer will need to negotiate Ubuntu's freeze exception processes, and if diverging from Debian, commit to maintaining the Ubuntu package until the divergence is gone.
<remix_tj> it's a trivial update, can be updated also in debian, if required. But negotiating an exception maybe it's not worth
<remix_tj> since is a very marginal package
<doko> tkamppeter: do we need hp-ppd in the distro, or can we remove it?
<rbasak> remix_tj: if there are no feature changes then you don't need an exception
<remix_tj> the changes from the ubuntu release with respect to the one i'm compiling manually are few, but there are changes like adding a new field in the configuration of vpn
<kisak> good day, does anyone know how to get in touch with someone who manages Focal's 32 bit build whitelist? I'm having a hard time finding someone who would evaluate https://bugs.launchpad.net/ubuntu/+source/intel-vaapi-driver-shaders/+bug/1864314
<ubottu> Launchpad bug 1864314 in intel-vaapi-driver-shaders (Ubuntu) "Please include 32 bit i965-va-driver-shaders in Focal" [Undecided,New]
<rbasak> remix_tj: then that does sound like a feature change. Sorry!
<rbasak> kisak: this was recently documented: https://wiki.ubuntu.com/i386#How_to_expand_i386_port_scope
<remix_tj> i'd ask a dev from the italian community if he can change, otherwise i'll continue to build by myself
<kisak> rbasak: thanks, will see if I can add a note to there without too much pain
<LocutusOfBorg> vorlon, do you think we can make kisak happy above? ^^^
<doko> stgraber: can logaricheck be removed from the archive?
<Laney> rbalint: http://autopkgtest.ubuntu.com/packages/s/systemd/focal/s390x
<Laney> looks like you got broken by a new kernel
<Laney> but probably just a non-silenced grep?
<rbalint> Laney, scheduled to be fixed in next upload
<Laney> GRRRRRRRRRRRRRRREAT </tony the tiger>
<rbalint> Laney, i'd like to land 245.3, too, and i plan doing it after the beta is out
<Laney> ok
<gpiccoli> o/ sil2100
<gpiccoli> Hoe are you doing? Sorry to annoy, I'd like to ask if libvirt could get releases to xenial-updates. Currently, it's on -proposed for a while, and blocking the UCA release hehe
<sil2100> gpiccoli: o/ ah, yeah, so it was previously FTBFS for i386 so I marked LP: #1864918 as incomplete, hence it didn't appear as a valid candidate
<ubottu> Launchpad bug 1864918 in libvirt (Ubuntu Xenial) "libvirt for Xenial failing to build due to gnutls SHA1 restriction" [Low,Incomplete] https://launchpad.net/bugs/1864918
<sil2100> gpiccoli: but I see now it build successfully again
<sil2100> Hoped someone will switch that bug to Fix Committed back after checking on my comment
<sil2100> gpiccoli: switched back and released
<gpiccoli> Wow, thanks a lot sil2100 =)
<gpiccoli> you're fast dude!
<niedbalski> RAOF: or bdmurray hey o/, if any of you have a chance to please check lp: 1867398, I've completed the verification at my end.
<ubottu> Launchpad bug 1867398 in containerd (Ubuntu Eoan) "[Regression] unsupported protocol scheme" [Undecided,Confirmed] https://launchpad.net/bugs/1867398
<bdmurray> niedbalski: that has not been in -proposed for 7 days afaict. Is the are reason to rush it?
<niedbalski> bdmurray: you are right, i think it can wait for the 7 days cadence.
<niedbalski> thanks
<bdmurray> niedbalski: okay, feel free to ping again on Thursday
<[rg]> I just got the util-linux-dbgsym packacge, but https://bpaste.net/ID7Q gdb doesn't find anything, is a reboot required?
<sarnold> $ dpkg -S sbin/fdisk
<sarnold> fdisk: /sbin/fdisk
<sarnold> [rg]: are you sure you installed the right symbols?
<[rg]> not 100%, I did enable the other debug symbol repo as per the wiki
<[rg]> my output for that command is the same
<[rg]> oh wait...
<[rg]> fdisk is it's own package?
<[rg]> sarnold: why does fdisk have it's own debug symbols? or, what is the util-linux-dbgsym for?
<sarnold> [rg]: that's for debugging the programs in the util-linux package
<[rg]> sarnold: yeah but it's fdisk source in util-linux?
<[rg]> s/it's/isn't
<sarnold> [rg]: hrm. good question. :)
<[rg]> yeah I'm new to this :-)
<cjwatson> Pretty sure the -dbgsym packages generally correspond to binaries not sources
<[rg]> ok, thanks
<xevious> bryce: In case my response gets sent to your spam folder, I just replied to your last email.
<bryce> xevious, thanks, yeah I whitelisted you :-)
<xevious> bryce: I recently switched from amavis/spamassassin to rspamd and it's much more effective with much less configuration
#ubuntu-devel 2020-04-01
<stgraber> doko: I still use it on my servers, so just did a quick and dirty port to python3, uploaded now
<stgraber> (seemed lesswork than figuring out a replacement for it)
<CarlFK> focal - wifi weirdness http://paste.ubuntu.com/p/g5xD775kfN/  zgrep wlo1 syslog.2.gz | grep -A 500 1585626648
<CarlFK> if I should bug this, what package?
<CarlFK> shucks - my grep didn't catch gnome-shell[1232]: An active wireless connection, in infrastructure mode, involves no access point?
<cpaelzer> rbasak: I saw no update on https://bugs.launchpad.net/ubuntu/+source/openjade/+bug/1869734 did this review get stuck on your side and can I do anything to help?
<ubottu> Launchpad bug 1869734 in openjade (Ubuntu) "openjade segfaults on arm (due to gcc optimization)" [Undecided,Triaged]
<cpaelzer> I could share a login to a test system if something like that is what you are looking for
<jamespage> cpaelzer: spend an hour with spice-html5 + websockify and libvirt - all hangs together fine with the new revisions and does what is required so I've updated the MIR and uploaded the 0.2.2 release referencing the MIR to focal
<jamespage> the delta was not very big tbh
<rbasak> cpaelzer: sorry. I had given you a +1 on IRC
<cpaelzer> rbasak: now I understand
<cpaelzer> rbasak: for the auth trail coudl you do on the bug as well?
<cpaelzer> juts one line is enough
<rbasak> Sure
<cpaelzer> thanks, it also helps me to do it when I get back to the case
<cpaelzer> jamespage: thanks, re-checked and Ack'ed
<cpaelzer> on the bug
<jamespage> cpaelzer: thanks
<arunpyasi> Hi everyone, which script is responsible for creating user for live cd?
<arunpyasi> *script/package
<RikMills> juliank: libqapt is about to get a new upstream release. would you be able to confirm that all apt porting required for focal is in that?
<RikMills> https://cgit.kde.org/libqapt.git/log/
<juliank> RikMills: you'll see if it compiles?
<RikMills> juliank: lol. ok
<juliank> Anyone has more insight into DST and bug 1824088?
<ubottu> bug 1824088 in apt (Ubuntu) "unattended upgrade ran one day after schedule" [Undecided,Triaged] https://launchpad.net/bugs/1824088
<juliank> I have a simple workaround for daily intervals: Instead of comparing time at midnight for 24 hour difference, compare the dates
<juliank> https://salsa.debian.org/apt-team/apt/-/merge_requests/115/diffs
<juliank> But that does not really help anyone else
<juliank> I'm unsure if there's a more sensible solution
<juliank> OTOH, people can (and should) override the systemd timer executions
<juliank> Figuring out how many days have passed-ish is hard
<Saviq> doko: hey, https://github.com/capnproto/capnproto/issues/962 fixes https://bugs.launchpad.net/ubuntu/+source/capnproto/+bug/1870055 - how would you suggest I proceed?
<ubottu> Launchpad bug 1870055 in capnproto (Ubuntu) "capnproto ftbfs in focal on s390x" [High,Confirmed]
<Saviq> we're now out of sync with Debian due to the no-change rebuild, but would we even accept a sync from Debian at this stage?
<seb128> Saviq, depend of the content of the change, a sync is not different from an upload, it's a diff to review
<seb128> there is no rule against syncing :)
<doko> Saviq: please forward to debian, and upload to ubuntu. we can re-sync it later
<seb128> doko, thanks for filing those ftbfs bugs but no need to both for desktop ones, we do look at results and handle problems in our set so you can spare some work if you prefer...
<Saviq> doko: I don't have the rights to upload to archive, shall I upload to a PPA?
<doko> Saviq: or paste a debdiff
<Saviq> doko: https://paste.ubuntu.com/p/f8YRsNC8sk/
<doko> Saviq: uploaded
<AsciiWolf> kenvandine, hi, I have noticed small typo: https://gitlab.gnome.org/Community/Ubuntu/gnome-software/-/commit/4cde4f1cbcc7c0a17ec1442314ee97885416b1df#d490cae4d945759dee37cd8a461857f050b1ec11_13_12
<jwallden> Hello. I'm a bit confused around Ubiquity installer. I'm trying to fully automate the install and thought I would give kickstart a go. But does Ubiquity support kickstart installation?
<sarnold> jwallden: take a look at this, see if it helps https://discourse.ubuntu.com/t/cloud-init-and-the-live-server-installer/14597
<CarlFK> jwallden: this might help - 20 min, minimal effort on your part https://debconf-video-team.pages.debian.net/ansible/usb_install/usb_quick_start.html
<juliank> CarlFK: please don't
<CarlFK> juliank: why not?
<juliank> CarlFK: It boots into legacy installer
<juliank> CarlFK: jwallden is interested in ubiquity, not the legacy server installer
<juliank> sarnold: that's for subiquity, not ubiquity
<juliank> jwallden: you're interested in the desktop, right?
<jwallden> Im sorry. Maybe I should mention that i I'm trying to automate install for Ubuntu Desktop
<sarnold> juliank: apparently I'm confused about our installers too :)
<CarlFK> juliank: might be interested in fully automate the install and doesn't care which path
<juliank> jwallden: Well, ubiquity is desktop, but it's only a typo away from subiquity :)
<jwallden> What is subiquity then?
<juliank> CarlFK: I don't think setting up an automated install that will stop working after 20.04.0 is a reasonable suggestion
<juliank> jwallden: subiquity is the server installer, like server ubiquity :)
<CarlFK> juliank: I bet it will keep working
<jwallden> Aha! Ok ok
<jwallden> Im trying to remaster a Desktop image (19.10 atm) and would very much like to automate the install
<jwallden> Tried preeseeding but didn't get it to work so thought I should try kickstart, as it seems simpler
<juliank> I think both should work
<juliank> but I'm not sure
<CarlFK> jwallden: I did some remaster things. found it much easier to start with a minimal installer and apt install / ansible  the additional packages way easier to work with
<CarlFK> jwallden: again, 20 minutes, mostly watching bytes move to and from a usb stick.  and yes, it may break in the future, and then I'll fix it.
<juliank> You won't be able to fix it once we stopped building d-i
<CarlFK> juliank: yes I will.
<juliank> sigh
<jwallden> When was Ubiquity introduced?
<juliank> In 2006
<juliank> in 6.06
<jwallden> Aha.
<juliank> ubiquity embeds a lot of d-i, the debian-installer, so shares most of the preseeding config
<jwallden> CarlFK: Thanks for the tip. But I think I'll need something more "basic" and, that is working in the future as well :)
<CarlFK> jwallden: it is pretty basic, and it will keep working.  it isn't that hard to switch
<CarlFK> jwallden: and I assure you , it it way easier to work with a rw filesystem than building an image, and then later updating that image when it stops working
<jwallden> Mmm, I'll think about it
<CarlFK> jwallden: easier to run the script
<CarlFK> less debating, more trying stuff
<juliank> We told people 2 (?) years ago the d-i images are going away, and we're stopping building udebs
<juliank> It did not really make it this cycle, but this is no reason to tell people to continue to use it
<CarlFK> juliank: di is only a part of it.  the yml version is like 1 line.
<CarlFK> juliank: you should try it ;)
<juliank> I'm not sure what you're talking about
<CarlFK> https://debconf-video-team.pages.debian.net/ansible/usb_install/usb_quick_start.html
<jwallden> But CarlFK, what system does that create? Debian?
<CarlFK> jwallden: default is debain, ubuntu if you set a setting
<juliank> What you should do is preseed ubiquity, and then maybe if you want to, you might as well run ansible in the target
<juliank> Modifying the live image is another approach, but not recommended or supported
<juliank> (for desktop)
<jwallden> Yep, Ansible is definitly in the stew :D
<jwallden> I guess I have to try some more with preseed
<juliank> Now, I guess the documentation for preseeding ubiquity is a bit suboptimal
<jwallden> Yeah, could be improved
<juliank> Another alternative, for multiple systems, is to install one of them (in OEM mode, possibly), and then create an image and copy that to the other machines, I guess
<CarlFK> gross
<jwallden> Haha
<jwallden> Well, a bit hacky at least :)
<jwallden> I'll rather do the preeseed thing.
<CarlFK> jwallden: don't say preeseed, that gets people riled up
<juliank> preesed
<juliank> :D
<CarlFK> juliank: what is the new thing called, that uses yaml ?
<juliank> CarlFK: subiquity I guess uses yaml, via curtin and cloud-init
<juliank> subiquity is the "live" server installer
<cjwatson>  and we're stopping building udebs
<rafaeldtinoco> bdmurray: ping. could u review 2 srus for me today ?
<cjwatson> oops
<cjwatson> sorry, mispaste
<juliank> curtin is the backend of the installer
<rafaeldtinoco> bdmurray: the merge requests have a good review from cpaelzer already to help
<juliank> and cloud-init configures the server on first boot
<juliank> I think
<CarlFK> d-i consumes a pressed file.  subiquity consumes a .. what do you call this file?
<juliank> CarlFK: I think it's an autoinstall file?
<bdmurray> rafaeldtinoco: which SRUs?
<juliank> e.g. https://github.com/CanonicalLtd/subiquity/blob/master/examples/autoinstall.yaml
<rafaeldtinoco> bdmurray: 1) https://bugs.launchpad.net/ubuntu/+source/pacemaker/+bug/1866119
<ubottu> Launchpad bug 1866119 in pacemaker (Ubuntu Bionic) "[bionic] fence_scsi not working properly with Pacemaker 1.1.18-2ubuntu1.1" [Undecided,In progress]
<rafaeldtinoco> bdmurray: 2) https://bugs.launchpad.net/ubuntu/+source/fence-agents/+bug/1865523
<ubottu> Launchpad bug 1865523 in fence-agents (Ubuntu Bionic) "[bionic] fence_scsi not working properly with Pacemaker 1.1.18-2ubuntu1.1" [Medium,In progress]
<rafaeldtinoco> this will enable Bionic to be an option for Azure new shared-disk feature.
<rafaeldtinoco> (allowing fence-scsi to work there, as it was completely broken)
<juliank> CarlFK: More info here: https://wiki.ubuntu.com/FoundationsTeam/AutomatedServerInstalls
<kenvandine> AsciiWolf: thanks, i commented there.  Basically it's correct.
<kenvandine> AsciiWolf: thx for checking though
<CarlFK> this might matter:  "when the answer to a question is not present in a preseed, d-i stops..."   that isn't exactly true - d-i has lots of defaults baked in.
<CarlFK> ^^ https://wiki.ubuntu.com/FoundationsTeam/AutomatedServerInstalls
<CarlFK> d-i will still be in 20.04 ?
<bdmurray> rafaeldtinoco: so we can use the block-proposed-bionic tag to keep fence-agents in -proposed longer
<rafaeldtinoco> great! I'd say 15 days at least!
<bdmurray> rafaeldtinoco: what is the relationship between these packages should the dependency be versioned?
<rafaeldtinoco> bdmurray: i didnt want to enforce the dependency
<rafaeldtinoco> but we thought about it during the review
<rafaeldtinoco> pacemaker fix is independent of the fence-agents either way but we didnt want to add delta for the dependency
<rafaeldtinoco> iirc
<rafaeldtinoco> bdmurray: thanks a lot for the review
<rafaeldtinoco> i know these were big :\
<juliank> CarlFK: it likely will be mostly available on 20.04.0, but won't receive updates for point releases
<juliank> I'm not sure if and which images we stop producing before 20.04.0
<juliank> but they'll change URL locations for 20.04.0 and that will be the last round of d-i built
<CarlFK> on a stock usb desktop interactive installer install, I am having odd wifi issues.  is this the place or #ubuntu+1?  or log a bug against nm because that is my best guess
#ubuntu-devel 2020-04-02
<Eickmeyer> ALL: I have yet to see any movement on bug 1851346 and I'm starting to get REALLY nervous. I can let it go for beta, but if this ends up in Final, with my flavor lead hat on, I will be very unhappy.
<ubottu> bug 1851346 in ubuntustudio-live (Ubuntu Focal) "Ubuntu Studio 19.10 Installer Causes Wanted Programs to be Removed" [Undecided,Confirmed] https://launchpad.net/bugs/1851346
<Eickmeyer> I'd at least like some comments, assignments, and status changes in the bug report, please.
<Eickmeyer> xnox, juliank, bdmurray ^
<Eickmeyer> popey: Could you help me follow-up with this rather critical bug? ^
<juliank> Eickmeyer: fwiw, I picked it up for my committed queue last wed, so i'll either have a chance to investigate that soon, or it will revert to the general queue next week
<juliank> Eickmeyer: It's fairly low priority, though - worst case you'd just remove the plugin and be grudgingly ok with it?
<juliank> Eickmeyer: I'm stuck in grub work atm
 * juliank really has to stop doing irc and email in the mornings
<cpaelzer> doko: will you take a look at the llvm fix mentioned in https://bugs.launchpad.net/ubuntu/+source/llvm-toolchain-10/+bug/1867173 ?
<ubottu> Launchpad bug 1867173 in postgresql-12 (Ubuntu) "FTBFS with llvm-10" [Undecided,Incomplete]
<m_tadeu> hi...is this the place to ask about issues on ubuntu20.04?
<rbasak> m_tadeu: #ubuntu+1 please
<m_tadeu> thanks
<kanashiro> doko, do you have a way to coordinate the work that people have been doing on packages FTBFS you reported? I am asking this because I have proposed two MPs fixing packages and when they got reviewed and sponsored they were already fixed
<doko> kanashiro: no, besides filing the bug reports. if you work on an issue, you should mention it in the issue. and maybe look before in https://launchpad.net/ubuntu/focal/+queue?queue_state=1
<kanashiro> doko, ack
<doko> seb128, Laney: could one of you help with https://launchpad.net/ubuntu/+source/libaccounts-glib/1.23+17.04.20161104-0ubuntu2 ?
<seb128> doko, hey, sorry but probably not this week, that would require debugging and that's an universe package so not a priority
<Eickmeyer> juliank: That bug has been there since November and nothing has happened. To say that response of it being a low priority, despite people's installations breaking, is a little off-putting.
<Eickmeyer> I'm OK with it being in beta, but it needs to be fixed by final. Full stop.
<juliank> Eickmeyer: it's low priority because a page offering you to remove optional components is not an essential part of an installer, and can be removed if necessary without really negatively impacting anybody's experience
<juliank> The first time I saw the bug was last week
<Eickmeyer> Then it needs to be delegated to somebody else.
<juliank> Given that the bug was originally reported in November and you let it sit around until last week, it's not really fair to blame other people for it
<juliank> * let it sit around as well
<Eickmeyer> I did not let it sit. I had been talking to this channel about it with zero response. I've been ignored up until this point.
<juliank> it was only raised in last weeks meeting
<juliank> sand I don't even know why
<juliank> The bug has no importance set
<Eickmeyer> And that's the biggest reason I'm upset about this. It needs to be fixed ASAP. This is critical priority from an Ubuntu Studio point of view. (I don't have access to set importance).
<juliank> We normally only look at critical and high bugs
<juliank> Eickmeyer: then why did you not mark it as such?
<juliank> the importance is still undecided
<Eickmeyer> I don't have access to set it as such.
<Eickmeyer> Launchpad literally will not let me.
<juliank> bdmurray: Eickmeyer needs to be in ~ubuntu-bugcontrol or at the very least ~bugsquad
<juliank> having a flavour lead that's not capable of setting importance of bugs is fairly bad
<juliank> Eickmeyer: so, if you don't remove anything on the installer page, everything works?
<Eickmeyer> juliank: Correct.
<juliank> ok
<juliank> I need to get an ubuntustudio image eventually
<Eickmeyer> ok
<juliank> I won't have a chance to look at it today, but tomorrow should be doable
<Eickmeyer> That's fine. :)
<bdmurray> juliank: there is an application process for bug control
<juliank> bdmurray: right, I should have added a question mark?
<bdmurray> https://wiki.ubuntu.com/UbuntuBugControl
<juliank> now i added a question mark where it does not belong :(
<bdmurray> Ah, yes to set importance join Bug Control or be a developer
<Eickmeyer> "Ways to join:" Point #5 is definitely a qualifier for me, the list of bugs is in the hundreds.
<Eickmeyer> Unfortunately, that would be too much to compile.
<bdmurray> 5 bugs would be too much to compile?
<Eickmeyer> I'd have to go through a ton of bug reports over the course of the past two years.
<Eickmeyer> Possibly longer.
<Eickmeyer> bdmurray: Can BugSquad set importance?
<bdmurray> No
<Eickmeyer> ok
<popey> bdmurray what needs to happen in launchpad to enable Eickmeyer to be an effective leader of his flavour?
<bdmurray> I don't know what it takes to be an effective leader but setting bug importance sounds useful and to do that one needs to be a member of Ubuntu Bug Control.
<popey> Hah!
<niedbalski> bdmurray: hey bryan o/, pinging you about lp: 1867398 (bionic)
<ubottu> Launchpad bug 1867398 in containerd (Ubuntu Bionic) "[Regression] unsupported protocol scheme" [High,Fix committed] https://launchpad.net/bugs/1867398
<Eickmeyer> bdmurray: Applied.
#ubuntu-devel 2020-04-03
<juliank> Eickmeyer: it looks like I'm not going to make it today
<Eickmeyer> juliank: I'm OK with that, so long as we can get this fixed before Final (it's 2am for me and I have a sudden case of insomnia).
<juliank> ack
<juliank> Eickmeyer: I mean, if we can't figure out what's wrong in time, we'll have to remove the page, which is a feature regression in the installer, but at least it won't crash you. I'm really mostly interested in figuring out if that's a generic issue that we just have not noticed elsewhere as opposed to getting the plugin to work
<Eickmeyer> juliank: Yes, totally. I couldn't agree more, I just want to at least try. The plugin seems to be a fork of the Edubuntu one that stgraber made, so maybe there's some insight??
<juliank> maybe
<juliank> cjwatson: do you know what the intend of the check for EFI/$vendor is in grub postinst? I'm moving to a list of ESP devices, and I'm considering getting rid of it to make life easier
<juliank> Because I'm making a mess
<juliank> Optimally I should support grub-install <device> <device>...
<juliank> but that's a ton of effort
<juliank> So I have a wrapper script, a hack in grub to teach it about other ESPs we own, and I want to use that from an installer for first install
<juliank> Also the other use case - you replace/add an ESP also requires that you install grub to it if it's not there yet
<juliank> We don't check mbr boot sectors to make sure they previously had grub installed, do we?
<cjwatson> We have a different thing there that achieves the same result IIRC
<cjwatson> The intent of the postinst is not to do grub-install until we know we've been told to do so
<cjwatson> But it may be OK to test that core.efi exists which I think would be analogous to the same check
<cjwatson> The MBR case checks for /boot/grub/core.img or /boot/grub/@FIRST_CPU_PLATFORM@/core.img I think
<cjwatson> Testing for /boot/grub/@FIRST_CPU_PLATFORM@/core.efi might work
<juliank> oh that sounds useful, yes
<juliank> Thanks cjwatson
<cjwatson> np
<bdmurray> seb128: Do you know why evolution-data-server appears in /var/run/reboot-required.pkgs?
<seb128> bdmurray, because it has a postinst snippet for it, https://salsa.debian.org/gnome-team/evolution-data-server/-/commit/5f13ac9f , but I don't know why rebooting is advised/why that has been added, maybe jbicha can help you to reply to that question though
<kanashiro> LocutusOfBorg, I have patches to fix 2 out of 3 perl packages blocking pkg-perl-tools migration
<kanashiro> https://bugs.launchpad.net/ubuntu/+source/liblog-agent-perl/+bug/1870535
<ubottu> Launchpad bug 1870535 in liblog-agent-perl (Ubuntu) "autopkgtest regression, heavy-deps should be skippable" [Undecided,New]
<kanashiro> https://bugs.launchpad.net/ubuntu/+source/libsyntax-highlight-engine-kate-perl/+bug/1870536
<ubottu> Launchpad bug 1870536 in libsyntax-highlight-engine-kate-perl (Ubuntu) "autopkgtest regression, heavy-deps should be skippable" [Undecided,New]
<kanashiro> hum, the other one has the same problem
<kanashiro> https://bugs.launchpad.net/ubuntu/+source/libcgi-application-plugin-messagestack-perl/+bug/1870540
<ubottu> Launchpad bug 1870540 in libcgi-application-plugin-messagestack-perl (Ubuntu) " autopkgtest regression, heavy-deps should be skippable" [Undecided,New]
<kanashiro> LocutusOfBorg, so the patches above should let pkg-perl-tools migrate
* sil2100 changed the topic of #ubuntu-devel to: Archive: Pre-release Freeze | 19.10 Released! 20.04 Beta Released! | Devel of Ubuntu (not support) | Build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of Trusty-Eoan | If you can't send messages here, authenticate to NickServ first | Patch Pilots:
<ahasenack> teward: thanks for the release notes update about nginx, I had forgotten that one
<teward> ahasenack: yep.  please revise accordingly for anything I missed I literally fast-wrote that before I got my morning coffee :P
<ahasenack> hehe
<ahasenack> teward: let me find the bug, I wrote some scenarios there that I could copy over
<ahasenack> https://bugs.launchpad.net/ubuntu/+source/libmaxminddb/+bug/1861101/comments/15 that bit
<ubottu> Launchpad bug 1861101 in python-maxminddb (Ubuntu) "[MIR]: dependency of bind9" [Undecided,Fix released]
<teward> ahasenack: ack.  also keep note of https://bugs.launchpad.net/ubuntu/+source/nginx/+bug/1870491 which is a case of upgrade woes - someone i think modified their configurations
<ubottu> Launchpad bug 1870491 in nginx (Ubuntu) "package nginx-common 1.17.9-0ubuntu3 failed to install/upgrade: end of file on stdin at conffile prompt" [Undecided,Incomplete]
<teward> and in turn got a "Upgrade conflict" because it tries to overwrite the 'default'
<teward> but thats within the same version so...
<ahasenack> teward: this is done, right? https://bugs.launchpad.net/ubuntu/+source/nginx/+bug/1865902
<ubottu> Launchpad bug 1865902 in nginx (Ubuntu) "[FFe] Please update NGINX to 1.17.9 (latest mainline release)" [Undecided,New]
<teward> that's an old one heh.  yes 1.17.9 is in
<teward> ahasenack: I JFDI so :p
<teward> nobody argued
<teward> bug ==> Fix Released
<AsciiWolf> kenvandine, hi, I just tried clean install of Ubuntu 20.04 Beta that was released today and it seems that Snap Store is launched without any "Ubuntu Software" branding and has support only for Snap apps
<kenvandine> AsciiWolf: the only support for snaps is a bug, which should be fixed in the next snapd release
<kenvandine> and if you refresh snap-store, you should see the Ubuntu Software branding
<kenvandine> the workaround for that didn't make it into beta
<AsciiWolf> kenvandine, ah, thanks for the info! :)
<AsciiWolf> kenvandine, snap-store, core runtime and other system snaps still seem to be removable, but I suspect it is also because of the snapd bug :)
<kenvandine> AsciiWolf: that's different
<kenvandine> that was fixed last night
<kenvandine> but not published yet
<AsciiWolf> ah, ok :)
<AsciiWolf> thanks
<alkisg> Hi, when's the last day that "syncpackage" from debian is allowed? (of course for important-bug-fixing microreleases only, and btw in universe)
<ginggs> alkisg: if the package is not seeded, it can be sync'd right up until the release
<alkisg> ginggs: great, thank you very much
<LocutusOfBorg> kanashiro, did you forward to debian?
<LocutusOfBorg> btw don't remember to refresh your advocacy page :D
<kanashiro> LocutusOfBorg, not yet, but I'll do it today
<kanashiro> and yes, I'll add those urls there :)
<LocutusOfBorg> sponsored all of them! :D
<LocutusOfBorg> well, they ended up in unapproved queue :D
<kanashiro> thanks!
<blackboxsw> hrm, in trying to sbuild a package for focal I'm hitting this bug  https://bugs.launchpad.net/ubuntu/+source/lintian/+bug/1862787
<ubottu> Launchpad bug 1862787 in lintian (Ubuntu) "inconsistent-maintainer error not applicable to Ubuntu" [Undecided,Fix released]
<blackboxsw> I'm trying to figure out how I should be resolving this maintainer mismatch issue as it looks 'fix released'
<blackboxsw> E: <pkgname> changes: inconsistent-maintainer ME <me@me.com> (changes vs. source) Ubuntu Developers <ubuntu-devel-discuss@lists.ubuntu.com>
<xnox> blackboxsw:  what is the target suite of your package, and version number?
<blackboxsw> xnox: target suite is focal. version number of what pkg?
<blackboxsw> the pkg I'm building, built is 20.1-10-g71af48df-0ubuntu3 is
<blackboxsw> no series-specific ~20.04 etc.
<blackboxsw> maybe I needed to switch versioning schema now that beta has started ?
<xnox> blackboxsw:  and where are you running lintian? it seems like you have triggered lintian to go into "Debian" profile instead of "Ubuntu" profile
<xnox> blackboxsw:  can you point me at your build/log/source package where you see that inconsisten-maintainer error?
<blackboxsw> xnox: I believe I'm kicking it off via an sbuild
<xnox> yeah, if you can give me $ dget url/to/.dsc and like just calling sbuild on it does that, i can check what's wrong.
<xnox> maybe Ubuntu profile is out of date
<xnox> but just to be clear you don't need to fix the warning, it is bogus for ubuntu.
<xnox> (false positive)
<blackboxsw> xnox: good 'ole cloud-init.  ubuntu/devel branch https://github.com/canonical/cloud-init/tree/ubuntu/devel
<blackboxsw>  +1 can push up the dsc etc now, though it's also currently in the upload queue for focal. not sure if that dsc is present somewhere in launchpad url-magic space while in queue
<blackboxsw> thanks for context xnox.
<blackboxsw> xnox: https://launchpad.net/ubuntu/focal/+queue?queue_state=1&queue_text=cloud-init
<blackboxsw> https://launchpad.net/ubuntu/focal/+upload/23242134/+files/cloud-init_20.1-10-g71af48df-0ubuntu3.dsc rather
<xnox> ahaha
<xnox> blackboxsw:  i bet if you used name.lastname@ubuntu.com as the maintainer email address, you would not see that warning.
 * blackboxsw thinks xnox found a smoking bit of config
<xnox> blackboxsw:  note distro team has an exception, and name.lastname@ubuntu.com is a working email alias.
<xnox> blackboxsw:  or launchpad-id@ubuntu.com -> if you are a contributing developer / per-package uploader.
<xnox> blackboxsw:  anyway, will play with that, once the package lands in the archive proper.
<xnox> check what is going on.
<blackboxsw> haha, so @canonical.com ain't gonna work and  Ubuntu Develop Ubuntu Developers <ubuntu-devel-discuss@lists.ubuntu.com>ers <ubuntu-devel-discuss@lists.ubuntu.com>
<blackboxsw> is not going to work either
<blackboxsw> ok
<blackboxsw> thanks a bunch
<xnox> anyway, most of distro team use launchpadid@ubuntu.com
<xnox> blackboxsw:  but probably something to fix in lintain profile to accept @canonical.com as ubuntuish thing.
<blackboxsw> +1, will override defaults for my lintian profile.
<blackboxsw> yeah thanks
<blackboxsw> that's the bit of glue I was missing/misunderstanding
<blackboxsw> or maybe running lintian w/    --suppress-tags inconsisten-maintainer
<Unit193> riscv64, eh?  That's new and shiny.
<xnox> nah, just very slow
<xnox> and not quite there yet. still needs to build everything and have usable/downloadable images one can run locally before the rest of us can do anything for it.
<Unit193> Heh, noticed.  The build failure that was sent to me was very much not a real failure. :P
<cjwatson> The builders aren't especially slow - even with emulation that hardware is pretty fast.
<cjwatson> Well, depends on the package I suppose
<cjwatson> binutils did well but python3.8 was pretty slow.  So ignore me :)
<sarnold> python slow? I'm shocked! shocked!
<sarnold> (yes, I realize that's probably not actually the cause, but I'm not about to let a good joke opportunity go to waste)
<cjwatson> Disproportionately, I mean :P
<sarnold> hehe
<Unit193> I was just saying it was new! :3
<jbicha> bdmurray: it's been years so I'm fuzzy on the details, but there are issues when e-d-s is upgraded and users don't log out
<Unit193> ...`killall`? :3
<Eickmeyer[m]> bdmurray: Saw your email about the slideshow. Someone in #ubuntu-quality found a problem with one of the translations. Are the translations done?
 * Eickmeyer[m] uploaded an image: photo_2020-04-03_15-37-41.jpg (93KB) < https://matrix.org/_matrix/media/r0/download/matrix.org/gmsIwOKJTcYzQVhJpfbHpEnN >
<Eickmeyer[m]> bdmurray: ^
<bdmurray> Eickmeyer[m]: It needs fixing here https://translations.launchpad.net/ubuntu/focal/+source/ubiquity-slideshow-ubuntu/+pots/ubiquity-slideshow-ubuntustudio/es/+translate
<Eickmeyer[m]> bdmurray: Thanks, I'll pass that along.
#ubuntu-devel 2020-04-04
<Eickmeyer[m]> bdmurray: I ended up doing some fixing myself using a web service, because the person in question seemed to have a language barrier in me telling them the translations needed updating.
<Eickmeyer[m]> I hope it works.
<jvwjgames> How do I make something auto start I am using a GUI lxde
<jvwjgames> Such as a script but with output of the script
<valorie> jvwjgames: this channel is for development
<valorie> try #lubuntu
<CarlFK> installed focal next to cosmic.   setup created sda3 Extended and sda5 .  I see both cosmic and focal grub entries in: sda5/boot/grub but when I boot I am guessing grub is using the sda1/boot that doesn't pause and boots cosmic
<CarlFK> regression - wifi - seems to work fine on cosmic, on focal keeps disconnecting
<Unit193> .xsession-errors say something?  (Or..if this is GNOME whatever GNOME logs to)
<CarlFK> syslog is full of authenticating/disconnecting
<CarlFK> I keep getting a notification: "connection failed, Activation of network connection failed"
<CarlFK> booted into cosmic, now I can ssh into it
<CarlFK> 02:00.0 Network controller: Realtek Semiconductor Co., Ltd. RTL8188EE Wireless Network Adapter (rev 01)
<CarlFK> [   14.924961] rtl8188ee: Using firmware rtlwifi/rtl8188efw.bin
<CarlFK> hmm, rebooted into focal, now it's fie
<CarlFK> fine
<Unit193> Voodoo.
<CarlFK> well great.  now it is fine
#ubuntu-devel 2020-04-05
<Eickmeyer> Does anybody have a chance to help me with some strange lintian errors I'm getting? https://paste.ubuntu.com/p/VJX2ZfyzD4/
<Eickmeyer> Code is at https://launchpad.net/lsp-plugins
<Eickmeyer> I'd be able to handle it, but these are debug symbols, which goes into territory I don't quite understand. Not sure if it's something I can fix or if upstream needs to fix it.
